SSL broken. (TLS 1.0 cryptographic attack that works. Not just fake certs.)

http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/

by willvarfar • 15 years ago

281 84 15 years ago

theregister.co.uk

0x12• 15 years ago

What are the practical consequences of this?

lars• 15 years ago

Someone listening in on your connection could take over your bank account session, pay pal session etc. It's unclear from the article how practical it is though, since it seems to require a JS injection on the attacked site.

JoshTriplett• 15 years ago

Not on the attacked site, no. Sounds like it would suffice to serve custom JavaScript to any unencrypted page running in the same browser, and sniff all the traffic going between an encrypted site and that browser.

kijin2• 15 years ago

If I'm reading this correctly, the attack requires specially crafted JS to be slipped into the target browser. But aren't you already screwed if third parties can slip arbitrary JS into your pages? It would be great if somebody could explain this in more realistic terms.

willvarfar3• 15 years ago

If I understand it correctly:

Someone with access to any unencrypted HTTP stream - think ISP or wifi-sharer or (especially) government or cybercriminal - can slip in javascript that, in one browser window, gives the attacker the information needed to decrypt the secure streams in other browser windows.

They do not need to find an exploit in your browser to jump from an insecure browser session to your secure sandbox beside it.

redthrowaway2• 15 years ago

How would they jump sandboxes? Wouldn't that require a browser-specific attack? For example, how would some injected code on HN jump over to my secure banking tab, in another chrome process?

chromic• 15 years ago

One of the main purposes of SSL is to prevent someone who may control the route from server to client from eavesdropping or injecting their own data, so the article assumes this situation: only the server and client are trusted. It's trivial to inject something into an unencrypted stream if you own the network, but they're saying they can slip in some arbitrary JS to an encrypted stream with about 10 minutes of work.

jroll• 15 years ago

Or decrypt that credit card number you just punched in.

rorrr• 15 years ago

If somebody injects JS into your stream, you are most likely screwed, but it doesn't mean your cookies can be stolen. Cookies can be set to HttpOnly (and should be, if you're trying to operate a secure site).

alecco3• 15 years ago

+Secure flag to block sending the cookies over plain HTTP.

ajross• 15 years ago

You're in luck! I have a Chrome extension that prevents just that. Let me send you a copy you can install for yourself...

ams6110• 15 years ago

Presumably running a plugin like noscript or disabling JS would mitigate this attack, then.

I wonder if at some point we're going to have a backlash against JS apps, which are really just the fat clients of the 1990s in a new container, as attackers discover more and more exploitable weaknesses in client JavaScript implementations.

dekz4• 15 years ago

TLS(SSL) broken != Browser Exploit Against SSL/TLS (BEAST). Please change the headline.

willvarfar3• 15 years ago

It claims to be a practical working attack, and it says they haven't found a practical solution. The title accurately reflects how I interpret the gist of the situation.

dekz4• 15 years ago

This attack could only be potentially practical against web browsers, not other applications implementing TLS.

pnathan• 15 years ago

". We present one application the attack: BEAST. BEAST focuses on SSL implementations on browsers which is HTTPS. BEAST works for most major browsers and websites."

The researchers said that the browser-based attack is just one variant. They said they also could implement a similar attack against other services that use SSL, such as instant-messaging clients or VPNs."

Please read the article before flaming it.

nknight2• 15 years ago

Please read the article linked to by the original post, not the article linked to by another commenter. The article on The Register which was linked to says nothing about VPNs or instant messaging clients.

dekz4• 15 years ago

They can do similar by sharing a SSL(only on CBC?) socket and piping known plain-text into it. This doesn't mean TLS itself is broken.

aclimatt2• 15 years ago

Here's a little more explanation on how it works: http://threatpost.com/en_us/blogs/new-attack-breaks-confiden...

They still require access to your browser to, I'm assuming, modify certain data in some way such that they can actually perform the chosen plaintext attack on the encrypted cookies.

donpark• 15 years ago

We won't know for certain until details are released but their claim that "exploit works even against sites that use HSTS, or HTTP Strict Transport Security" is disturbing.

