Man-In-the-Middle Vulnerability For SSL and TLS 170
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."
We need to invest in Quantum Physics. (Score:5, Funny)
Only with quantum physics can we actually get a secure data transfer. Or not or both.
Re:We need to invest in Quantum Physics. (Score:5, Funny)
Re:We need to invest in Quantum Physics. (Score:4, Insightful)
What will really irritate quantum physicists in this instance is that, unfortunately, the joke is both funny and unfunny at the same time. The state of the joke relies upon the opinion of the observer, not any quantum juxtaposition.
In fact, I'm not so sure this is related to quantum phy... Oh.
Re: (Score:2)
It has destroyed the alternative states, yes. But it has created a separate universe for everybody!
So now we all run our very own instances of the universe.
Who am I telling this... you could just be imaginations of my mind... and if not, you are now in MY universe anyway! :D
Re: (Score:2)
So now we all run our very own instances of the universe.
You've shifted into philosophy, my friend.
Solipsism [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
Re:We need to invest in Quantum Physics. (Score:4, Funny)
Damn you, Quantum Physics!! [angryflower.com]
Re: (Score:2)
We know it's funny, we just don't know exactly how funny it is.
Re: (Score:2)
Come on moderators, its a joke - Yes, I realise its both funny and not funny at the same time.
Before reading it, I thought your post might be funny. But my twin brother saw it first and didn't find it funny, which determined my state.
Re: (Score:2)
Re: (Score:2)
And what exactly is a Man In The Mirror attack?
I don't know, but it probably involves a "special underwear" [ew.com] 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?)
Re: (Score:2)
The funniest part of your post is the (Score:0, Funny)
GrpA
Its a quantum man in the middle attack (Score:5, Funny)
Its the same man in all 3 places.
Re: (Score:2)
Just like DRM, then? ;-)
Re: (Score:2)
I died laughing when someone opened the box.
Re: (Score:2)
Funny... but as I understand it... one mode of QM communications only allows for 100% detection of an intercepted communication, not specifically unbreakable ciphers.
oh joy (Score:1)
More cyber terror :)
Re: (Score:3, Insightful)
Re:oh joy (Score:5, Insightful)
Millions of ordinary people didn't know there was a vulnerability until now. Who knows how many bad guys knew already though?
Knowing of a potential vulnerability allows people to alter their behaviour if they deem that an appropriate response. Systems administrators can examine setups to see if they can use other methods to secure communications and it also allows all those who have written applications to examine their code.
I'd rather know of a vulnerability and respond, than not know while others are potentially exploiting it.
The false belief of security through obscurity. (Score:2)
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
Re: (Score:2)
Ah yes, the authentication piece - the secret that only you and I know. (inaudible whispering)
The secret that only the two of you know, until I get my high-sensitivity microphone into the room. Any non-trivial sharing must go through a medium that allows interception by third parties.
And of course, never underestimate the password-obtaining ability of a $5 wrench.
Re: (Score:2)
It doesn't matter how many may have known. What matters is if it was ever used. And once it is, it doesn't take too long to track down where the hole in the security system is...
Re: (Score:2)
Millions of ordinary people didn't know there was a vulnerability until now.
Dear Ordinary Person,
As you may have heard in the media, there has been an exploit discovered in the security protocols used in the banking sector. As such, we require you to log on and reset your password. Please click on this link [notreallyyourbank.com] and enter your security details there. Please ignore any certificate warnings that you might see, they are unavoidable while we implement a more secure protocol.
Sorry for the inconvenience
Bad Guy^H^H^H^H^H^H^H Yourbank
Re:oh joy (Score:5, Informative)
I wouldn't be so sure on that, anyone can read a mail-listing Ill quote this from Marsh Ray on the ietf mail list:
I can confirm the severity of the TLS MITM bug. I've had a working
exploit going since the end of August.
Steve Dispensa and myself put together (with help of many of course) an
industry working group to address it. I think we were successful in
producing a preliminary fix, which vendors are in various stages of
testing and deployment.
We'd agreed to responsibly delay disclosure to give the industry time to
coordinate the fix.
web developers (Score:1, Funny)
Re: (Score:2)
"So are these man in middle exploits fixed in the latest Ubuntu release ?"
No, they've just changed the name to "koala in the middle" exploits.
We need (Score:2)
Re: (Score:2)
In Antwerp, I would think.
Dissabling SSL re-negotiation? (Score:4, Insightful)
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
Re:Dissabling SSL re-negotiation? (Score:5, Informative)
Re: (Score:3, Insightful)
> The second situation occurs ALL THE TIME in web services that require
> different levels of trust for different content within the same site.
Don't do that.
Re:Dissabling SSL re-negotiation? (Score:5, Informative)
"But let me ask this : who would ever require SSL renegotiation in practice?"
from,
http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html
SSL renegotiation is useful in the following situations, once you have established an ordinary SSL session:
* When you require client authentication
* When you are using a different set of encryption and decryption keys
* When you are using a different set of encryption and hashing algorithms
The last two are kind of useless in practice. The first one is very useful to authenticate the client. Actually, if this is the only way to verify client cert, then SSL renegotiation is vital part of SSL.
Re: (Score:2, Informative)
Umm, you want to rotate your block ciphers on long-running connections. Saying this isn't useful in practice implies that you must reset connections and recover at the application level instead, or risk using the same block ciphers for too long.
Re: (Score:2)
Umm, you want to rotate your block ciphers on long-running connections. Saying this isn't useful in practice implies that you must reset connections and recover at the application level instead, or risk using the same block ciphers for too long.
Exactly. I was going to say the same myself.
Re: (Score:2)
Re: (Score:2)
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.
Client certificates need this.
Re: (Score:2)
Re:Maybe because the "hackers" are writing the cod (Score:4, Informative)
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.
Assuming people are noble is why you got Enron. (Score:2)
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.
Re: (Score:2)
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.
We warned you about the mortgage crisis. (Score:2)
And you didn't listen, because you focused on our tin foil hats. Good luck.
Use PGP/GNUPG auth (Score:2, Insightful)
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?
Re:Use PGP/GNUPG auth (Score:5, Insightful)
Let the user [...] be responsible for their own security
Yes, because as all of the botnets have shown, that works so well in practice.
Re: (Score:2)
When have we given the user the choice to have an operating system not vulnerable to botnets? They don't get a choice. And let's be realistic, botnets are offtopic.
Re: (Score:2)
Note that using a smartcard in this case would not help you. Smartcards provide a protected place to put your keys and do "private" stuff (like signing) but all the same protocols are usually used on top of that (including SSL/TLS).
I doubt GNUPG Auth is without fault itself. It's really hard to do security and crypto stuff correctly. Really, really hard as even the best mathematicians, theorists and developers in the world get caught out all the time.
When has PGP failed? (Score:2)
Show me an example of a PGP failure.
Re: (Score:2)
That will not happen, because there is no money in it. Tunnelling over ssh has the same problem.
Re: (Score:2)
You are clearly confused. This is about a flaw in the SSL protocol, not a flaw in X.509/PKI. The only real difference between PGP and X.509/PKI is in key management. Using PGP's extremely expensive, time-consuming, and error-prone key distribution method is the reason PGP is going extinct. Your grandma will never go to a key-signing party.
Another thing you are confused about: smart cards? What? What do they have to do with anything? Smart cards typically use X.509, not PGP. And in this case, smart cards wou
Re: (Score:2)
How would a smartcard ever be less secure than a password?
The problem is SSL. Did you do your research as to what GNUPG auth is? Sure it does not replace all the functions of SSL, but SSL if it's this broken isnt really much better. I think there should be an alternative to SSL so that SSL actually has reason to improve. If you only offer one crypto protocol and one set of options then what do you expect?
Re: (Score:2)
Because you haven't understood security at all!
Smartcards still need a password, or they are no more secure than a fingerprint (cut off the finger) or a credit card (buy something immediately after stealing it).
Passwords alone of course a also not great. But at least nobody can steal a password that is stored only in your mind.
What password is that? (Score:2)
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 remem
Re: (Score:2)
Who is they? The mafia?
If they are in position to torture you, whatever secrets you have is probably not worth more than your life.
Re: (Score:2)
SSL/TLS, used properly, doesn't just authenticate one end of the connection.
Of course, SSL/TLS is usually not used properly.
Wrong Impression? (Score:3, Insightful)
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.
Re:Wrong Impression? (Score:5, Insightful)
You pay money to certificate providers so that your customers won't be frightened away by scary browser warnings.
Re: (Score:2)
Re: (Score:2)
The warnings work well enough to cost you more than than price of the certificate.
Re: (Score:3, Insightful)
> You pay money to certificate providers so that your customers won't be
> frightened away by scary browser warnings.
Which they get anyway....and next ignore. Yippie Skippy!
While the SSL crypto part is pretty neat, I always felt the commercial CA
thing is one of the biggest money-making rip-off's in the entire IT field.
Nor do I believe it to be secure or "trust" it. We always assume MITM's to be
someone without access to the CA's themselves. Frankly, the people I worry
more about are those, that DO have a
Re: (Score:2)
Indeed. GPG and SSH have workable trust models. Not perfect, but workable. The model in TLS is just wrong. Anything which requires me to trust the (hopefully merely incompetent) people working for Verisign is a loss.
And they do. (Score:2)
You're confusing a single vulnerability with a systemic problem. When this is fixed, that's what SSL certificate providers will do again.
How does this compromise SSL? (Score:2)
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?
Re: (Score:2)
Re: (Score:2)
Let's say you are paying your mortgage, putting in your bank account information for a transfer. An attacker could inject additional HTML (Javascript, etc.) that sends your response to the attacker's server instead of the mortgage company's server, compromising your account info.
Or a simpler attack would be the bank's online banking login page: again, inject additional HTML to the bank's response, and now you submit your username/password to the attacker's server.
Re: (Score:3, Interesting)
Actually, this isn't true. This attack only allows for injecting data into the request from the client to the server. The attacker doesn't even get to see the result, much less modify it.
Basically, the only thing the attacker gets is the ability to make the client's browser request whatever the attacker wants. You know, the kind of thing you could do with a simple injected IMG tag.
Re: (Score:3, Informative)
Basically, the only thing the attacker gets is the ability to make the client's browser request whatever the attacker wants.
Oh, is that all? So for example, you can serve something that looks like my bank's home page but originates on your server.
Then when I enter my user name and password your server collects them, and if you're feeling particularly clever redirects me back to my bank's real site. Now you have access to my account, and I'm none the wiser.
This is far more serious than image loading, becau
Re: (Score:3, Informative)
Erm, no, you're getting it wrong. What this attack means is that the attacker gets the ability to make arbitrary requests for resources on behalf of the user.
So no, it doesn't mean that the attacker can now serve you malicious web pages that will appear to be coming from your bank's web site. What it does mean is that once you go to a secure page on your bank site, the attacker can instruct the bank to transfer money from your account to his, without you ever knowing. This is kind of similar to the IMG tag
re: How does this compromise SSL? (Score:2, Informative)
You're right, this isn't a big deal. What they're describing is essentially a very complicated CSRF. The upshot is that you can get the user's browser to visit a URL of your choosing, but you can't see the results from that page. Sound familiar? That's because all you'd have to do is embed an IMG tag in some HTTP that the user is getting back in order to accomplish the exact same thing -- no fragile renegotiation attack required.
Thank you security industry for all the hype.
Re: (Score:2)
The key difference is that with IMG tag the attacker can only get the user's browser to make GET requests, whereas this attack enables POST requests as well. Any reasonably well-designed online banking application should not be exploitable via GET requests.
Also, the attack vector here is different compared to a "regular" CSRF through XSS. Which one is more practical is open to debate.
Re: (Score:3, Informative)
POST
content-length: 20
< xml >< orderafrog number=1/ >< address > my address <
And converts it to:
POST
Re: (Score:2)
So it's really not that big of a deal for HTTPS. Attacks exactly like that already exist, they are called cross site request forgery. However this is a significant attack against other SSL wrapped protocols.
Re: (Score:2)
That said, there aren't that many case where this can be exploited really.
Re: (Score:2)
As Admiral Kirk taught us when facing Khan, when you inject prefixes over a datastream like a comm channel to another Starfleet vessel, you can take command of their consoles and lower their shields.
Re: (Score:2)
goodness (Score:2)
Phew! 2 hours later and only 51 comments. This must not be a big deal.
Y'all had me worried there...
Re: (Score:2)
I think it's more that most of us don't understand this stuff. I know I don't, and freely admit it.
Admittedly, I've never had to touch SSL (and if I did, you can be damned sure I'd be learning it inside out), but if I'm a web developer and don't understand it, how can we expect Joe Sixpack to?
Re: (Score:2)
It is a complex issue that has no simple/obvious solutions. That's why the usual blah is not occurring.
It is a huge thing because we used to design web services ala 'Slap SSL onto it, and traffic can not be modified and wiretapped' (assuming the server cert is right). ... as the pdf [extendedsubset.com] states, even if no client certs are involved, the current protocols and all client/server software is vulnerable, and at least some of the attack scen
That beauty of SSL, just to add a layer that will take care of it all, is gone
Another one! Is the Web fundamentally insecure? (Score:2)
They just keep coming. Is the Web fundamentally, unfixably, insecure?
(That's the Web, not the Net)
Client certificates only? is this important? (Score:5, Interesting)
Re: (Score:3, Informative)
The linked articles only discuss authentication via client certificates
Not true. From http://extendedsubset.com/Renegotiating_TLS.pdf [extendedsubset.com] :
Cases not involving client certificates have been demonstrated as well.
It is a complex issue that has no simple/obvious solutions. The current protocols and almost all client/server software is vulnerable, and at least some of the attack scenarios are not uncommon.
Re: (Score:2)
> and at least some of the attack scenarios are not uncommon.
That sentence is modded informative? Where is the informative part? WHICH scenarios? References?
Educated Guesswork link with explanation (Score:2)
I think this blog site explains best:
http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html [educatedguesswork.org]
Re: (Score:2, Interesting)
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, s
Re: (Score:2)
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.
Re: (Score:2)
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 tab
Re: (Score:2)
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.
Re: (Score:2)
Also. Toggling these flags does not require restarting Firefox.
Re:Disabling SSLv3 in Firefox (Score:5, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
I had no certainty. I was simply taking the 3.0+ in the summary at face value.
However:
http://extendedsubset.com/Renegotiating_TLS.pdf [extendedsubset.com]
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 certifi
Re: (Score:2)
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.
Re: (Score:2)
"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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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 [mistersquid.com]. 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 m
Re: (Score:2)
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.
Re: (Score:2)
According to TFA you need a server renegotiation in order to allow this injection. FAIL.
Re: (Score:2)
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.
====
Re: (Score:2)
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 ser