It seems openssl will accept ChangeCipherSpec messages much too early. CCS in TLS means "we've finished handshake/renegotiation and will now start using the new keys".
It looks likely that a MITM can send CCS to both ends during handshake, and have them agree on the empty master secret (and therefore trivial application data encryption keys). This is pretty bad as far as TLS bugs go (as bad as "goto fail", but not as bad as "heartbleed").
Given that accepting TLS messages only within the right constraints is fundamental to correctness of TLS and openssl seemingly can't get this right (this, and heartbeat messages before/during handshake), it seems likely this isn't the last problem of this kind.
Thank you for this excellent description for we who recognise this must be a problem, but lack the area knowledge to immediately appreciate how bad (or not) it may be.
Edit: agl has a good writeup of the bug and what it might take to exploit https://www.imperialviolet.org/2014/06/05/earlyccs.html
Given that this also affects 0.9.8 there are going to be lots of backend systems that need upgrading.
(1) Apparently Chrome on Android is the odd man out in using OpenSSL, but I don't know if it is vulnerable to this problem.
http://www.pcworld.com/article/2143440/server-makers-rushing... http://www.networkworld.com/article/2176022/router/heartblee...
It sounds kind of stupid, but i'm thinking the best short-term way to secure an exposed OpenVPN tunnel against future OpenSSL TLS holes may be two layers of encrypted traffic. One static key tunnel to prevent public TLS holes from exposing the installation, and inside that a strong TLS 1.2 implementation with perfect forward secrecy. It's lame and limited (due to the requirement on the static key) but could work for black-box implementations where you don't have much choice in your use of the product. Some cheap hacks to the source of OpenVPN may even allow both of these to be stacked without requiring two tunnels.
OpenVPN has offered such an option for a long time: https://community.openvpn.net/openvpn/wiki/Hardening#Useof--...
This wraps just the TLS control channel, which has low traffic and thus results in a small overhead. The data channel is separated from TLS in OpenVPN, which is why TLS-auth does not add overhead to the actual network packet encapsulation. TLS-auth is a neat feature and everybody should use it.
While it does not provide additional encryption, it does prevent clients who do not know the secret from initiating connections (and thus interacting with the TLS state machine/etc).
So, it is a potential threat to servers since most web server are *nix based and most of those will have the default of OpenSSL installed.
However, I seem to recall this always being a possible attack vector, in any SSL/TLS library due to how browsers/servers have always negotiated which algo to use based on which are commonly supported and the strongest available... so ... nothing new?
Specifically,
With any OpenSSL client talking to an OpenSSL 1.0.1
server, an attacker can inject CCS messages to fixate the
bad keys at both ends but the Finished hashes will still
line up. So it's possible for the attacker to decrypt
and/or hijack the connection completely.I'll also note that "This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common." is pretty misleading. nginx is affected, is not multithreaded, but is fairly common.
I think you get a pretty decent return on investment even if your dollars support openbsd features you don't use. All of us working on libressl are working in it because we work on openbsd, and we work on openbsd because others have made it a viable platform for us. Basically you may not care about openbsd desktops, but I do, and I'm only working on libressl because of that. Paying me market rates for this work would get a lot less done.
Particular example: libressl exists in part because of previous work done on exploit mitigation. Without that, there'd be no libressl.
Or, to put it another way, if you were to donate to me, I'd probably turn around and forward that money to openbsd foundation anyway.
All that said, you can mention that your donation is for libressl. That doesn't guarantee anything, but I'm sure there are unofficial tallies.
Can you imagine someone saying "I want to give you this gift but only if you focus on thing X (which I care about) and not on things Y and Z (which you care about)"?
Keep in mind that the BSDs strive to be a complete, integrated operating system. While some devs focus on small parts of the tree, many or most work on the larger whole. Improvements to specific parts are a part of improvements to the whole. Working on LibreSSL is a byproduct or part of working on OpenBSD.
Can you buy a faster server and more bandwidth to serve this one subdirectory in your project? But don't spend that money on anything else?
EDIT: Having said that, developers are and have been funded to work on specific things.. IIRC the kms work was sponsored, and gilles works on smtpd as a part of his job. But I think it would be kind of rude to disregard the effort the core OpenBSD devs have spent on LibreSSL and only donate if you can give that money to one or two paid developers. Look at it this way: Theo works on many many parts of the system. So does Miod. And so does Bob. As do many other developers who commit changes to LibreSSL. They're in it for OpenBSD. Can you tell them to forget OpenBSD and do LibreSSL for you?
EDIT: Or how about this? Sorry guys, this hackathon we're allowed to touch libssl only. Why? Because some people "donated" for us to work on LibreSSL and LibreSSL only. I don't think it can go like that. It becames work for money. Work on specific things people pay you to work on. Work for people who are voluntarily working on OpenBSD. I doubt many OpenBSD developers would attend such a hackathon.
libreSSL isn't any better on this front than OpenSSL without SSL_MODE_RELEASE_BUFFERS.
I guess until a couple of weeks ago OpenSSL was 'one of many other critical pieces of software that have nowhere near the level of scrutiny that WordPress (and I know you don't meant Wordpress) is receiving currently'. So we'll see a re-focusing on other software when people feel that either the OpenSSL well of exploits has at least temporarily dried up or when something else that is crucial breaks.
But as long as vulnerabilities in OpenSSL are discovered at this rate it seems to be an effort well-spent, and we will all reap the benefit of that effort.
Heartbleed really shook the IT world, I don't know anybody in operations that was not affected by it. (And I can hear them collectively sighing right now). If there was a Richter scale for exploits it would have rated a '9'.
It's a bit like the news cycle, these things tend to burn out. But right now OpenSSL exploits are very much in the spotlight, and guarantee almost instant fame for the person discovering one. So I think we'll see a few more of these before it will quiet down. (I actually hope that we won't see more of these but given the past couple of weeks that hope is not very realistic).
Having been around in the '90s, with the instant root shell exploits and whatnot, I tend to think of Heartbleed as more of a 6.
The Core Infrastructure Initiative is starting to address that: http://www.linuxfoundation.org/programs/core-infrastructure-...
Red Hat 6 advisory: https://rhn.redhat.com/errata/RHSA-2014-0625.html
Red Hat 5 advisory: https://rhn.redhat.com/errata/RHSA-2014-0624.html
Ubuntu advisory: https://lists.ubuntu.com/archives/ubuntu-security-announce/2...
openssl 1.0.1e-3ubuntu1.2 and openssl 1.0.1e-3ubuntu1.4
[1]: http://packages.ubuntu.com/saucy/openssl
[2]: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...
If you want to see the patches they're now up on GitHub:
OpenSSL 1.0.1: https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-sta...
OpenSSL 1.0.0: https://github.com/openssl/openssl/commits/OpenSSL_1_0_0-sta...
OpenSSL 0.9.8: https://github.com/openssl/openssl/commits/OpenSSL_0_9_8-sta...
A. This bug was discovered by Masashi Kikuchi of Lepidum. He found this bug while studying safe TLS implementations using a proof assistant system Coq."
So they are starting to find actual bugs with Coq? I'm impressed, and would love to know if anybody has more details (lepidum's blog seems down at the moment).
http://www.reddit.com/r/netsec/comments/27dhcn/openssl_secur...
Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution.
It seems to me that users on versions earlier then 1.0.1 would be advised not to upgrade since they stated in the sentence before that 1.0.1 is vulnerable.
------
edit: Oops, I feel kind of dumb. Literally the next line is describing the recommended upgrade for 0.9.8 users:
OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.
> OpenSSL 0.9.8 SSL/TLS users should upgrade to 0.9.8za.
> OpenSSL 1.0.0 SSL/TLS users should upgrade to 1.0.0m.
> OpenSSL 1.0.1 SSL/TLS users should upgrade to 1.0.1h.
See Ted's comment here: https://news.ycombinator.com/item?id=7851949
> No. Attackers cannot steal your private keys through this bug itself.
Q. Do I have to re-create my private keys or certificates?
A. No. Attackers cannot steal your private keys through this bug itself. However if you have transferred your private keys via paths protected by SSL/TLS, the keys could be sniffed. If this is the case, consider regenerating the keys or certificates.
https://lists.debian.org/debian-security-announce/2014/msg00... https://news.ycombinator.com/item?id=7851535
https://github.com/openssl/openssl/commit/bc8923b1ec9c467755...
I noticed (in that commit anyway) there were no tests changed. Is it pretty standard not to test things like this? If I find a major bug in code I write, I usually write a test first and TTD until it's fixed.
Edit:
They also released a blog entry about the CCS injection issue: https://access.redhat.com/site/blogs/766093/posts/908133
[1] http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/ZDI-1...