uiri• 15 years ago

Did anyone really trust it anyways? I mean, with fake certs floating around, in order for it to really be secure you need to guarantee that the cert you got is the real cert anyways, which most people (read: average users) don't bother with.

sp332• 15 years ago

But even if we get the CA issue sorted out somehow, or even if someone really only uses trustworthy certificates, SSL is still broken. That's why this is news. It's an attack on the confidentiality of SSL which (I think) has never been done before.

onedognight• 15 years ago

It looks like it uses a chosen plain text attack that exploits the multiplexing of multiple requests over the same SSL socket level connection that by design share the same key.

More information at http://permalink.gmane.org/gmane.ietf.tls/8822

burgerbrain• 15 years ago

http://twitter.com/#!/moxie__/status/115865331687370752

moxie4• 15 years ago

No details about this attack have been made available to anyone who can publicly corroborate them, and yet the researchers are doing press interviews and speaking publicly about how they've broken SSL. I have no idea what the details of this attack are, but in my experience, when people hype an exploit for weeks before making details available, it's because the exploit isn't really very good.

I realize that the security industry is built on hype, but this is fucking dumb.

marshray9• 15 years ago

I agree their disclosure strategy pretty effed up.

Nevertheless, if BEAST is basically an exploit on the Bard attack that's been known for years, perhaps it suggests that there was an insufficiency of hype around the original publication.

skeptical• 15 years ago

I would go further and say anyone can claim they "broke" whatever system. Why do we even care about this. PoC or it didn't happen.

Also, 'SSL broken' it's a way abusive title to whatever hack relying on non encrypted http requests, javascript injection and so on.

But the real question: why do people pay so much attention to this here at HN? Why does it gets discussed as if would be given for a fact when all we have are rumors? I think people just like to talk vaguely about crypto, throwing a few concepts and hypothesis around migt be enough for many to feel intelligent...?

moxie4• 15 years ago

Maybe, we don't know. I'm guessing that @agl can't respond in detail, because he's likely bound by whatever disclosure agreement the Chrome team entered into, but he's a smart cookie and I'm inclined to trust his assessment.

I obviously have no way to know whether this is a big deal or not. These guys have a "proven track record" from the ASP.net thing, but remember that attack came after a number of less-than-earth-shattering releases from them around padding oracles in other circumstances.

pvarangot• 15 years ago

