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
a) switch to cellular on a phone before accessing something important like a banking site
or b) use something like Personal Hotspot together with a phone switched to cellular to allow a laptop to access something important like a banking site
That's what I do. I certainly don't trust random WiFi for sensitive communications.
IMO you're much safer relying on AT&T or Verizon to connect you to key sites via cellular service rather than thru WiFi. OTOH I know that in the past AT&T has automatically switched my iPad from cellular to WiFi when I was at a coffee shop that had service from them. So this may be a little tricky in practice.
And even if you do protect against ARP spoofing via 802.1x -- you would still need some kind of shared secret/certificate scheme to avoid a fake access point? As anyone sitting next to you is likely to be able to provide a stronger signal than the hotspot...
Reminds me that I had an idea to wrap up some kind of hot-spot with an easy to use internet cafe style time-limited access software distribution and offer up to local businesses... I suppose these days providing a screen for qr-code sharing of details would be a viable option...
I thought most wireless lans acted as an (shared medium) ethernet, that is, they allow clients to send packets directly client to client? That is, I thought [ed:naughty]-client could just broadcast ARP packets directly to the clients? Or does perhaps (ethernet) broadcast traffic go through the gateway?
None of this helps with a rouge AP, of course -- so it might be a bit academic.
Edit: Looks like I was spot-on! This is a real vulnerability, and is called Hole 196: http://www.airtightnetworks.com/wpa2-hole196.
But as demonstrated up-thread I clearly need to refresh my knowledge of 802.11*...
Interesting, I hadn't really looked into 802.11alphabetsoup in terms of ad-hoc vs infrastructure -- wasn't aware the ap was a bottleneck. The natural next question is if there are any standard secure forms for ad-hoc networking?
It would seem that shared-secret should be easy enough (but probably with the same/similar security issues as other shared-media networks in addition to the possibility of guessing the key). Some form of certificate authentication, or kerberos like shared-secret-trusted-mediator should be possible? But having a look around, I can't seem to find any - certainly not any that could be expected to work with standard OSs and devices...?
I suppose one could simply use an unsecured ad-hoc network + vpn for routing? Still I don't know of any VPN-styles that would allow broadcast traffic over such a mesh network?
[edit: It would appear the olpc projects has done some work in this area: http://wiki.laptop.org/go/Mesh_Security
ed2, also: http://wiki.laptop.org/go/Mesh_Network_Details
Which other browsers use OpenSSL?
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.
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:
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.
OpenVPN does a pretty good job, as long as you choose a sane configuration (most importantly, use tls-auth and TLS key negotiation). It's definitely less vulnerable than other TLS stuff due to the tls-auth option.
(Full disclosure: my company provides the hardened OpenVPN-NL, and I've done a little work on that.)
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?
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.
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).
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...
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.
even though the "exploit mitigation" didn't work with Heartbleed, which was the reason libressl started.
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.
If you want to deny the project its money and only contribute to a part of it, the only way I can see that happening right now is that you hire a developer to work on the part you want.
Also, don't forget that developing software on OpenBSD is likely to make that software better (there are features that make OpenBSD a good development platform; and the fact that code is tested on many different hardware platforms helps). So while you might not be using OpenBSD, chances are the system is affecting you positively nevertheless. I'd also encourage you to look at how many other projects use code from OpenBSD. Do you use Android per chance?
Yes. One the one side you have a group called 'employers'. On the other side you have a group called 'contractors'. Contractors are free to work on whatever they feel like, but if they also want money, they should probably do some work for employers from time to time.
It's hardly rude to say "I value this, here is some money to help this along". If the devs see that plenty of people are giving money to 'this', then if they don't work on it, that channel will dry up. Donations aren't a gift like a christmas present, which you get to use on whatever you want. Donations are an enabling device usually intended for a particular cause. They don't mean you get to dictate the actions of the staff, but at the same time, the staff shouldn't be taking donations for work they don't care to do.
libreSSL isn't any better on this front than OpenSSL without SSL_MODE_RELEASE_BUFFERS.
See Ted's comment here:
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.
> No. Attackers cannot steal your private keys through this bug itself.
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.
They also released a blog entry about the CCS injection issue: https://access.redhat.com/site/blogs/766093/posts/908133
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.