Re: Semantics of HTTPS

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

Received on Thursday, 13 September 2012 10:24:15 UTC