Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Man-In-the-Middle Vulnerability For SSL and TLS

Soulskill posted more than 4 years ago | from the alphabet-soup dept.

Security 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."

cancel ×

170 comments

Sorry! There are no comments related to the filter you selected.

We need to invest in Quantum Physics. (4, Funny)

jellomizer (103300) | more than 4 years ago | (#29994474)

Only with quantum physics can we actually get a secure data transfer. Or not or both.

Re:We need to invest in Quantum Physics. (5, Funny)

PiSkyHi (1049584) | more than 4 years ago | (#29994530)

Come on moderators, its a joke - Yes, I realise its both funny and not funny at the same time.

Re:We need to invest in Quantum Physics. (0, Funny)

Anonymous Coward | more than 4 years ago | (#29994610)

Most of the mods here wouldn't get an intelligent joke if it came up and kicked them in the face.

It'd have to kick them in the nuts to be low-brow enough for them to notice.

Here is a good joke (0)

Anonymous Coward | more than 4 years ago | (#29994650)

Wasn't the man in the middle attack the subject of a Michael Jackson song?

Re:Here is a good joke (0)

Anonymous Coward | more than 4 years ago | (#29995072)

That was "Man in the Mirror"

Re:Here is a good joke (1)

tom17 (659054) | more than 4 years ago | (#29997070)

And what exactly is a Man In The Mirror attack?

Re:We need to invest in Quantum Physics. (3, Insightful)

L4t3r4lu5 (1216702) | more than 4 years ago | (#29995050)

Unfortunately, that's incorrect. By hearing (reading) the joke, you have observed its state. This has destroyed the alternative quantum state of the joke.

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:We need to invest in Quantum Physics. (3, Funny)

mcgrew (92797) | more than 4 years ago | (#29995426)

Damn you, Quantum Physics!! [angryflower.com]

Re:We need to invest in Quantum Physics. (1)

Jurily (900488) | more than 4 years ago | (#29996394)

We know it's funny, we just don't know exactly how funny it is.

Re:We need to invest in Quantum Physics. (1)

93 Escort Wagon (326346) | more than 4 years ago | (#29996622)

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:We need to invest in Quantum Physics. (0)

Anonymous Coward | more than 4 years ago | (#29994676)

I LOLed. +1

Its a quantum man in the middle attack (5, Funny)

Viol8 (599362) | more than 4 years ago | (#29994750)

Its the same man in all 3 places.

Re:Its a quantum man in the middle attack (0)

Anonymous Coward | more than 4 years ago | (#29995944)

Im in ur tubes. Confusing ur adminz.

oh joy (1)

LoneWlf (228331) | more than 4 years ago | (#29994480)

More cyber terror :)

Re:oh joy (0)

Anonymous Coward | more than 4 years ago | (#29994596)

Millions of potential exploiters didn't know about it, until now.

Thanks /.

Re:oh joy (2, Insightful)

toleraen (831634) | more than 4 years ago | (#29994652)

If the only place the exploiters were getting their info from was Slashdot, this world would be a much more secure place, and the attacks that did make it through would have more ponies.

Re:oh joy (0)

Anonymous Coward | more than 4 years ago | (#29995172)

Trojan ponies?

Re:oh joy (1)

isama (1537121) | more than 4 years ago | (#29996574)

trojan unicorns.

Re:oh joy (4, Insightful)

Albanach (527650) | more than 4 years ago | (#29994700)

Millions of potential exploiters didn't know about it, until now.

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. (1)

elucido (870205) | more than 4 years ago | (#29995086)

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.

Re:The false belief of security through obscurity. (1)

sexconker (1179573) | more than 4 years ago | (#29996808)

Uh. Password-based security is the only one that works.

Here's how security works:

Hi I'm Slashdot Bob.
Prove it.

Ah yes, the authentication piece - the secret that only you and I know. (inaudible whispering)

Ok, you're Slashdot Bob. What do you need?
I need access to Jill.

Hmmm, nope. You don't have access.
Fuck!

Hmmm, nope. You don't have access to that either.

All of our security EVER relies on maintaining a list of who has access to what, and ensuring people are who they claim to be. This can ONLY be done with secret information. A password is the closest we have to that. All physical dongles and devices can be stolen. All biometric data can be scanned and spoofed. They aren't yet able to read your mind. The fact that people forget their passwords, write them down, pass them out, or have shitty ones is their own fault.

Re:The false belief of security through obscurity. (1)

AnyoneEB (574727) | more than 4 years ago | (#29997084)

No, the user may authenticate locally (that is, within a trusted system) with a password, but a password should never be sent over the internet, even encrypted (maybe hashed with a challenge, but not just encrypted). You use public key encryption or even a zero-knowledge proof [wikipedia.org] . There does need to be a secret that the client uses to authenticate itself, but transmitting the secret, even encrypted, is a horrible idea for security as it completely falls apart as soon as there is even the slightly flaw in the encryption or server authentication.

Having the server know the password at all is a bad idea, too (bad things happen when the user uses the same password for multiple services), but it is a bit harder to avoid as, in general, the user needs a way to log in from any computer and having a file or dongle required is bad (one solution is to use a hash of the user-entered password and the domain as the password, which is basically what digest auth [wikipedia.org] does).

Re:The false belief of security through obscurity. (1)

sexconker (1179573) | more than 4 years ago | (#29997386)

All forms of authentication rely on the two parties, and only the two parties, knowing a piece of information.

There is no getting around that. Public key encryption does not. Whatever wikipedia link you provide does not.

All encryption is the same. You both need to know the decryption key. Which is why SSL and TLS fail. Which is why everything ever will fail.

Man in the middle attacks will ALWAYS be viable.
It ALWAYS boils down to a key sharing problem and an initial authentication problem. You can set up your online account in person in a locked vault and it would still have the same fucking issues.

Of course it's dumb to send a password in plaintext. Anyone could be listening. Of course it's dumb to do what SSL and TLS do - anyone could be listening. Of course it's dumb to tell someone a secret in a park - anyone could be listening.

The only thing anyone will ever achieve in regards to security is greater obfuscation and hassle for potential baddies AND for the two intended parties.

Re:The false belief of security through obscurity. (1)

Dragonslicer (991472) | more than 4 years ago | (#29997432)

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:oh joy (4, Informative)

think_nix (1467471) | more than 4 years ago | (#29994738)

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 (3, Funny)

chrisranjana.com (630682) | more than 4 years ago | (#29994486)

So are these man in middle exploits fixed in the latest Ubuntu release ?

Re:web developers (1)

bbernard (930130) | more than 4 years ago | (#29996122)

"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 (1)

jav1231 (539129) | more than 4 years ago | (#29994542)

We need someone who can eliminate these middle men! Where's Tom Shane on this??

Re:We need (1)

FauxPasIII (75900) | more than 4 years ago | (#29996510)

In Antwerp, I would think.

This vulnerability is brought to you... (0)

Anonymous Coward | more than 4 years ago | (#29994580)

...by the CIA/NSA/[insert your favorite spying agency]

No, it is not (0)

Anonymous Coward | more than 4 years ago | (#29995128)

They have simply being making use of it and others.

This is news? Come on! (1, Informative)

Anonymous Coward | more than 4 years ago | (#29994712)

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.

Re:This is news? Come on! (0)

Anonymous Coward | more than 4 years ago | (#29994918)

So you didn't load certificates or keys on your IronPort? Wow, you must have the only magic IronPort made.

Re:This is news? Come on! (1, Insightful)

Anonymous Coward | more than 4 years ago | (#29994980)

It's news in the sense that TLS provides an authentication mechanism specifically designed against this kind of attack.

Re:This is news? Come on! (1, Interesting)

bluefoxlucid (723572) | more than 4 years ago | (#29995634)

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.

Re:This is news? Come on! (1)

petermgreen (876956) | more than 4 years ago | (#29996678)

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:This is news? Come on! (1)

ArsonSmith (13997) | more than 4 years ago | (#29995774)

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.

Now the terrorists win. (0, Offtopic)

elucido (870205) | more than 4 years ago | (#29994902)

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.

Dissabling SSL re-negotiation? (4, Insightful)

AbbeyRoad (198852) | more than 4 years ago | (#29994938)

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 because the "hackers" are writing the code? (0)

elucido (870205) | more than 4 years ago | (#29995170)

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.

Re:Maybe because the "hackers" are writing the cod (3, Informative)

Hatta (162192) | more than 4 years ago | (#29995222)

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.

Re:Maybe because the "hackers" are writing the cod (1)

AbbeyRoad (198852) | more than 4 years ago | (#29996268)

> "Never attribute to malice that which may be adequately explained by incompetence."

this is MY line. f765ing plagiarist

-paul

Re:Maybe because the "hackers" are writing the cod (0, Redundant)

andrew554 (1649757) | more than 4 years ago | (#29996424)

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.

Re:Dissabling SSL re-negotiation? (5, Informative)

dopodot (1559063) | more than 4 years ago | (#29995268)

It's more than changing the cipher type, it's also negotiating up from anonymous client to verified client. The second situation occurs ALL THE TIME in web services that require different levels of trust for different content within the same site. So it's not a "seldom-used" feature in the least.

Re:Dissabling SSL re-negotiation? (2, Insightful)

John Hasler (414242) | more than 4 years ago | (#29995510)

> 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? (5, Informative)

Anonymous Coward | more than 4 years ago | (#29995656)

"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:Dissabling SSL re-negotiation? (0)

Anonymous Coward | more than 4 years ago | (#29995862)

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.

If I remember correctly, SSL renegotation was (and probably ever is) used for upgrading cryptographic strength when transaction are done with financial institutions. Encryption is/was subject to some legal restrictions in some countries, wich ones have/had some exceptions (obviously for exchanging financial or other sensible data).

Re:Dissabling SSL re-negotiation? (1)

ArsenneLupin (766289) | more than 4 years ago | (#29995894)

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:Dissabling SSL re-negotiation? (1, Insightful)

Anonymous Coward | more than 4 years ago | (#29996118)

No, SSL client auth works just fine w/o renegotiates. Only some scenarios (client auth only for some resources on the site) or implementations (a webserver made in the american north-west) use renegotiates.

Re:Dissabling SSL re-negotiation? (1)

cananian (73735) | more than 4 years ago | (#29996878)

RC4? Really?! Dude, that's totally broken -- see http://en.wikipedia.org/wiki/RC4#Security [wikipedia.org] and especially http://en.wikipedia.org/wiki/Fluhrer,_Mantin,_and_Shamir_attack [wikipedia.org] . Ron Rivest makes lots of good stuff, but all of "Ron's Codes" have been broken. (Except maybe RC6, but the AES committee determined that Rijndael was better than it.) Classic example of amateur cryptography actually resulting in a system that is *weaker* than the alternative. Le sigh.

Use PGP/GNUPG auth (1, Insightful)

elucido (870205) | more than 4 years ago | (#29994948)

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 (1)

croftj (2359) | more than 4 years ago | (#29996038)

SSL at least in the context of web browser is not only to secure our communication, but authenticate that the web site is the web site we really want to be at.

Re:Use PGP/GNUPG auth (1)

mindstrm (20013) | more than 4 years ago | (#29996676)

They are even more closely tied together than that.

Without authentication, encryption (in this context) does not provide any security at all.

Re:Use PGP/GNUPG auth (1)

DragonWriter (970822) | more than 4 years ago | (#29997148)

SSL at least in the context of web browser is not only to secure our communication, but authenticate that the web site is the web site we really want to be at.

SSL/TLS, used properly, doesn't just authenticate one end of the connection.

Of course, SSL/TLS is usually not used properly.

Re:Use PGP/GNUPG auth (4, Insightful)

schon (31600) | more than 4 years ago | (#29996532)

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:Use PGP/GNUPG auth (1)

Cthefuture (665326) | more than 4 years ago | (#29996546)

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:Use PGP/GNUPG auth (1)

the_womble (580291) | more than 4 years ago | (#29996864)

That will not happen, because there is no money in it. Tunnelling over ssh has the same problem.

Another way of MITM on NSS SSL/TLS implementation (0)

Anonymous Coward | more than 4 years ago | (#29995152)

http://www.thoughtcrime.org/papers/null-prefix-attacks.pdf
http://www.thoughtcrime.org/papers/ocsp-attack.pdf

http://www.thoughtcrime.org/software/sslsniff/

Wrong Impression? (2, Insightful)

Dareth (47614) | more than 4 years ago | (#29995190)

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? (5, Insightful)

John Hasler (414242) | more than 4 years ago | (#29995542)

You pay money to certificate providers so that your customers won't be frightened away by scary browser warnings.

Re:Wrong Impression? (1)

The MAZZTer (911996) | more than 4 years ago | (#29995956)

If phishing attacks are any indication, the scary browser warnings don't work anyway.

Re:Wrong Impression? (1)

John Hasler (414242) | more than 4 years ago | (#29996914)

The warnings work well enough to cost you more than than price of the certificate.

Re:Wrong Impression? (2, Insightful)

muckracer (1204794) | more than 4 years ago | (#29995992)

> 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 access to the CA's and are thus able to
create perfectly valid certificates at a whim for any application, incl. a
chained MITM attack. SSL is, IMHO, not in any shape safe from certain
government intrusions. Ironically, likely due to the so-called "trust" model
it employs.

Re:Wrong Impression? (1)

amorsen (7485) | more than 4 years ago | (#29997412)

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.

ZRTP (1)

cool_arrow (881921) | more than 4 years ago | (#29995242)

I've been reading about ZRTP http://en.wikipedia.org/wiki/ZRTP [wikipedia.org] as it relates to VOIP. I was wondering if it might have some use for these types of problems.

How does this compromise SSL? (1)

Dan Ost (415913) | more than 4 years ago | (#29995266)

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:How does this compromise SSL? (1)

TheNinjaroach (878876) | more than 4 years ago | (#29995330)

From what I understand, the MITM could "swallow" the original HTTP request from the client, inject their own URL (with parameters in the query string) into the request all while continuing to forward the client authentication cookies. Imagine prefixing an HTTP GET request for a poorly written webapp: GET bad.webapp.com/payment/send.php?account=12345&amount=1000000000.00 HTTP/1.1

Re:How does this compromise SSL? (1)

Burdell (228580) | more than 4 years ago | (#29995380)

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:How does this compromise SSL? (3, Interesting)

Anonymous Coward | more than 4 years ago | (#29995506)

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:How does this compromise SSL? (0)

Anonymous Coward | more than 4 years ago | (#29995880)

This is true, up until the point where the public keys get renegotiated, with the MitM running the show.

Once he has the keys to the kingdom, you are owned.

Re:How does this compromise SSL? (2, Informative)

radtea (464814) | more than 4 years ago | (#29995964)

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, because you can serve arbitarary web pages to me. As others here have pointed out, you could even serve my bank's authentic webpage but with some added javascript to just forward my username and password to you. Can you do that with an embedded image tag?

No, I didn't think so.

Re:How does this compromise SSL? (1, Informative)

Anonymous Coward | more than 4 years ago | (#29996468)

Dude, no. This attack does not allow me to impersonate any website. It does not allow me to intercept your credentials. It does not allow me to read *anything*. All it allows me to do is make your browser request a page from a *legitimate server*, without me being able to see the response. It is functionally identical to me passing you an IMG tag for a link that your browser follows. There is literally no advantage over more sane CSRF techniques.

Re:How does this compromise SSL? (2, Informative)

omuls are tasty (1321759) | more than 4 years ago | (#29997176)

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 attack but it's more difficult to defend against.

re: How does this compromise SSL? (2, Informative)

Anonymous Coward | more than 4 years ago | (#29995414)

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: How does this compromise SSL? (1)

omuls are tasty (1321759) | more than 4 years ago | (#29997270)

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:How does this compromise SSL? (1)

savanik (1090193) | more than 4 years ago | (#29995546)

Effectively, if they're between you and your server, 'click here to own this connection.'

I just talked with the resident encryption guru here - as long as the attacker is between you and the server you're connecting to, with this bug you can inject arbitrary data in front of the target encrypted packet. Some of the data you can inject includes commands, such as, 'By the way, send the rest of this connection to this IP over here, keep the authentication details but renegotiate the encryption.' In other words, 'Keep authentication but talk to the attacker's PC instead.'

Re:How does this compromise SSL? (0)

Anonymous Coward | more than 4 years ago | (#29995628)

You need to hire a different resident encryption guru, because he doesn't understand this.

Re:How does this compromise SSL? (0)

Anonymous Coward | more than 4 years ago | (#29996310)

The webserver receives the attackers request with your session cookie? SSL is not just about confidentiality but also about data integrity...

Re:How does this compromise SSL? (2, Informative)

WhiplashII (542766) | more than 4 years ago | (#29996352)

Let's say you have a web service exposed to your clients that processes orders. The error allows an arbitrary amount of data to be injected into the beginning of the client request - so the "bad guy" takes your request:

      POST /OrderTheFrogs HTTP/1.0
      content-length: 20

      < xml >< orderafrog number=1/ >< address > my address < /address > < /xml >

And converts it to:

      POST /OrderTheFrogs HTTP/1.0
      content-length: 24

      < xml >< orderafrog number=100/ >< address > evil address < /address > < /xml >

      POST /OrderTheFrogs HTTP/1.0
      content-length: 20

      < xml >< orderafrog number=1/ >< address > my address < /address > < /xml >

by using this attack to insert the evil request before yours. Now 100 items are sent to the evil address, and presumably are billed to you!

Disabling SSLv3 in Firefox (0)

Derek Pomery (2028) | more than 4 years ago | (#29995596)

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.

Re:Disabling SSLv3 in Firefox (1)

Derek Pomery (2028) | more than 4 years ago | (#29995794)

Also. Toggling these flags does not require restarting Firefox.

Re:Disabling SSLv3 in Firefox (4, Insightful)

Nursie (632944) | more than 4 years ago | (#29995900)

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:Disabling SSLv3 in Firefox (1)

Derek Pomery (2028) | more than 4 years ago | (#29996024)

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.

Re:Disabling SSLv3 in Firefox (1)

Nursie (632944) | more than 4 years ago | (#29996726)

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.

Re:Disabling SSLv3 in Firefox (1)

Derek Pomery (2028) | more than 4 years ago | (#29996996)

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 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.

Re:Disabling SSLv3 in Firefox (1)

Derek Pomery (2028) | more than 4 years ago | (#29997034)

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:Disabling SSLv3 in Firefox (1)

Nursie (632944) | more than 4 years ago | (#29997302)

"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.

Summary is WRONG! (0)

Anonymous Coward | more than 4 years ago | (#29996964)

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!!!!!

Re:Summary is WRONG! (1)

Derek Pomery (2028) | more than 4 years ago | (#29997056)

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:Disabling SSLv3 in Firefox (1)

MisterSquid (231834) | more than 4 years ago | (#29996028)

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 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.”

Re:Disabling SSLv3 in Firefox (1)

Nursie (632944) | more than 4 years ago | (#29996998)

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:Disabling SSLv3 in Firefox (1)

Derek Pomery (2028) | more than 4 years ago | (#29997090)

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.

Re:Disabling SSLv3 in Firefox (1)

Nursie (632944) | more than 4 years ago | (#29997356)

According to TFA you need a server renegotiation in order to allow this injection. FAIL.

Re:Disabling SSLv3 in Firefox (0)

Anonymous Coward | more than 4 years ago | (#29996126)

Nice thought unfortunately most sites have disabled SSLv2 long ago for security standards compliance.

Re:Disabling SSLv3 in Firefox (1)

Derek Pomery (2028) | more than 4 years ago | (#29996152)

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.

SSL is broken and the world has ended? (1, Insightful)

Anonymous Coward | more than 4 years ago | (#29995888)

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.

goodness (1)

MagicM (85041) | more than 4 years ago | (#29995916)

Phew! 2 hours later and only 51 comments. This must not be a big deal.

Y'all had me worried there...

Re:goodness (1)

6Yankee (597075) | more than 4 years ago | (#29996040)

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? (1)

John Hasler (414242) | more than 4 years ago | (#29996162)

They just keep coming. Is the Web fundamentally, unfixably, insecure?

(That's the Web, not the Net)

Client certificates only? is this important? (4, Interesting)

Xylantiel (177496) | more than 4 years ago | (#29996906)

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?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?