A demo is due on Friday, that's hardly a "weeks" timeframe. Browser vendors have been contacted, and and far as I've been reading details given on interviews by Juliano and Thai are straight to the point. The hyping up is being done by journalists, and by people on the security-conference biz (Dragos, i'm looking at you...), those are businesses relying on hype, not security itself.

I find you own attitude on the mater as a security researcher rather unprofessional. I beleive you are speculating hardly on this not being a serious matter, and are in fact as detail-less as the journalists hyping this up.

moxie4• 15 years ago

They've been talking about it on twitter for weeks before this.

anologwintermut2• 15 years ago

The hype is indeed a little absurd. But look at it another way: Bard's paper enumerated a very potential exploit i 5 years ago .Issues with the IV were disclosed on the openssl list 3 years before that.

For the past 8 years TLS was know to be theoretically insecure and yet the fix was not widely adopted. I would have hoped we had outgrown ignoring "academic" issues with crypto systems after the debacle with non provably secure RSA signatures in SSL/the Bleichenbacher attack that necessitated OAEP in the 90s.

Maybe the security community deservers the world it lives in where this kind of hype is acceptable and productive? Certainly it could have been avoided by paying attention to these issues in the first place.

moxie4• 15 years ago

Hah, fair enough.

licketysplit• 15 years ago

Anyone know if what netty uses by default or SSLServerSocket are vulnerable? The article says SSL > 1.0 is ok.

elehack• 15 years ago

Not SSL > 1.0 - TLS > 1.0. Big difference. TLS 1.0 is roughly the security era of SSL 3.0, perhaps even newer.

marshray9• 15 years ago

Yes, TLS 1.0 is almost identical to SSL 3.0. The name change occurred when Netscape handed stewardship of the protocol to the IETF.

agl2• 15 years ago

I happen to know the details of this attack since I work on Chrome's SSL/TLS stack.

The linked article is sensationalist nonsense, but one should give the authors the benefit of the doubt because the press can be like that.

Fundamentally there's nothing that people should worry about here. Certainly it's not the case that anything is 'broken'.

marshray9• 15 years ago

But http://eprint.iacr.org/2006/136 sure looks like a real attack to me. OpenSSL had released mitigations for it in the past but had to turn them off for compatibility reasons.

Duong and Rizzo claim to be able to work out the session cookie in a few minutes from a network level MitM and they have come through on their promises before.

How does this add up to nothing being 'broken'?

alecco3• 15 years ago

This is a very real and serious attack. The IV weakness of SSL looks very scary.

This MitM attack very feasible over wifi/corporate networks. For example, (simplifying a lot):

  * Initial shopping session example.com (HTTP)
  * User proceeds to payment stage payment.com
  * Browser with auth cookie for SSL payment.com
  * payment.com redirects to success page at example.com HTTP
  * Attacker MitM success page adding HTTP iframe to payment.com
  * Attacker serves fake iframe with JS code
  * The iframe has same-origin to payment.com
  * iframe does thousands of carefully crafted ajax/form requests to SSL payment.com
  * Optional 1: attacker snoops those requests/response to hint JS iframe
  * Optional 2: attacker blocks those requests
  * Since it's local MitM thousands of requests can be fired in seconds

The attacker could use specially crafted URLs at https://payment.com and headers using XMLHTTPRequest.setRequestHeader() for the known plaintext.

jacques_chester• 15 years ago

The iframe injection reminds me of cookiemonster.

In my understanding (I am not an expert), the attack really boils down to two high-level steps:

1. Gain a foothold in the browser to inject javascript.

2. Run a chosen-plaintext attack from that position.

anologwintermut2• 15 years ago

Fundamentally is precisely the wrong word to use here.

It may be the case that this particular attack is not an issue -- I doubt it given the authors track record -- but the paper marshray links to is an actual real issue even if this particular practical exploit of it is flawed.

Fundamentally, TLS 1.0 is not secure ( formally INDCPA II). The correct thing to do is use something that is secure. Allegedly, TLS 1.1+ fits this bill (if one trusts Hugo Krawczyk proof that assumed fresh IVs).

Anyone working on an SSL/TLS stack should be working to get this supported and should know enough to realize that supposedly theoretical issues with crypto systems can quickly become real easily (e.g, bleichenbacher's attack against ssl in the 90s)

agl2• 15 years ago

> Certainly it's not the case that anything is 'broken'.

Since others have found the links to the prior papers I don't have to worry about revealing anything by suggesting that there's prior work.

What I was trying to hint at (badly) while still giving the authors their presentation, is that there's a long history behind this. Any weaknesses in TLS 1.0 should be credited correctly (and I'm sure the authors will do so), but it makes me feel bad that it's getting lost in the coverage so far. There might be a neat demo on Friday (I don't know the details of that) but they didn't break anything themselves.

marshray9• 15 years ago

Note: I now have a draft of their paper but haven't read it yet.

I think it's open at this point that BEAST is substantially based on Bard 2004/2006. What's not clear is how much they've improved upon it. This is important for more than just assigning credit, it's important so we can decide how much resources to invest in reviewing the severity all over again.

* Rizzo and Duong have produced a working exploit. This is something Bard did not do. It's one thing to show something is possible and let the world forget about it soon after. It's another thing entirely to actually do it.

* Bard's papers, especially the first one, spends too much time talking about trojan browser plug-ins and Java applets. This minimizes the fundamental attack. Obviously a user who installs a browser plugin is pwned in far simpler ways than this.

* Rizzo and Duong have made some important improvements to the attack. It looks like Bard was heading in that direction in 2006 but did not get all the way. R&D are better at manipulating the underlying HTTP.

(Of course they need to go ahead and go public with the details already!)

willvarfar3• 15 years ago

Broken is when an attacker can decrypt your gmail without a fake cert. That's broken.

