CVE-2014-0224 looks the worst of this bunch. 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 T…
Was the person who commited ChangeCipherSpec the same person who commited HeartBleed?
OpenSSL Security Advisory
41–50 of 89 posts
Re: OpenSSL Security Advisory
#42Debian advisory: https://lists.debian.org/debian-security-announce/2014/msg00... 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...
Anybody know what the difference is between Ubuntu package
openssl 1.0.1e-3ubuntu1.2 and openssl 1.0.1e-3ubuntu1.4
Re: OpenSSL Security Advisory
#43Earlier quoted context omitted.
I would even dispute it being as bad as goto fail. For this to work both client and server must be vulnerable and the attacker must be in a privileged network position. A malicious server can do it, but it's significantly more difficult to exploit this than goto fail. 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
It would mean (for example) that your local coffee shop could MITM their clients connecting to the bank through their free wifi. Being in a privileged network position isn't that hard, with all the mobile devices flying around everywhere.
Even worse, from what I've observed, such networks are often not secure even against a trivial ARP spoof attack, so anyone connecting to the coffee shop Wi-Fi could mount this attack.
Re: OpenSSL Security Advisory
#44Earlier quoted context omitted.
This should be interesting for OpenVPN.
I think people underestimate how many products use OpenSSL... 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…
You don't need another layer of encryption, just another layer of authentication protects you from attacks that require an active mitm adversary (as basically all attacks on TLS do).
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.
Re: OpenSSL Security Advisory
#45Since most(1) web browsers do not use OpenSSL, CVE-2014-0224 is not going to be a big concern for people browsing using SSL, but it is a concern for machine-to-machine communication where using OpenSSL on both ends will be common. 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 I'm understanding the CVE correctly, it has nothing to do with the browser. It's when it's on the Server, an attacker could just make OpenSSL think their "browser" doesn't support all of the good algo's and eventually cycle through it's available algo's until a relatively insecure one is decided upon (like the relatively weak CBC algo's).
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?
Re: OpenSSL Security Advisory
#46Interested to see if LibreSSL has knocked these ones on the head.
Two of them, CVE-2014-0198 and CVE-2010-5298. We haven't even started looking at the protocol code. 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.
Happy to see you guys working on this. Is there a way to specify that donations should go to the LibreSSL effort rather than to the OpenBSD foundation as a whole?
Re: OpenSSL Security Advisory
#47Is LibreSSL also vulnerable to this?
Yes, there have been no audits of the protocol code yet. I have a feeling it will be patched shortly.
See Ted's comment here: https://news.ycombinator.com/item?id=7851949
Re: OpenSSL Security Advisory
#48Since most(1) web browsers do not use OpenSSL, CVE-2014-0224 is not going to be a big concern for people browsing using SSL, but it is a concern for machine-to-machine communication where using OpenSSL on both ends will be common. 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…
This should be interesting for OpenVPN.
CVE-2014-0224 is the only one that really impacts OpenVPN (No DTLS nor SSL_RELEASE_BUFFERS etc) and as others have said, if you are using OpenVPN chances are you are making use of TLS-AUTH which helps mitigate MITM issues to a reasonable degree. Furthermore, both sides apparently need to be vulnerable. So if you have little control over the clients, updating the server seems to be adequate to address this specific bug.
Re: OpenSSL Security Advisory
#49Earlier quoted context omitted.
Two of them, CVE-2014-0198 and CVE-2010-5298. We haven't even started looking at the protocol code. 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.
Happy to see you guys working on this. Is there a way to specify that donations should go to the LibreSSL effort rather than to the OpenBSD foundation as a whole?
That is a weird request to me. Telling that it should go to the LibreSSL effort is very much like telling OpenBSD developers what they should work on. The way I understood it, most OpenBSD developers are not for hire, not in a manner like this anyhow. These people work on the things they want to work on, and they share the result of their work as a gift to the world. Donations are a gift in return, and the funding enables them to hack more (i.e. hackathons, hardware for developers who need it, infra, etc.) and to share the result with the rest of us (servers & infra).
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.
Re: OpenSSL Security Advisory
#50Logos are now prerequisite, so of course CVE-2014-0224 has you covered. http://ccsinjection.lepidum.co.jp 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...
[deleted]