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

Re: Semantics of HTTPS

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Thu, 13 Sep 2012 09:30:31 +0100
Message-ID: <505199A7.3070605@cs.tcd.ie>
To: Willy Tarreau <w@1wt.eu>
CC: 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>

Hi Willy,

On 09/13/2012 06:47 AM, Willy Tarreau wrote:
> Hi Mark,
> 
> On Thu, Sep 13, 2012 at 03:06:24PM +1000, Mark Nottingham wrote:
>> I haven't seen any more discussion of this. 
>>
>> Being that both the TLS WG Chair and at least one security AD have both
>> unambiguously said that it should be considered an e2e protocol (please
>> correct if I'm wrong), we return to the original question --
>>
>> Should we state that the HTTPS URI scheme implies end-to-end security (i.e.,
>> between the user-agent and the origin server)?
> 
> I have thought a bit about the arguments made in favor of this and my
> opinion has evolved on the subject. I think that we should probably keep
> the https scheme as "end-to-end" so that the user is sure about this,
> but in this case we'd need another scheme for the https from proxy to

Do you mean another URI scheme?

That might be a way forward since it'd allow both ends (UA, site)
some choice in whether they'd allow middlebox snooping.

> origin server that browsers would switch to for a given site when the
> proxy would refuse access. Basically it would look like this :
>   - user types https://forum.example.com/ in his browser

But that uses the https URI scheme, that we just agreed is
defined to have e2e security properties. I'm confused now.

>   - 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?

Cheers,
S.

> And the benefit of the alternative scheme is that non-browser clients could
> easily be configured to make use of it (eg for automatic software updates,
> etc...).



> 
> Regards,
> Willy
> 
> 
> 
Received on Thursday, 13 September 2012 08:31:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 September 2012 08:31:21 GMT