Are you saying that TLS 1.0 is not broken?

Sounds like instead you are saying that it's been broken for so long that this isn't breaking news. But "broken" as in "breaking news" is not at all how anyone parsing your initial post would grok it.

caf6• 15 years ago

The underlying vulnerability in TLS1.0 is described here: http://www.mail-archive.com/openssl-dev@openssl.org/msg10664...

Surmising from this and the scant details released: It is a chosen-plaintext attack. Requests to the logged-in SSL site are made by injected Javascript in a separate non-SSL page. By changing the length of the requested URL (easily done by appending GET variables), the authentication cookie header is pushed out so that the first unknown character is right at the end of a cipher block. This allows us to make guesses at that character, testing each guess using the method described by Wei Dai in the linked email (using another crafted request to the server). Once we've found the first character, we push the cookie one byte further back and work on the second character, repeating until we have the entire unknown portion of the cookie.

If this turns out to be somewhat accurate, a workaround could be to have the browser force the HTTP headers to be block-aligned, by inserting a dummy first header if necessary.

benmmurphy• 15 years ago

i think this is the original paper: http://eprint.iacr.org/2006/136

caf6• 15 years ago

Note that the mail I'm quoting is from 2002, predating Bards paper by several years.

asdfaoeu• 15 years ago

I think you would need to have the last unknown character at the start of the next cipher block as you would need to control the content of the cipher block directly after that.

caf6• 15 years ago

The idea is that if you force the browser to produce the ciphertext of a block like "kie: sessionid=f", where the first 15 characters are already known, then you don't have to try many candidate plaintext blocks through your adaptive-chosen-plaintext oracle to find that unknown 16th character.

itsnotvalid2• 15 years ago

As mentioned in the article, the attack only works on TLS 1.0 (and below). Now the question would be, why are we still stuck with TLS 1.0 (at least with Mozilla's NSS) and not migrated to newer versions of the protocol,

schiptsov• 15 years ago

Oh, come on. the same bullshit as openssh 0-day. Have you ever tried to imagine how many audits have been done on SSL protocol and most common implementations by all those corporations, banks, and other organizations with a lots of money and time? And how many individuals spend weeks with sources and debuggers and wiresharks? Unless you're complete idiot (who uses weak ciphers or allows re-configuration) current SSL implementations will suit you well.

wladimir• 15 years ago

This is scary. Would this also affect SSH (which uses OpenSSL) and SSL-based VPNs? Or is it specific to SSL in the browser?

dramaticus3• 15 years ago

That's what I'm trying to find out too. TLS is used in many more places than HTTPS, email for instance (my area).

    Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11])
   	(using TLSv1 with cipher AES128-SHA (128/128 bits))

mike-cardwell• 15 years ago

RequestPolicy users should be safe from this attack. The attacker can inject arbitrary javascript into a http page, but RequestPolicy will by default block that javascript from causing any cross site requests to the target https site.

Lennie• 15 years ago

It won't the JavaScript does not have to load from an external domain.

If you can inject JavaScript-code in the HTML you are just as screwed.

mkup• 15 years ago

The attack works in such way:

1. A user opens any HTTP website like http://google.com/ in Iran (for example)

2. Government-controlled Iranian ISP intercepts HTTP traffic and injects some rogue JS code.

3. Rogue JS code opens https-AJAX-connection to https://gmail.com/ and transmits some constant nonsense there (chosen plaintext attack).

4. The key point of TLS 0.x-1.0 vulnerability is deterministic calculation of IV in all sessions except first one. Initialization vector (IV) is computed using (pseudo)random numbers for the first session, and subsequent connections to the same website use new IVs computed with deterministic algorithm from previous IVs, without using random numbers.

http://eprint.iacr.org/2006/136

It's a specific form of key integrity probably intended to counteract partial MitM. Or at least that way it was thought in 1994 by Netscape.

5. Rogue Iranian ISP intercepts resulting https traffic for https://gmail.com/ and by comparing known (chosen) plaintext versus ciphertext, computes initial IV. Here is where the novelty of the research is: popular belief in 2006 was this computation requires 2^1000 operations, in 2011 it turns out that could be handled in 10 minutes [see my remark below].

