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

Re: Semantics of HTTPS

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 13 Sep 2012 20:59:06 +1000
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, 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: <B33D2D48-52A6-46C3-9CD3-6096E0EA3F6F@mnot.net>
To: Willy Tarreau <w@1wt.eu>
We're getting off track here -- this issue is about the semantics of the HTTPS scheme, in the context of HTTPbis, not potential future work.


On 13/09/2012, at 8:23 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Thu, Sep 13, 2012 at 09:30:31AM +0100, Stephen Farrell wrote:
>> 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?
> Yes, which would be just for the browser, not for web sites.
>> 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.
> This is e2e, the user asks https for e2e.
>>>  - 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?
> Exactly for the same reason right now we ask them if they still want to
> connect to a site with an invalid certificate chain. Either they accept
> a lower security level (eg: to consult forums when looking for some info)
> or they refuse it (eg: to connect to their bank).
> This is a way to let the user decide what is done with his connection and
> to ensure that "https" in the URL bar always means e2e security.
> Regards,
> Willy

Mark Nottingham   http://www.mnot.net/
Received on Thursday, 13 September 2012 10:59:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC