112051 - Send and handle TLS no_renegotiation alerts

Status: RESOLVED WONTFIX

(NSS :: Libraries, enhancement, P3)

Description

[Nelson Bolyard (seldom reads bugmail)]

TLS defines many new alerts, one of which is no_renegotiation.
The alert is intended to provide a way for an application to prevent 
handshakes subsequent to the first one done when the TCP connection is 
established.  

It is always a "warning", never "fatal". but when sending or receiving one, 
the application or TLS implementation must decide whether to 

a) treat this as fatal, terminating the connection, or 

b) simply stop the handshake in progress and allow the TLS connection to 
revert to the state it was in before the handshake began (assuming that
a previous handshake had succeeded).

Presently, libSSL provides no way to ever send that alert.  There is no
way for an application to configure the SSL socket to disallow handshakes
subsequent to the first (or most recently preceeding) one.

Also, libSSL presently just ignores "warning" alerts, and does not reset 
the handshake state when this alert is received, which could lead to a hang.
At the very minimum, libSSL should probably treat these alerts as fatal if 
it cannot reset the handshake.

The ability to send these alerts probably should not be added to libSSL
until libSSL is able to handle these alerts per method "b" above.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Target 4.0.

Comment 2

[Wan-Teh Chang]

Changed the QA contact to Bishakha.