Renegotiation
Starting a new handshake negotiation inside of an existing secure session is called renegotiation. There are two properties that determine System SSL renegotiation characteristics.
Multiple reasons exist for an application to use renegotiation. Renegotiation can be started by either the client or server. The application layer might not be aware that a secure session is renegotiated at the request of a peer. gsk_secure_soc_misc() is used by a GSKit System SSL application to initiate renegotiation.
The SSL and TLS protocol architecture as defined by their base RFCs contain a flaw with renegotiation. The protocols fail to provide cryptographic verification that a session renegotiation is linked to the existing secure session. Supplemental RFC 5746 defines an optional extension to the base protocols to correct the issue.
Since RFC 5746 is a recent addition to a previously defined protocol, not all SSL implementations currently support it. Some SSL implementations have not or cannot be updated to support RFC 5746. To allow for business continuity/interoperability during various stages of the transition, two renegotiation properties exist.
SSL Renegotiation Mode
The System SSL default requires RFC 5746 semantics are used for all renegotiated handshakes. The default mode can be changed with the System Service Tools (SST) Advanced Analysis Command SSLCONFIG.
The mode can be set to allow all unsecure renegotiations or to allow only abbreviated unsecure renegotiations. Use these modes only after careful consideration.
A mode exists to disable all peer initiated handshake renegotiation. This mode prevents secure (RFC 5746 semantics) and unsecure renegotiation. This mode can result in interoperability issues for applications that require the use of renegotiation. Locally initiated secure renegotiation such as gsk_secure_soc_misc() is still allowed in this mode.
SSL Extended Renegotiation Critical Mode
Extended Renegotiation Critical Mode determines when System SSL requires all peers provide the RFC 5746 renegotiation indication during initial session negotiation.
To completely protect both sides of the secure session against the renegotiation weakness, all initial negotiations must indicate support for RFC 5746. This indication can be in the form of the “renegotiation_info” TLS Extension or the Signaling Cipher Suite Value (SCSV) as defined by RFC 5746.
Critical mode is disabled by default to maintain interoperability with SSL implementations that do not implement RFC 5746. When critical mode is enabled, System SSL is restricted to negotiating with systems that implemented RFC 5746. The restriction exists even if neither side supports or uses renegotiation. If it is determined that all System SSL peers support RFC 5746, then this mode can be changed to be enabled.
The default extended renegotiation critical mode can be changed with System Service Tools (SST) Advanced Analysis Command SSLCONFIG. There is a property for client applications and a separate property for server applications.
System SSL always sends the “renegotiation_info” TLS Extension or the SCSV in ClientHello. SCSV is sent only if no other extensions are part of the ClientHello.
