Re: Semantics of HTTPS

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 UTC