- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 6 Aug 2012 23:14:46 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Mon, Aug 06, 2012 at 04:06:10PM -0500, Mark Nottingham wrote: > Right. That's a big change from the semantics of HTTPS today, though; right > now, when I see that, I know that I have end-to-end TLS. No, you *believe* you do, you really don't know. That's clearly the problem with the way it works, man-in-the middle proxies are still able to intercept it and to forge certs they sign with their own CA and you have no way to know if your communications are snooped or not. > If we change that, > it's going to require a LOT of coordination with W3C, browsers, privacy > people, etc. to make sure expectations are managed, communicated, etc. That's for sure, but given that the promise offered by "https://" is not granted nowadays, I think we don't need that many convincing efforts to have something which now really reflects what's done (ie https to the proxy then https to the web site). > I think the question is here is whether end-to-end security is a fundamental > part of the semantics of HTTPS, or something that is just a de facto now, and > open to being changed later. I think it's important but then we should more clearly have an explicit "tunnel://" scheme. > Personally, I think it is; while I can see the use cases you're taking about, > having HTTPS URIs become inspectable by proxies is a surprising outcome from > a user perspective. But they're already and people don't suspect they are until they notice some random breakage they only observe at work. > Perhaps we could say something like "HTTP implies end-to-end security, unless > the user has explicitly opted out of it (i.e., in a configuration dialog). > When TLS is providing end-to-end security, the CONNECT method is used with > proxies." I really think we need a third scheme if we want to be transparent to the user. Otherwise we can have the browsers support the two modes for the https scheme and first try the tunnel, then upon failure fall back to the GET https:// if the browser policy allows it. > Just thinking out loud there... Same here :-) I believe Adrien de Croy has more experience in this area, would be nice to have his opinion here. Regards, Willy
Received on Monday, 6 August 2012 21:15:09 UTC