6835904
story
Comments: 170 +- IT: Man-In-the-Middle Vulnerability For SSL and TLS on Thursday November 05, @09:23AM
background: url(//a.fsdn.com/sd/topics/topicsecurity.gif); width:59px; height:78px;
security
background: url(//a.fsdn.com/sd/topics/topicit.gif); width:75px; height:61px;
it
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."
Related Stories
leverage, n.:
Even if someone doesn't care what the world thinks
about them, they always hope their mother doesn't find out.
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.
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)
Parent
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.
Parent
Re:We need to invest in Quantum Physics. (Score:4, Funny)
Damn you, Quantum Physics!! [angryflower.com]
Parent
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.
Its a quantum man in the middle attack (Score:5, Funny)
Its the same man in all 3 places.
Parent
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)
Parent
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.
Parent
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.
Parent
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.
Parent
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.
Re: (Score:2)
That will not happen, because there is no money in it. Tunnelling over ssh has the same problem.
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.
Parent
Re: (Score:2)
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
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:3, Informative)
POST
content-length: 20
< xml >< orderafrog number=1/ >< address > my address <
And converts it to:
POST
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?
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: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.
Parent
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: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.
Parent
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)
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.
Parent
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 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)
"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.