Re: Semantics of HTTPS

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.

Cheers,


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