6. User navigates to https://gmail.com/ to read email. Browser chooses new IV different from old one, but Iranian ISP can compute it independently because algorithm is deterministic and previous IV is known to them.

7. By knowing second IV, Iranian ISP is able to decrypt all https traffic of the second session and extract user cookies from it. (Not necessarily in real time.)

8. Now Iranian government is able to read user's email by substituting his cookies on any computer and navigating to https://gmail.com/.

You may replace Iranian govt in this story with your neighbour in public WiFi, equipped with enhanced version of FireSheep.

---

My remark: I think this is fixable on the client side and somehow related to low-entropy PRNG used to generate IV for the first TLS session.

ominous_prime• 15 years ago

So if this is a problem with subsequent IVs, wouldn't turning off SSL session caching server side mitigate the attack as well? Highly loaded servers wouldn't be able to handle this, and it degrades the experience for high-latency users, but it does force a new session on every connection.

caf6• 15 years ago

It's not session resumption that is the problem - even when TLS sessions are resumed, new connections still generate new keys. Rather, it's new requests on the same HTTPS connection (HTTP keepalive). The problematic predictable IV is at the start of each HTTPS record within a single connection.

secp• 15 years ago

This description of the attack suggests a stream of ajax requests to a site to detemine the PRNG. Does that mean that it would be possible to create rainbow tables (or equivalent) for all common implementations of the PRNGs, or certainly for targeted sites e.g. banks, PayPal etc etc?

marshray9• 15 years ago

No, it's not an attack on the PRNG in the usual sense.

One way to think about it though is that CBC mode "sort of" uses the previous ciphertext block as the output of a PRNG which is used to randomize the plaintext before it's encrypted with the block cipher. However, the way TLS 1.0 uses it, the attacker is able to learn the output of that PRNG well in advance of when it can be used. If he can choose some plaintext during that time, this adaptive chosen plaintext attack is made possible.

xtacy• 15 years ago

As people point out, at least according to this RFC, this issue should have been fixed with TLS 1.1:

http://tools.ietf.org/html/rfc4346#ref-CBCATT

peterwwillis2• 15 years ago

Another MitM attack using the browser's inability to force you to only use SSL for a given domain. We need a function in our browsers to specify domain XYZ only should use SSL. I know it sounds ghetto, but I would love to force domains matching "ssl.* . *" in my browser to only work with strong SSL on port 443 and nothing else (by default).

I know, why not just use https:// ? But it's hard to train users to act a different way and understand what's going on under the hood when they leave out a single letter in the protocol prefix. Just giving them a new address which they type in verbatim anyway seems like an easier fix. Plus, you disable all unencrypted connections for that domain and you don't need to worry about complex attacks like the current one and previous ones.

emily37• 15 years ago

I think Strict Transport Security does more or less exactly what you're asking for: http://tools.ietf.org/html/draft-ietf-websec-strict-transpor....

But besides that, as I understand it, this attack doesn't require an HTTP request to the victim site; it only requires an HTTP request to any site, followed by an HTTPS request to the victim site, so STS wouldn't be much help here unless all websites turn on SSL and adopt STS. (Though someone should correct me if I'm wrong.)

peterwwillis2• 15 years ago

This vulnerability works by injecting HTML and JS purporting to be from a plaintext version of the site being attacked. In other words, the browser has to accept non-SSL pages from the domain. If your browser just threw away all unencrypted requests for the domain this would never work. Neither would sslstrip or a handful of other tools; the improper handling of SSL certs would have an impact, however.

I could have read that draft wrong but it looks like it depends on headers from the victim site to determine if all traffic should be encrypted. MitM would defeat this.

angel122• 15 years ago

Rss

What's that and how do I make the phone stop talking out loud

elke-park• 15 years ago

The government can seem to do everything else but they can't stop this yeah right . Sometimes this government really ticks me the f... Off.

SSL broken. (TLS 1.0 cryptographic attack that works. Not just fake certs.)

Related Stories