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??
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.
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.
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...
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.
Also. Toggling these flags does not require restarting Firefox.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
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.
Of course it is! This is terrible advice!
SSLv2 isn't widely used any more precisely because it's got systemic vulnerabilities. What's needed is a new revision of the protocol or the removal of the renegotiation feature.
Phew! 2 hours later and only 51 comments. This must not be a big deal.
Y'all had me worried there...
The systemic problems in SSLv2 seem less-bad than this flaw in SSLv3.
I will take the truncation of encrypted messages or attempt to downgrade the protocol (which as noted Firefox restricts anyway so it won't have much effect) any day over a replay attack.
The removal of the renegotiation and fixing of the protocol are excellent in medium-to-long-term.
But as a user, right now, I'm using banks that *will* have that feature.
Reverting to SSLv2 is the only viable option apart from doing all my finances in person.
I'm interested in seeing what your non-terrible advice is.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
I am not a developer or security expert, but I know quite a bit about Internet services (run my own LAMP server locked as tight as I can afford on a hobbyist's budget) and I do what I can.
Firefox disabled by default ssl2. In 2006, wrote a post telling users how to reenable ssl2 in Firefox. One of my main users (and my fiance) gets lots of Firefox was running into errors. So, I disabled ssl2 in /etc/apache2/httpd.conf.
And now this.
So here is my big giant “fuck off” for the Firefox engineers and managers who collectively disabled ssl2 support to encourage server admins to shut off ssl2 support, even as I suspected all cryptography at the practical level is broken.
Yeah, I know security is a process, not a product, but if this is the case, then “encourging” admins to use one version of a protocol by disabling one is just the engineering version of “I know better than you so follow my lead.”
blog
Not sure what this "most sites" is - all the banking sites I've checked so far.
(i.e. sites where SSL actually matters) worked fine w/ SSLv2 turned on and SSLv3 turned off.
So far the sites that force SSLv3 are far less crucial to me, like addons.mozilla.org.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
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
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
And your certainty that SSLv2 is not vulnerable to this same problem comes from?
And have you tried watching a session with your bank? Set up an ssl-dumping proxy and see if there are any renegotiations. I'm guessing not. This only occurs where the server needs a client certificate (not your bank) or the cipher suites are going to change (not going to happen on a "normal" TLS connection.
My non-terrible advice? It's not going to affect 99% of anything anyone does unless someone figures out a way to force the renegotiation.
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?
I had no certainty. I was simply taking the 3.0+ in the summary at face value.
However:
http://extendedsubset.com/Renegotiating_TLS.pdf
Says:
"including SSL v3 and previous"
So, I suppose that was simply inaccurate and I should have read thoroughly.
Now on to second part of your comment. If any part of the banking website supports client certificates, for any reason, it seems a renegotiation can be trivially triggered by the attacker.
Anyway, the portion:
"Not that the picture is all rosy even when client certificates are not involved. Consider the attacker sending an HTTP request of his choosing, ending with the unterminated line "X-Swallow-This: ". That header will then swallow the real request sent by the real user, and will cause any headers from the real user (including, say, authentication cookies) to be appended to the evil request."
Is a pretty severe attack as well and I don't see any safety from that one.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
Do you make your clients authenticate their SSL connections with a client-side certificate?
If not then you're probably just fine with SSLv3. Look out for patches to your server to be issued soon that either disable cipher renegotiation completely or make it a config option.
Reading up on it, it does seem to be TLS only which would suggest SSLv3+/TLS1.0+ only.
In the absence of any evidence to the contrary, SSLv2 is still the best solution, and I don't find your advice in the least bit comforting.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
My actual reading of the PDF suggests this is a TLS protocol problem only.
Thus TLS1.0+ and SSLv3+
So. Unless you can tell me SSLv2 is vulnerable, using it still seems best choice.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
And what exactly is a Man In The Mirror attack?
According to TFA, I see no reason to believe your advice is in the least bit correct.
The injection is still bad even w/o the replay attack.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
"Now on to second part of your comment. If any part of the banking website supports client certificates, for any reason, it seems a renegotiation can be trivially triggered by the attacker."
How?
The way I'm reading the vulnerability, the attacker can only gain access to the data stream AFTER renegotiation, so how does he trigger it? He can't insert traffic into the encrypted stream.
According to TFA you need a server renegotiation in order to allow this injection. FAIL.
Well, as I see it...
If he is in the middle, he just has to force you to access a client certificate portion of the bank's website.
He can do this by inserting a fetch for that data into some other request that you perform.
And you don't even necessarily have to be doing any unencrypted browsing at the same time, due to the 2nd portion of the attack, seems he can insert unencrypted headers which could do a redirect.
And of course if you *did* do any unencrypted browsing in another window, a JS payload could be used at that point to do the load of the client cert protect portion at his convenience.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
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.
From. "TFA"
(and gosh you and mr anonymous coward enjoy using "FAIL" don't you)
====
Not that the picture is all rosy even when client certificates are not involved. Consider the attacker sending an HTTP request of his choosing, ending with the unterminated line "X-Swallow-This: ". That header will then swallow the real request sent by the real user, and will cause any headers from the real user (including, say, authentication cookies) to be appended to the evil request.
====
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
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!
And what exactly is a Man In The Mirror attack?
I don't know, but it probably involves a "special underwear" packet.
(It's worse than you think: I blew the chance to use moderator points on this post just to make that joke. See what I do for you folks?)
I think this blog site explains best:
http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html
Not unencrypted, just unauthenticated. The attacker will do the initial connection in which the client is not yet authenticated. Any data send at that time should not be trusted to come from the client, including any GET requests. This is a problem when the page is in a protected domain *and* the first page is accepting information from e.g. a GET request to fill in forms and such. Then the response will be encrypted for the authenticated user only, but the attacker still could inject information to the server.
This also goes for other protocols that use the same mechanism (accepting yet unauthenticated information) and also works when key-renegotiation takes place.
There are tree ways to fix this: 1) servers should not treat the initial request information as authenticated, 2) servers should not do renegotiation and 3) fix the TLS protocol so that the initial request *can* be trusted. The last one would be the best option, but fixing a protocol takes time.
Hope that explains it.
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.