Slashdot Mirror
Man-In-the-Middle Vulnerability For SSL and TLS
imbaczek writes "The SSL 3.0+ and TLS 1.0+ protocols are vulnerable to a set of related attacks which allow a man-in-the-middle (MITM) operating at or below the TCP layer to inject a chosen plaintext prefix into the encrypted data stream, often without detection by either end of the connection. This is possible because an 'authentication gap' exists during the renegotiation process, at which the MitM may splice together disparate TLS connections in a completely standards-compliant way. This represents a serious security defect for many or all protocols which run on top of TLS, including HTTPS."
Only with quantum physics can we actually get a secure data transfer. Or not or both.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
More cyber terror :)
-LoneWolf-
It is by will alone I set my mind in motion.
So are these man in middle exploits fixed in the latest Ubuntu release ?
Chris ,
Php Programmers.
We need someone who can eliminate these middle men! Where's Tom Shane on this??
...by the CIA/NSA/[insert your favorite spying agency]
Wasn't the man in the middle attack the subject of a Michael Jackson song?
Anyone who knows anything about TLS/SSL knows that MitM attacks are always the biggest risk.
Heck, appliances like the IronPort devices use exactly that to inspect user traffic.
Its the same man in all 3 places.
So now that SSL is pretty much useless, lets assume the terrorists have all of our https and ssl secured credit card numbers. This is on top of the random number generator vulnerability in Windows which most people don't know about.
So you didn't load certificates or keys on your IronPort? Wow, you must have the only magic IronPort made.
Am OpenSSL patch (http://www.links.org/files/no-renegotiation-2.patch) disables SSL
renegotiation, closing the security hole.
But let me ask this : who would ever require SSL renegotiation in practice?
I mean seriously -- changing the cipher in the middle of an SSL session??
-- no mainstream scenario would ever do this.
A question comes to mind why renegotiation was ever supported in the first place.
The next question is what OTHER seldom-used "features" are supported by
most SSL implementations that are just supported so that the implementation
can claim full RFC compliance, but are never actually used by real web sites.
My own SSL builds disable everything except RC4-*-RSA
Maybe its time we stop using SSL and just use GNUPG Auth. Let the user generate their own key and be responsible for their own security, or lets just use smart card readers. We make impossible to secure our machines due to our institutional insecurity. This way we can use it as an excuse to blame terrorists and get the feds involved.
Why aren't smart cards the norm? Why are we using passwords at all?
It's news in the sense that TLS provides an authentication mechanism specifically designed against this kind of attack.
If somebody is sufficiently motivated, has lots of free time, and has the knowledge, you can be sure they'd learn about this exploit before slashdot or the mainstream media. You can be sure they'd probably learn about it the moment the first researchers learn about it and sell the information, or brag about what they discovered behind closed doors. Lets get real, most people can't keep a secret and that includes the people who discover the exploits, and while it might not be on slashdot, the sort of people who would use this exploit probably don't look on slashdot to find the latest exploits.
No... the criminals can bribe or pay some masters or phd level researcher to sell them the source code in some instances or they can just listen and wait for them to brag to their friends on IRC "hey look I just discovered a bug in SSL!"
We should eliminate SSL completely, and the password based security methodology. Credit cards are no more secure using a password over SSL than they are if you use credit cards over the phone than they are if you just hand someone your credit card and hope they can't remember what they see.
They have simply being making use of it and others.
http://www.thoughtcrime.org/papers/null-prefix-attacks.pdf
http://www.thoughtcrime.org/papers/ocsp-attack.pdf
http://www.thoughtcrime.org/software/sslsniff/
It's actually simple if you look at it from the point of view of an insider who can write or who reads code. Why do we keep seeing the same bugs in the most critical software? Buffer overflows, and other exploitable backdoors? Every hacker knows to look for buffer overflow exploits and it's not all that difficult to write the code or pay someone to write it for you. So it's just stupid to believe that by hiding the exploits that we weaken hackers. To the contrary, by hiding the bugs we make the hackers stronger because the backdoors remain secret and there is no incentive to ever fix the bugs.
Remember that bug in Ubuntu that let people remotely get root? These sorts of bugs/backdoors could be written in on purpose. A lot of people say it coming and warned them against keeping the user logged in as root, and we all know the dangers of sudo. When a buffer overflow leads to privileges then you have to wonder whether the coders made an honest mistake or whether somebody paid them to sneak in a backdoor or two. Never rule out corruption from any equation, especially in a bad economy like this one.
I had the impression that we paid money to SSL certificate providers because they provided security and identify confirmation. Maybe that was just a wrong impression.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
Never attribute to malice that which may be adequately explained by incompetence. There is of course always the possibility that someone would do this on purpose. But I still trust people who let us see the code more than those who don't.
Give me Classic Slashdot or give me death!
I've been reading about ZRTP http://en.wikipedia.org/wiki/ZRTP as it relates to VOIP. I was wondering if it might have some use for these types of problems.
I read the first article (second won't load...probably hosed by the /. effect) and it's still not clear to me why this is a big deal. Can someone explain how injecting prefixes compromises my secure datastream?
*sigh* back to work...
Go to about:config
security.enable_ssl2 - set to true
security.enable_ssl3 - set to false
Some websites, such as addons.mozilla.org require SSLv3 - you might want to create a separate profile or temporarily enable SSLv3 on those sites.
I tested a few bank websites and paypal. All accept SSLv2
Also, Firefox disables 40/64 bit and similarly weak protocols, so the SSLv2 protocol downgrade is not really as much of a problem as the SSLv3 replay attack.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
The funny part is a lot of people argue, strongly, that self-signed certs aren't any less secure than CA-signed certs.
When routing, you have a default gateway IP... no, that's wrong. You configure such a thing; but what you have is an ARP request finding the MAC of the default gateway (say 10.0.0.1 -> 00:11:22:AA:BB:CC). Not sending to the local network? Slap that MAC as the target packet; the router interface gets the packet, reads the IP, says "Hmm that's not my IP address," checks routing table, slaps a new MAC on, and transmits out the appropriate interface.
Well, if I'm at a point where I can eaves drop your packet (self-signed certs protect against eavesdropping), say on your Wifi AP, I can send a spoofed ARP response at you. Knock off your ARP table entry, replace 10.0.0.1's entry with DD:EE:FF:11:23:45 (mine). Now you'll send the packet to me; I MitM you; then I slap on 00:11:22:AA:BB:CC as the destination addr of the new packet and it routes as normal.
ALL SSL attacks are MitM attacks. An eaves drop attack is a lazy MitM that could become an active MitM if he cared. Mitigation is complex and prone to causing catastrophic breakage; in uncontrolled environments it causes breakage immediately, and in huge controlled environments (corporate LAN) it becomes impossible to reconfigure things on the fly without causing a network storm and outages-- and mistakes require manually walking to each affected machine to undo them.
Note that many people, of course, don't understand SSL. Many programmers get the implementation wrong (it supplies encryption; ignore all these weird certificate anomaly bullshits, shit's encrypted so it's fine). Users don't know what they're worrying about. Notice further that SSL is very well designed, but on like version 4? (SSL3.0 -> TLS1.0) The designers are well aware that the issue is hard to understand, and that they've not gotten it quite right yet; they are, however, intelligent, and managing a pretty fucking good job.
Support my political activism on Patreon.
The difference here is that the client thinks it has a "verified" secure connection to the named host. Other SSL MiM attacks work by providing a fake certificate.
Paying taxes to buy civilization is like paying a hooker to buy love.
Most people don't use client authentication and there is typically little reason to ever configure a server to change ciphers or otherwise initiate renegotiation.
If the server does not initiate renegotiation the MITM attack does not apply! This is why there is such focus on client authentication because this is realistically the only real world case where renegotiation makes any logical sense. Sure you can dream up other scenarios where the server forces you to use a higher strenght cipher to access specific content but realistically this is nonsensical. Operators make a global stand WRT cipher strength at the site level.
TLS was written back in the day when we had low and ultra low export quality ciphers and more international encryption issues than exist today. All sane operators have since disabled these and all browsers that matter have reasonably high strength ciphers available to them mitigating any reason to renegotiate.
Yes it should be fixed.
No its not the end of the world.
Phew! 2 hours later and only 51 comments. This must not be a big deal.
Y'all had me worried there...
They just keep coming. Is the Web fundamentally, unfixably, insecure?
(That's the Web, not the Net)
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
> "Never attribute to malice that which may be adequately explained by incompetence."
this is MY line. f765ing plagiarist
-paul
And moreover, do not attribute to malice what may be adequately explained by the fact that writing bug free, let alone robust, let alone secure software is difficult.
ALL SSL attacks are MitM attacks. An eaves drop attack is a lazy MitM that could become an active MitM if he cared.
Somewhat true.
One big downside of being an active MITM is it makes it much easier to get caught. If some peice of software doesn't behave in the way you expect or maybe someone manually verifies a certificate then the tampering may be reveled. Depending on how much influence they have they may then start looking for you.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
The linked articles only discuss authentication via client certificates, which seems pretty rare currently. How does this vulnerability actually impact the "usual" web commerce usages of SSL, which involves a server certificate? Also it does not appear that there is any way to force a re-negotiation from outside. And while re-negotiation appears common for client certs, I would expect it to be somewhat uncommon for server certs except for the initial up-negotiation to a secure connection for TLS. How important is this for the common-use cases of e-commerce and banking?
WTF are you talking about?
If you actually read TFA you would notice there is NOTHING wrong with SSL. The problem is with the,
1. some servers (HTTP) using anonymous requests and responding to them in authenticated channels, as if they came from authenticated channel (SSL authentication via client cert). And yes, SSL did correct thing, it is the server that fsked up
The problem is with TLS not SSL so please don't act stupid because your advice is TERRIBLE.
Finally, connecting to bank site is secure unless your initial request does not require authentication. Most banks do that via username/password that is sent via SSL layer. That is obviously not what this MITM is doing.
So yes, EPIC fail at reading. EPIC fail in summary and EPIC fail on your advice.
PS. The patch is EPIC FAIL! Problem has nothing to do with SSL!!!!!
When a buffer overflow leads to privileges then you have to wonder whether the coders made an honest mistake or whether somebody paid them to sneak in a backdoor or two.
Well, I know what I'm buying you for a birthday gift: a lifetime supply of tin foil.
Extremely clever, I will say that. But doesn't this require that the client just plainly ignore that it is getting data from the server that it never requested? Seems somewhat odd that a client would do that, but not completely unexpected anymore.
The funny part is a lot of people argue, strongly, that self-signed certs aren't any less secure than CA-signed certs.
They are if you know what you are doing -- it is not trivial to generate an alternate self-signed certificate with the same fingerprint as the original. As to whether most people pay any attention to the fingerprint I couldn't say (I assume they don't, but I have no evidence either way), but the fact that people don't understand the system does not mean the system itself is broken.
And then there's the intermediate option that everyone just ignores -- generate your own CA and use that to generate normal certificates without paying anyone. Obviously that doesn't work for untrusted third parties, but neither do self-signed certificates.
This should be a sticky till a fix is found...
This attack might be used for bypass behavioral network filters used for blocking SSL and TLS connections.
Persian Project Management Software as a Service
You're confusing a single vulnerability with a systemic problem. When this is fixed, that's what SSL certificate providers will do again.
Don't thank God, thank a doctor!
I think it's high time that Bob and Alice kick the snot out of Marvin and Mallory. They are known troublemakers, right?
I think this blog site explains best:
http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html
Attacks based on using the MAC (or anything else related to the data link layer) require the attacker to already be on the local network segment. An upstream middle-man attacker can't do that stuff, because routers (well, sane routers anyway) don't forward anything below the network layer.
That doesn't mean such attacks have no relevance at all. The principle of defense in depth dictates that you *do* want to defend, as much as possible, against attacks originating on the LAN. But these attacks are not as prevalent or dangerous as ones that can be perpetrated from a remote or upstream system, such as the MITM vulnerability discussed in the article.
Cut that out, or I will ship you to Norilsk in a box.
> The funny part is a lot of people argue, strongly, that
> self-signed certs aren't any less secure than CA-signed certs.
It's not significantly harder for the bad guys to get a CA-signed cert than it is for the good guys. Ipso facto, CA signing does not add any significant security. It only *seems* to do so, if you ignore the question of who can get a certificate.
What does add significant security is if the client software flashes big red glowing alarm bells if the certificate changes compared to last time. OpenSSH does this. Mail clients don't and definitely should. Web browsers don't and perhaps should (although there would need to be some provision for legitimately transitioning to a new certificate without setting off said alarms, which in order to be secure would require nontrivial design changes to the way https certs are handled on the server as well as the client).
The lesson here is that application of encryption often results in an overall system that is much weaker than you might think based on the strength of the encryption itself. When you are looking at designing a secure system, selecting strong encryption can be useful, but only if you apply it in a secure way. It is my considered opinion that the use of SSL on the web adds very little security -- not due to any inherent flaw in the design of SSL, but due to the way in which https uses it.
Cut that out, or I will ship you to Norilsk in a box.
Routers are often physically point-to-point, connected either to a network segment with exactly 1 router on it or directly to another router. Physically eaves dropping across these links is impossible.
In any other layout, you've got a router plugged into a switch. ARP spoofing can break the switch, in no greatly useful way. Still, the routers are configured (I've done this) in the same way as hosts: the next hop is a network address, which they ARP for the IP address of (unless you add a static ARP table, which can be done, but nearly nobody bothers).
Upstream attacks that aren't at either endpoint have little relevance because physical topology barely allows for them.
Support my political activism on Patreon.
Show me an example of a PGP failure.
What password of random characters can you actually store in your mind and how many? If anyone actually has access to your machine then all your passwords are useless. Assuming your passwords cannot be cracked is silly. The smartcard removes the need to enter a password into a machine, this prevents remote users from using a software keylogger.
Passwords are why everyone is so easy to hack today. Nobody picks a secure password because those passwords cannot be remembered, and the passwords which can be remembered can usually be cracked. Smartcards are as secure as credit cards, passwords aren't very secure because you have to type them into a computer and thats writing it down for everyone to see.
Individuals who base their worldview on the assumption that the world is not a corrupt place are always shocked by financial collapses, or corrupt politicians, or corrupt cops. When are you going to figure out that people are inherently selfish, inherently corrupt, and they aren't looking out for your best interest?
Yes some are incompetent, but if there is financial incentive to be corrupt then you should consider the possibility of corruption based on the amount of incentive and not on any assumption.
And you didn't listen, because you focused on our tin foil hats. Good luck.
For well structured secure apps, a one-way hash token check would prevent this problem. That is, if session hash-check fails, drop connection from client end. Granted this won't work for pure ssl html apps. Maybe session hashing should be built into the protocol???