- From: Donald Stufft <donald.stufft@gmail.com>
- Date: Thu, 18 Dec 2014 19:54:47 -0500
- To: michael.martinez@xenite.org
- Cc: Chris Palmer <palmer@google.com>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>, security-dev <security-dev@chromium.org>, mozilla-dev-security@lists.mozilla.org, blink-dev <blink-dev@chromium.org>
> On Dec 18, 2014, at 7:44 PM, Michael Martinez <michael.martinez@xenite.org> wrote: > > On 12/18/2014 7:17 PM, Chris Palmer wrote: >> On Thu, Dec 18, 2014 at 4:08 PM, Michael Martinez >> <michael.martinez@xenite.org> wrote: >> >>> A Study of SSL Proxy Attacks on Android and iOS Mobile Applications >>> http://harvey.binghamton.edu/~ychen/CCNC2014_SSL_Attacks.pdf >> That paper describes bugs in the certificate validation procedures *of >> specific clients*. (Note that the authors call out the fact that the >> clients in question are *not* browsers.) > > Agreed. The paper only looks at mobile apps, of which only some were found to be compromised. But those of you responding with objections are completely missing the point. Google wants everyone to switch over to using secure protocols and the execution will not only never be perfect, the hackers already have sufficient information about how the SYSTEM works that they are seeking other ways to bypass the security. All they have to do is insert a rogue proxy somewhere in the middle, and they can do that in a lot of different ways. You’re missing a step here, “All they have to do is insert a rogue proxy somewhere in the middle AND either get a certificate incorrectly issued to them (really hard to do) or the client software in question needs to not properly implement TLS. In this as far as anyone is currently aware Chrome (and Mozilla, and all the major browsers) are currently implementing TLS correctly so unless someone finds a bug there (which would be promptly fixed) and the CA vendors are not currently mis-issuing certificates. > > If the browser detects a problem with the certificate, great, the user gets a warning (and about half of all users ignore them according to some research). On the other hand, when the legitimate certficate-serving resources are compromised, then what? I think that attempting to hold up improvements to one link in the chain under the guise that unless they can secure every link in the chain is boorish behavior. > > Google proposes that everyone use HTTPS, even when they are not collecting data from end-users. This will only result in more Websites being improperly flagged for poor execution. And how does that protect anyone from what is actually being done to steal user data at the access point? User data that a website collects isn’t the only purpose of TLS. What articles someone reads on a news site can also be personal information that people do not wish to have given out to anyone who is on the same coffee shop WIFI as they are. TLS also provides more than just privacy, it also provides integrity checks. This prevents people from modifying a blog post that includes instructions for installing some software and replacing them with instructions that actually install something malicious. > > We don't need to find bugs in Chrome to ask why it's necessary to force everyone to use HTTPS. What we need is a valid argument for why everyone should do that. Indicating that the connection isn’t secure isn’t forcing everyone to use HTTPS. Disabling HTTP access altogether would do that, but nobody is suggesting that. All this proposal really does is have the user agents be honest and ethically inform their users of the properties of their current connection. > > Access point security is not all about who is sniffing unsecure connections, so forcing us to use only secure connections on the pretext that it makes us all safer just doesn't work as an argument in favor of Google's proposal. > > > -- > Michael Martinez > http://www.michael-martinez.com/ > > YOU CAN HELP OUR WOUNDED WARRIORS > http://www.woundedwarriorproject.org/ > > To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Received on Friday, 19 December 2014 00:55:16 UTC