New OpenSSL Man-in-the-Middle Flaw Affects All Clients 217
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.'
Key phrase of vulnerability : (Score:2, Informative)
"but in the current environment, where open wireless networks are everywhere and many users connect to them without a second thought"
Re:Versions (Score:5, Informative)
That's right, it affects all versions that are anywhere close to current.
Re: Versions (Score:3, Informative)
There are also stable releases of 0.9.8 and 1.0.0 which are still maintained for security updates. Many long-term-stable distros and even some recent network appliances don't use 1.0.1 because of the possibility that code churn and feature dev has made it less secure than 1.0.0. In this case they would be right.
Re:This is awesome (Score:5, Informative)
OpenSSL design is fundamentally flawed. Bug fixes will probably introduce more bugs in many cases.
Well, the LibreSSL project is ripping out much of the code and rebuilding it: http://www.libressl.org/
I mean, OpenSSL will use your actual private key as a source of entropy. How messed up is that?
Ummm, your private key should be randomly generated, otherwise public key encryption doesn't work too well.
But your private key doesn't change, so that isn't a good thing to do. Fixing the entropy is one of the many things LibreSSL is doing: http://www.openbsd.org/papers/bsdcan14-libressl/mgp00016.html
Re:How are people affected in their day to day liv (Score:2, Informative)
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
Re:Neat (Score:4, Informative)
The summary is actually ridiculous.
The summary suggests SSL is useful without a man-in-the-middle. SSL protects against eaves droppers on your network; but any eaves dropper can become a MITM. ARP cache poisoning is a common technique; on switched networks, you cannot eaves drop without ARP cache poisoning or ARP flooding. Hubbed networks are similarly easy: packet the target with IP=DEFAUTGATEWAY MAC=YOU and it will start addressing default gateway packets to you (routing works by putting the destination IP on a packet, but the default gateway's MAC on the frame; you enter the IP address of the router, and the OS runs an ARP request to find its MAC).
It's entirely unlikely that SSL does anything if there isn't a man in the middle.
Re:MITM needs to be designed around (Score:3, Informative)
"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.