W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Semantics of HTTPS

From: Yoav Nir <ynir@checkpoint.com>
Date: Thu, 13 Sep 2012 13:23:32 +0300
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
CC: Willy Tarreau <w@1wt.eu>, Mark Nottingham <mnot@mnot.net>, Eric Rescorla <ekr@rtfm.com>, "Adrien W. de Croy" <adrien@qbik.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <2B20D883-2CEB-4C66-A658-052970879BFE@checkpoint.com>

On Sep 13, 2012, at 11:30 AM, Stephen Farrell wrote:

>>  - proxy says "NAK, switch to insecure mode if you want"
>>  - browser asks "Proxy can't let you go there without inspecting contents,
>>    do you agree to let it see the contents you're accessing ?"
>>  - if the user clicks YES, then the browser uses the hop-by-hop scheme for
>>    every attempt to access https://<this site> and makes it quite clear
>>    (eg: by changing the color of the URL bar).
>>  - if the user clicks NO, then no access is performed.
>> 
>> I think it can be a bit complex to implement in browsers but they're already
>> handling per-site certificate exceptions, so I don't think it would be
>> something very different.
> 
> Asking the user if they approve of a middlebox "seeing" their
> traffic seems fairly broken to me really. Why would we expect
> that'd make any sense to users?

Someone would need to run usability tests on such interactions, but this is somewhat better than the certificate issue screens that we all know and love. 

With those you get a message like "You have asked Firefox to connect securely to www.example.com, but we can't confirm that your connection is secure"

In most cases the information in this message is correct, but it's not a good indication of whether there is really an attack or whether the site administrator is just lazy. 

In the case of an explicit proxy the message can be very definite: There is a proxy called "sslproxy.example.com" that wants to decrypt your traffic. All passwords, CC numbers and personal information will be visible to this proxy. You should never accept this with an untrusted proxy. Accept/Deny?

The difference here is that the attack is definitely happening. Of course this message cannot tell the user whether the middlebox is scanning for malware, phishing for credentials and credit cards, or looking for subversion. I don't think the data we have on the certificate issue screens (that users treat them as barriers to be overcome) will definitely apply to such messages.

OTOH I wouldn't want us to standardize protocols (including my own proposal) that lead to such interaction before someone does perform a usability study to see if users will just click through or not.

Yoav
Received on Thursday, 13 September 2012 10:24:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 September 2012 10:24:52 GMT