- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Mon, 02 Apr 2012 15:04:35 +0000
- To: ifette@google.com
- cc: ChanWilliam(???) <willchan@chromium.org>, ietf-http-wg@w3.org, Peter Lepeska <bizzbyster@gmail.com>
In message <CAF4kx8dt=2m6viL_6Hf8OAj1v7RzYBVS38wSt6WV28DY6KZWpQ@mail.gmail.com> , =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= writes: >What i was getting at is that if your "http router" is also doing SSL >termination, The architecture right now does not allow routing without TLS termination, and that is a major bottleneck for high-traffic sites. What I tried to sketch out, was a way to allow routing without terminating the TLS session, in order to reduce the processing load on the router. This would allow deployment of HTTP routers in front of TLS certificates you don't have access to, something data centers and web-hosting companies might appreciate. >Re: which items need to be encrypted, on an HTTPS page, everything on the >page needs to be encrypted, so there's really no signaling involved... I agree that with respect to man-machine interface, that is probably the correct starting point. But I can imagine a lot of situation where a more granual approach would work better: Get http://video-on-demand.example.com/ redirects to TLS protected login.example.com user logs in on TLS protected page user picks video on TLS protected page, get DRM key back. DRM protected video is streamed without TLS protection. The actual video might even come from a different server than the TLS session, if a HTTP router was deployed, but the client still sees just one TCP connection. But as I said: There is a lot of clarity to be had with an all-or-nothing approach to TLS. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 2 April 2012 15:05:05 UTC