OpenSSL Security Advisory

Renegotiation is a huge win for performance.

Despite the common belief, SSL negotiation introduces significant overhead and latency.

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/apache...) for details on the protocol.

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.

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.

OpenSSL 1.0.1f is completely unsupported by the OpenSSL project, as that advisory points out:

Support for version 1.0.1 ended on 31st December 2016. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates.

Since 1.0.2 is not vulnerable, it seems unlikely that the bug would be in 1.0.1.