4 ms·

What is the point of renegotiation of ssl/tls sessions? It seems to have very limited use cases, but is the source of an almost infinite amount of vulnerabiliti

by throwaway2048 10y ago

What is the point of renegotiation of ssl/tls sessions? It seems to have very limited use cases, but is the source of an almost infinite amount of vulnerabilities. Is there ever a real reason to want to suddenly change cipher suites half way through a session? It seems a solid 20-30% of serious openssl vulns are renegotiation related.

paulddraper 10y ago
Renegotiation is a huge win for performance. Despite the common belief, SSL negotiation introduces significant overhead and latency.
- orf 10y ago
  But under what circumstances is it used? Why would you renegotiate in the middle of a session?
- agl 10y ago
  I think you have session resumption in mind. Renegotiation is different and involves performing more than one handshake per connection.
  - paulddraper 10y ago
    Oh, thanks. Hm...then I agree with parent; I have no idea what renegotiation is for.
geofft 10y ago
Server-Gated Cryptography, the old '90s thing to allow 128-bit crypto to US persons, works by first connecting with "export-grade" 40-bit crypto, reading an extension in the certificate that says "Yes, this is a US-based server", making sure the cert is signed by a US-based CA, and then doing a renegotiation to 128-bit crypto. If the certificate is missing a valid extension, the connection continues with 40-bit crypto. Now that browsers are no longer prohibited by law from making 128-bit connections outside the US, this use case doesn't matter any more. See mod_ssl/README.GlobalID from wherever you can still find mod_ssl (e.g., https://stuff.mit.edu/afs/sipb/machine/anxiety-closet/apachessl/mod_ssl-2.8.11-1.3.27/README.GlobalID https://stuff.mit.edu/afs/sipb/machine/anxiety-closet/apache...) for details on the protocol.
- yuhong 10y ago
  Note that there are two versions, the Netscape one and the Microsoft one. The Netscape one used renegotiation, the Microsoft one just sends a new ClientHello after the Certificate message. I think SChannel supported both of them and looked at the certificate to determine which one to use, while NSS supported only the Netscape one.
agl 10y ago
You are correct that renegotiation has been a very rich source of bugs over the years. It has been removed in TLS 1.3. You would have to ask people who were involved in the early days of SSL to be sure but my impression was that the motivation was centered around the idea that symmetric keys should not be used to encrypt too much information. Thus extra handshakes were thought to be needed in order to "refresh" keys. That's not inaccurate, although I feel that people wanted to rotate keys out of a sense of unease, rather than based on an analysis of how the security bounds change as the amount of data increases. Server-gated crypto was certainly a reason, as detailed in a comment here by geofft. These days (and I don't know if this was in mind when renegotiation was designed), renegotiation in HTTPS is almost exclusively used by servers (often IIS) to request a client-certificate after receiving an HTTP request. There are much simpler ways to achieve these goals and they have been implemented in TLS 1.3 to replace renegotiation. I think that people were much more confident in their ability to write correct software in the 1990s.
rkeene2 10y ago
Renegotiation is used in cases where you want to change the rules of the SSL/TLS session after data has been sent in the channel. One common use case for this is to require TLS client certificates for only SOME resources. The TLS/SSL server initially does not advertise any acceptable CAs for client certificates, but once a resource that requires a TLS client certificate is requested then renegotiation is done providing the resource-specific list of acceptable CAs for which a client certificate would be acceptable to provide access to the resource.

paulddraper 10y ago

Renegotiation is a huge win for performance. Despite the common belief, SSL negotiation introduces significant overhead and latency.

orf 10y ago
But under what circumstances is it used? Why would you renegotiate in the middle of a session?
agl 10y ago
I think you have session resumption in mind. Renegotiation is different and involves performing more than one handshake per connection.
- paulddraper 10y ago
  Oh, thanks. Hm...then I agree with parent; I have no idea what renegotiation is for.

geofft 10y ago

Server-Gated Cryptography, the old '90s thing to allow 128-bit crypto to US persons, works by first connecting with "export-grade" 40-bit crypto, reading an extension in the certificate that says "Yes, this is a US-based server", making sure the cert is signed by a US-based CA, and then doing a renegotiation to 128-bit crypto. If the certificate is missing a valid extension, the connection continues with 40-bit crypto. Now that browsers are no longer prohibited by law from making 128-bit connections outside the US, this use case doesn't matter any more. See mod_ssl/README.GlobalID from wherever you can still find mod_ssl (e.g., https://stuff.mit.edu/afs/sipb/machine/anxiety-closet/apachessl/mod_ssl-2.8.11-1.3.27/README.GlobalID https://stuff.mit.edu/afs/sipb/machine/anxiety-closet/apache...) for details on the protocol.

yuhong 10y ago
Note that there are two versions, the Netscape one and the Microsoft one. The Netscape one used renegotiation, the Microsoft one just sends a new ClientHello after the Certificate message. I think SChannel supported both of them and looked at the certificate to determine which one to use, while NSS supported only the Netscape one.

agl 10y ago

You are correct that renegotiation has been a very rich source of bugs over the years. It has been removed in TLS 1.3. You would have to ask people who were involved in the early days of SSL to be sure but my impression was that the motivation was centered around the idea that symmetric keys should not be used to encrypt too much information. Thus extra handshakes were thought to be needed in order to "refresh" keys. That's not inaccurate, although I feel that people wanted to rotate keys out of a sense of unease, rather than based on an analysis of how the security bounds change as the amount of data increases. Server-gated crypto was certainly a reason, as detailed in a comment here by geofft. These days (and I don't know if this was in mind when renegotiation was designed), renegotiation in HTTPS is almost exclusively used by servers (often IIS) to request a client-certificate after receiving an HTTP request. There are much simpler ways to achieve these goals and they have been implemented in TLS 1.3 to replace renegotiation. I think that people were much more confident in their ability to write correct software in the 1990s.

rkeene2 10y ago

Renegotiation is used in cases where you want to change the rules of the SSL/TLS session after data has been sent in the channel. One common use case for this is to require TLS client certificates for only SOME resources. The TLS/SSL server initially does not advertise any acceptable CAs for client certificates, but once a resource that requires a TLS client certificate is requested then renegotiation is done providing the resource-specific list of acceptable CAs for which a client certificate would be acceptable to provide access to the resource.