9 ms·
SSL broken. (TLS 1.0 cryptographic attack that works. Not just fake certs.)
- 0x12 15y agoWhat are the practical consequences of this?
- deleted 15y ago[deleted]
- lars 15y agoSomeone 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 15y agoNot 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.
- iam 15y agoHow exactly would you sniff traffic between an encrypted site and the browser, without running JS in that encrypted site, or without exploiting the browser (in which case you already won and don't need need to break SSL)? Is this some sort of man-in-the-middle hybrid that uses JS as an attack vector?
- marshray 15y agoMy understanding is that it is indeed a MitM leveraging Javascript. However, it seems likely that other variations may surface as more people start to think about it.
- biot 15y agohttp://en.wikipedia.org/wiki/Chosen-plaintext_attack http://en.wikipedia.org/wiki/Chosen-plaintext_attack Let's say an ISP in an oppressive country is hooked up to a government system which sniffs all traffic. It's able to record all your SSL traffic but is unable to decrypt it since it doesn't know the session key that was used for encryption. At the same time you're browsing on the SSL-secured site, you're also using a site which isn't SSL-secured in another tab. The ISP can inject the unsecured site with specially crafted javascript for your browser to execute. This javascript fetches data from the SSL-secured site using specific known plaintext[0] and the ISP records the resulting traffic. Presumably this separate tab would not have to renegotiate the SSL handshake from scratch, thereby reusing the previously randomly generated session ID.[1] By doing this very deliberately with specially chosen plaintext, over time you have enough data to reverse engineer what key was used to encrypt the data. [0] I'm guessing it takes the form of a GET request to non-existent resources. You know part of the input, and the resulting 404 page is almost always the same so you know part of the output. [1] http://en.wikipedia.org/wiki/Transport_Layer_Security#Resumed_TLS_handshake http://en.wikipedia.org/wiki/Transport_Layer_Security#Resume...
- deleted 15y ago[deleted]
- kijin 15y agoIf 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.
- willvarfar 15y agoIf 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.
- redthrowaway 15y agoHow 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?
- caf 15y agoPresumably the injected code creates specially crafted requests to the SSL site being attacked - it can't read the results of those requests, but that doesn't matter: its only purpose is to create some adaptively-chosen known plaintext for the sniffer.
- dekz 15y agoTLS(SSL) broken != Browser Exploit Against SSL/TLS (BEAST). Please change the headline.
- willvarfar 15y agoIt 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.
- dekz 15y agoThis attack could only be potentially practical against web browsers, not other applications implementing TLS.
- aclimatt 15y agoThey claim to also be able to perform the attack on other applications using TLS (such as VPNs), not just web browsers.
- dekz 15y agoQuite possibly, but this is about BEAST and the ability of loading malicious Javascript. Performing the feat of code injection on a non-browser application is something completely different. If something is injecting code into your native application or throwing known plaintext into your socket streams then you've already been compromised.
- dfox 15y agoYou don't need to inject code, you need to inject traffic. Injecting code into client is only one way to do that. For example in many VPN deployments you can inject traffic into secure channel directly.
- pnathan 15y 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.
- aclimatt 15y agoHere's a little more explanation on how it works: http://threatpost.com/en_us/blogs/new-attack-breaks-confidentiality-model-ssl-allows-theft-encrypted-cookies-091611 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 15y agoWe 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 15y agoDid 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 15y agoBut 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.
- deleted 15y ago[deleted]
- onedognight 15y agoIt 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 http://permalink.gmane.org/gmane.ietf.tls/8822
- burgerbrain 15y agohttp://twitter.com/#!/moxie__/status/115865331687370752 http://twitter.com/#!/moxie__/status/115865331687370752
- moxie 15y agoNo 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.
- marshray 15y agoI 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 15y agoI 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...?
- marshray 15y agoDuong and Rizzo have a proven track record. The demo is scheduled for Friday http://www.ekoparty.org/2011/juliano-rizzo.php http://www.ekoparty.org/2011/juliano-rizzo.php
- moxie 15y agoMaybe, 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.
- licketysplit 15y agoAnyone know if what netty uses by default or SSLServerSocket are vulnerable? The article says SSL > 1.0 is ok.
- agl 15y agoI 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'.
- marshray 15y agoBut http://eprint.iacr.org/2006/136 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'?
- alecco 15y agoThis 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 https://payment.com and headers using XMLHTTPRequest.setRequestHeader() for the known plaintext.
- jacques_chester 15y agoThe 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.
- deleted 15y ago[deleted]
- sunyc 15y agoI don't understand how this works, different site will have different SSL connections, injecting a js to file a SSL request with known plaintext only shows you key in that connection. It won't affect your proxy, because each site has a CONNECT tunnel which is not related to each other. Unless of course, you are using a openvpn like all your traffic go through single ssl socket, where it can be easily fixed by just have multiple socket open and cycle among them
- caf 15y agoThe underlying vulnerability in TLS1.0 is described here: http://www.mail-archive.com/openssl-dev@openssl.org/msg10664.html 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 15y agoi think this is the original paper: http://eprint.iacr.org/2006/136 http://eprint.iacr.org/2006/136
- caf 15y agoNote that the mail I'm quoting is from 2002, predating Bards paper by several years.
- asdfaoeu 15y agoI 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.
- caf 15y agoThe 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.
- itsnotvalid 15y agoAs 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 15y agoOh, 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.
- schiptsov 15y agoHey, it is browser's vulnerability - insufficient data separation between windows/frames. Face some reality - there is no problem in protocol or its implementation.)
- wladimir 15y agoThis is scary. Would this also affect SSH (which uses OpenSSL) and SSL-based VPNs? Or is it specific to SSL in the browser?
- dramaticus3 15y agoThat'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 15y agoRequestPolicy 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 15y agoIt 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 15y agoThe attack works in such way: 1. A user opens any HTTP website like http://google.com/ 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/ 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 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/ 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/ 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/ 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 15y agoSo 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.
- caf 15y ago
- xtacy 15y agoAs 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 http://tools.ietf.org/html/rfc4346#ref-CBCATT
- peterwwillis 15y agoAnother 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:// 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 15y agoI think Strict Transport Security does more or less exactly what you're asking for: http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02 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.)
- peterwwillis 15y agoThis 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 15y agoRss What's that and how do I make the phone stop talking out loud
- elke-park 15y agoThe government can seem to do everything else but they can't stop this yeah right . Sometimes this government really ticks me the f... Off.