Slashdot Mirror
New OpenSSL Man-in-the-Middle Flaw Affects All Clients
Trailrunner7 (1100399) writes 'There is a new, remotely exploitable vulnerability in OpenSSL that could enable an attacker to intercept and decrypt traffic between vulnerable clients and servers. The flaw affects all versions of the OpenSSL client and versions 1.0.1 and 1.0.2-beta1 of the server software. The new vulnerability could only be exploited to decrypt traffic between a vulnerable client and a vulnerable server, and the attacker would need to have a man-in-the-middle position on a network in order to do so. That's not an insignificant set of conditions that must be present for a successful attack, but in the current environment, where open wireless networks are everywhere and many users connect to them without a second thought, gaining a MITM position is not an insurmountable hurdle. Researchers who have looked at the vulnerable piece of code say that it appears to have existed, nearly unchanged, in the OpenSSL source since 1998.'
"but in the current environment, where open wireless networks are everywhere and many users connect to them without a second thought"
But if you have a man in the middle position, most of those same users would have just clicked "ignore" or typed yes to the "connect anyway" prompt.
"Ultimately you still need to get the encryption information across securely"
This is provably impossible with an active MITM attacker (Though a solution to passive listeners does exist and is in common use). If it could be done, we wouldn't be messing around with complicated certificate signing systems.
Just to be clear, versions 1.01 and 1.02(beta) is the same as saying "Any OpenSSL version released since early 2012", right? It sounds like the summary is trying to downplay the threat a little bit.
The more of these we find, the more secure OpenSSL will be. I hope we continue to find these kinds of problems and see them fixed. If open source has one strength, it's that when many skilled eyes DO converge on the code it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work. The trick is getting the eyes there in the first place.
...and it was like ten Christmases to them. They're probably really down that they just lost one of their best toys.
"When information is power, privacy is freedom" - Jah-Wren Ryel
This is a flaw, but it requires both ends use vulnerable OpenSSL versions. Which means your day-to-day life may or may not be affected that much.
I mean, if you use iOS, OS X, or Windows, you're more than likely NOT using OpenSSL on the client side (except say, if you use Firefox on Windows) - since Apple and Microsoft have their own SSL implementations. If you have an Android phone or tablet, then yes, it's quite likely an issue, and while both are popular, people generally don't use them that much for data (iOS traffic, after 7 years, has finally dropped to below 50% of all mobile traffic out there, despite Android outselling iOS by a huge margin). And nevermind the oddball Linux user.
So the real question is, how many people really ARE affected?
Heartbleed affects everyone because it exposes server secrets irrespective of the client side. But this vulnerability is only really present if both ends use OpenSSL.
Given all the open-source SSL/TLS security flaws (OpenSSL, gnutls, Apple SSL) that have come out these past few months - mostly thanks to renewed interest in hunting flaws, thanks to the Snowden revelations, I suspect - I hope that companies like Microsoft are also seeing this as a wake-up call driving them to do code reviews on their closed-source SSL/TLS code.
#DeleteChrome
I mean, if you use iOS, OS X, or Windows, you're more than likely NOT using OpenSSL on the client side (except say, if you use Firefox on Windows)
Ummm, firefox uses NSS, not OpenSSL: http://en.wikipedia.org/wiki/Network_Security_Services
The real limiter for your average user is the requirement for man in the middle position.
Even without this flaw, most users will just click through any warning that comes up during a man in the middle attack.
It's still a bad thing that the mechanism designed to protect us from man in the middle is broken, but for the average user, the mechanism is already broken via apathy.
does this affect LibreSSL?
Firefox uses NSS, not OpenSSL.
If I understood it correctly, my older OpenSSL package (openssl 0.9.8o-1ubuntu4.6) should be fine, right?
So the real question is, how many people really ARE affected?
That would depend on how much, if any, of OpenSSL code was incorporated into Microsoft and Apple products regardless of the GPL. After all, 1998, was a long time ago.
That's not an insignificant set of conditions that must be present for a successful attack
But it is exactly the point of TLS, to protect against such an attacker. If you know you don't have a man-in-the-middle then you don't even need it in the first place.
True that the server might not be running that version, but a non-trivial number of them are.
Plenty of client applications make SSL connections and OpenSSLis used for that.
That's quite the parabolic sentence there. I hope you didn't give yourself whiplash.
Corporation, n. An ingenious device for obtaining individual profit without individual responsibility. - Ambrose Bierce
I agree with your assessment and conclusion, and while I can't refute that apathetic users are a problem, I submit that apathetic users should NOT be a problem. In our current state of the art, users take a lot of blame for not implementing best practices regarding credential quality, changing passwords frequently, failing to read warnings, privacy statements and terms of conditions, etc. Users are also held accountable for not updating their operating systems and the programs that ride on the (Flash, Java, Other). The real burden, in my opinion, rests solely with the experts in the field. Users are reading about Heartbleed, OpenSSL, Man In The Middle, client, server, encryption, ...
Users want to level up on Candy Crush Saga and they want to leave all that mumbo-jumbo to people like we here on this board.
I think that's fair.
It little behooves the best of us to comment on the rest of us.
After reading the advisory from OpenSSL, I'm still confused by what is vulnerable and what isn't. The flaw requires both the client and server to be vulnerable. If the client is using OpenSSL, they're vulnerable for 0.9.8/1.0.0/1.0.1. But if the server is using OpenSSL, they're only vulnerable if using 1.0.1/1.0.2(beta). Yet the bullet list of recommendations points out that servers should upgrade even if they're using 0.9.8: * OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. Let's say I have a server using 0.9.8 and client using 1.0.0. If I understand their explanation correctly, then this scenario is *not* vulnerable. Is that the same conclusion others would draw from their explanation?
The project name is written as LibReSSL. Clever, clever..
Fascism should more properly be called corporatism because it is the merger of state and corporate power. -- Mussolini
WRONG. If the server is vulnerable, your session can be hijacked. http://ccsinjection.lepidum.co...
Oh I totally agree with this. Relying on the user to "make the decision" is (or should be) the last resort when a programmer can't figure out how to deal with a situation.
In the specific area of certificate verification on web browsers, the problem has been too many false positives. Lots of people are sloppy with their certificates, and users have gotten used to the idea that any error mentioning a certificate is probably no big deal (because the other 100 times they clicked the ok button the world didn't end). This then served only to encourage people to be even more sloppy (the user will just click the warning that comes up, no big deal).
Things are moving in a good direction now, with most of the major browsers making the dialog more menacing and (in the case of firefox at least) requiring several not-so-intuitive steps, and this having the effect of making letting your certificates expire/using incorrect certificates more of a big deal because you will lose traffic. I think we are at least at a point where most users will stop when they get one of these more complicated warnings and they are doing something like banking or buying something online.
"Ultimately you still need to get the encryption information across securely"
This is provably impossible with an active MITM attacker (Though a solution to passive listeners does exist and is in common use). If it could be done, we wouldn't be messing around with complicated certificate signing systems.
Correct. A MITM beats everything done over the wire. You need to secure your shit before you use the wire. You need a pre-shared key to encrypt the initial communication. A certificate sort of does this, but not really because we still trust them blindly and we initially accept them over the same wire. The proper way to do shit would be for you to go to your bank in person, for example, and generate 2 keys - one for you to use to talk to your bank and one for the bank to use to talk to you. You then use that key when establishing your first communication with the bank, and they use theirs. You can use whatever encryption you want, you can deploy a key-changing scheme, or a certificate scheme like we have now, whatever.
Your initial key exchange must be done securely. Doing it in person is the most secure way possible, but it's also the least convenient. Doing it over the wire is NEVER secure against a MITM.
I see a lot of comments that try to convince that "closed source isn't any better". So my actual question is: would it be some kind of sin if closed source was actually better?
at least my install still uses 0.9.8n though who knows what other nasties lurk in that one
Something does not add up. How is there a new vulnerability that's been in the source for sixteen years? How are older versions of the server code not vulnerable if it's sixteen years old?
Diffie-Hellman Key Exchange allows you to securely share a secret key over an insecure medium. Combining this with asymmetric cryptography to identify parties is how modern handshake protocols work.
The problem here how to trust Bob's asymmetric key really came from Bob and not Eve.
You are correct in that the ideal solution would be to talk to Bob over a different medium (like phone) and ask him if that is his key but there are ways to do this over the wire. As an example, several Linux distros sign their LiveCD images with cryptographic keys and post the keys' fingerprints on their web page. Can these be spoofed? Sure, hack the server hosting the files. That requires additional effort (and risk) though which would dissuade most cyber-criminals from attempting it.
Is this perfect security? No, but there is no such thing short of chucking whatever you want secured into a black hole.
Is OpenVPN affected?
openssl-libs-1.0.1e-37.fc20.1.x86_64
openssl-1.0.1e-37.fc20.1.x86_64
With the last entry in the "libs" change log being Mon Apr 07 2014.
Today:
openssl-libs-1.0.1e-38.fc20.x86_64
openssl-1.0.1e-38.fc20.x86_64
From the "libs" changelog (removed the accents from the name):
* Thu Jun 05 2014 Tomas Mraz 1.0.1e-38
- fix CVE-2010-5298 - possible use of memory after free
- fix CVE-2014-0195 - buffer overflow via invalid DTLS fragment
- fix CVE-2014-0198 - possible NULL pointer dereference
- fix CVE-2014-0221 - DoS from invalid DTLS handshake packet
- fix CVE-2014-0224 - SSL/TLS MITM vulnerability
- fix CVE-2014-3470 - client-side DoS when using anonymous ECDH
Not bad a fix, virtually on the same day the vulnerability is announced. Of course in a production environment you should not be using Fedora but if you are using Redhat there is a fix already, however any self respecting System Admin should now be raising change requests to upgrade the relevant packages (you most likely don't even need a reboot although managers normally feel better with one) after checking with their software support. Actually the same procedures should apply for any Linux distribution that is used in a production environment.
There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
And your insurance company thinks driving slow is dangerous.
Support my political activism on Patreon.
For $Deitie's sake, gief zeese man a "+1 funee" I runned out of ze moderation pointz, sacrebleu!
-- 29A the number of the Beast