OpenSSL Security Advisory(openssl.org)
openssl.org
OpenSSL Security Advisory
https://www.openssl.org/news/secadv/20170216.txt
26 comments
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.
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.
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.
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.
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.
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.
Renegotiation is a huge win for performance.
Despite the common belief, SSL negotiation introduces significant overhead and latency.
Despite the common belief, SSL negotiation introduces significant overhead and latency.
I think you have session resumption in mind. Renegotiation is different and involves performing more than one handshake per connection.
Oh, thanks. Hm...then I agree with parent; I have no idea what renegotiation is for.
But under what circumstances is it used? Why would you renegotiate in the middle of a session?
Since Ubuntu 14.04 is still on openssl version 1.0.1f, is that version applicable to this security advisory?
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.
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.
Ubuntu 14.04 is LTS though, so they'll be updating to a supported version of OpenSSL, just as they've done with, say, OpenJDK ( https://bugs.launchpad.net/trusty-backports/+bug/1368094 ).
</s>
I love Ubuntu; the "LTS" part is a bit of a joke.
</s>
I love Ubuntu; the "LTS" part is a bit of a joke.
This happened before with 12.04 LTS. They never back-ported a newer version of OpenSSL.
I'm not sure if it's just poor wording, but that way you stated that makes it seem like you don't know what backporting is. Backporting[1] is not providing a newer version of the application/library in question, it's taking the fix and making it work on the older version.
A cursory look at the Ubuntu security advisories page shows that they have back-ported OpenSSL for both 14.04 LTS and 12.04 LTS. There's one from a few weeks ago for both[2], and there are many more that have been done.
1: https://access.redhat.com/security/updates/backporting
2: https://www.ubuntu.com/usn/usn-3181-1/
A cursory look at the Ubuntu security advisories page shows that they have back-ported OpenSSL for both 14.04 LTS and 12.04 LTS. There's one from a few weeks ago for both[2], and there are many more that have been done.
1: https://access.redhat.com/security/updates/backporting
2: https://www.ubuntu.com/usn/usn-3181-1/
I noted above that the nomenclature is inconsistent between Ubuntu and RHEL. But you are right on the money with regards to the fix in precise.
I've seen ubuntu backport fixes and rarely backport packages from a newer Ubuntu/Debian release. As you said, the nomenclature for backport is confusing.
Why is it a joke? It has always been a case that Canonical will backport security patches and critical bugfixes, rather than updating the entire package to the latest upstream version.
On the other hand, Ubuntu Backports is community project, and your snarkiness is unwarranted - as long as no one cares enough to backport and keep maintaining the backport, it won't be done.
That not backporting, that's a package upgrade request. Backporting[1] is something different, and applies to features and bug fixes being ported back to older versions of a product, not providing an upgraded package for an older product. All the enterprise class distributions backport (for good reason). Some also provide the occassional package upgrades (such as those that roll out at RHEL point-releases).
1: https://access.redhat.com/security/updates/backporting
1: https://access.redhat.com/security/updates/backporting
In Ubuntu terms a backport is when a newer version of a package is made available in an existing release. With few exceptions (see MicroReleaseExceptions) versions of packages in a distro release are not updated, which is why the backports pockets exist.
We certainly provide security updates for packages in main for the LTS lifetime.
We certainly provide security updates for packages in main for the LTS lifetime.
That's unfortunate, as there has been accepted terminology that differentiates those concepts for quite a while in the enterprise distribution space, likely predating Ubuntu's existence. Backports as you describe them here are referred to as "rebasing" in RHEL's parlance.
I understand where the difference comes from though, Debian. The problem is that Debian serves a different need, and is not really an "enterprise" distro. That's not to imply it isn't a quality distribution, but their purposes are not necessarily aligned with the needs of organizations which may be managing hundreds or more systems all at once. Debian "backports" newer packages from testing to to current to deal with needed fixes, while enterprise distributions "backport" the patches to make sure the package behavior doesn't inadvertently change due to some other changes in the package during the time since it was first included.
Ubuntu's beginnings as an offshoot of Debian show here, but that's where there's a disconnect between the terminology they use and that of most other distributions that target the enterprise (which admittedly Ubuntu only does partially). I can't really blame Ubuntu for their use of the terminology, since it does have historical precedence for them, and they are't even entirely an enterprise distro (by which I mean they also target desktop usage heavily, compared to RHEL which only goes as far that direction as to target workstations, and somewhat halfheartedly IMO).
I understand where the difference comes from though, Debian. The problem is that Debian serves a different need, and is not really an "enterprise" distro. That's not to imply it isn't a quality distribution, but their purposes are not necessarily aligned with the needs of organizations which may be managing hundreds or more systems all at once. Debian "backports" newer packages from testing to to current to deal with needed fixes, while enterprise distributions "backport" the patches to make sure the package behavior doesn't inadvertently change due to some other changes in the package during the time since it was first included.
Ubuntu's beginnings as an offshoot of Debian show here, but that's where there's a disconnect between the terminology they use and that of most other distributions that target the enterprise (which admittedly Ubuntu only does partially). I can't really blame Ubuntu for their use of the terminology, since it does have historical precedence for them, and they are't even entirely an enterprise distro (by which I mean they also target desktop usage heavily, compared to RHEL which only goes as far that direction as to target workstations, and somewhat halfheartedly IMO).
OpenSSL is in "main" and as such, it is supported by Canonical for the whole lifetime of the LTS. Upstream dropping support doesn't change that, it simply means that Canonical security team will be backporting patches themselves.
https://people.canonical.com/~ubuntu-security/cve/pkg/openss...
https://people.canonical.com/~ubuntu-security/cve/pkg/openss...
Not sure why this is high - it's only a crash, not a data leak.
I wonder how common is RFC 7366 currently BTW.
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.