- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 13 Sep 2012 07:47:57 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Eric Rescorla <ekr@rtfm.com>, "Adrien W. de Croy" <adrien@qbik.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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
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
- 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.
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 05:48:27 UTC