Chrome shows sites as secure when they are vulnerable to DROWN
Reported by
robmos...@gmail.com,
Apr 7 2016
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36 Steps to reproduce the problem: 1. Connect to a site via HTTPS which is vulnerable to DROWN (e.g. https://sports.ladbrokes.com/en-gb/ ). 2. Check the padlock in the address bar. 3. Click the padlock and check the information in the Connection tab. 4. Click the Details link and check the information presented. 5. Check the website using the SSLLabs scanner ( https://www.ssllabs.com/ssltest/analyze.html?d=sports.ladbrokes.com ). 6. Check the website using the DROWN Attack scanner ( https://test.drownattack.com/?site=sports.ladbrokes.com ). What is the expected behavior? The expected behaviour is that Chrome should present a warning informing the user that the website is insecure and that their information and privacy is at risk. What went wrong? Every bit of information Chrome presents to the user tells them that the site is secure and that their information is safe. This is not the case. Did this work before? No Chrome version: 49.0.2623.110 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 21.0 r0 A near-trivial attack exists when the server is vulnerable to CVE-2016-0703, which this server is. I guess it should be sufficient to implement something similar to the HSTS Preload list, where certificates with a blacklisted hash would cause the "Your connection is not private" message to appear.
,
Apr 7 2016
Chrome can only 'reason' about what it can observe directly. Enriching Chrome's observations by keeping a list of sites that the DROWN scanner has flagged wouldn't be an obvious win, since it would get out of date and stay out of date, almost immediately. Finally, it's not obvious what we could, with high confidence, tell the person using Chrome.
,
Apr 7 2016
Couldn't we at least alert the user if the server is vulnerable to CVE-2016-0703 or advertises SSL 2.0 or 3.0-with-CBC? That's easy enough to do surely from the handshake?
,
Apr 8 2016
That's not how TLS works. Client offers and then server chooses. If a server supports TLS 1.2 with AEAD but also supports, say, 3.0-with-CBC, the only way to find out is to send an SSL 3.0 ClientHello and only enable CBC mode ciphers. We'd have to go out of our way to implement separate probing connections (costing network resources and performance) for each new and exciting vulnerability that comes up. Also note that, for 3.0-with-CBC, Chrome's connection is not impacted by the server enabling this. We've long disabled SSL 3.0. DROWN-related issues is a different matter and does indeed impact modern clients. But so does a server which secretly posted their private key online, but we're not going to crawl the web for private keys before accepting a TLS connection.
,
Apr 8 2016
,
Apr 8 2016
OK. The message at least should change then. Chrome shouldn't tell a user their data is definitely secure if that's not necessarily the case.
,
Dec 9 2016
Security>UX component is deprecated in favor of the Team-Security-UX label |
||||
►
Sign in to add a comment |
||||
Comment 1 by kenrb@chromium.org
, Apr 7 2016Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Feature
Owner: rsleevi@chromium.org
Status: Untriaged (was: Unconfirmed)