- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Mon, 02 Apr 2012 14:36:33 +0000
- To: ifette@google.com
- cc: ChanWilliam(???) <willchan@chromium.org>, ietf-http-wg@w3.org, Peter Lepeska <bizzbyster@gmail.com>
In message <CAF4kx8cqCiBWZz4sbXqShDzTdgggSgprdLpF3_5Beg+gQf4cFw@mail.gmail.com> , =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= writes: >I'm curious if under your definition of "http router" that box is >terminating the ssl connection and forwarding to different backends or if >you are speaking about the non-ssl case. That's actually an interesting question. One option, which I personally really like, is that we use a toplevel "container" format to do multiplexing (and possibly routing), and allow the channels to be individually TLS protected. The nice thing about this is that we can do the upgrade to TLS using the same TCP connection. A mockup would look something like: C->S GET / HTTP/1.1 ... Upgrade: http-20-tls S->C HTTP/1.1 101 Switching Protocols S->C [chan=1,msg=HTTP20-REPONSE,len=X] {200|OK|Set-Cookie: blablabla...} S->C [chan=1,msg=HTTP20-BODY,len=X] {<HTML>yaddayadda...} S->C [chan=1,msg=HTTP20-BODY,flag=FINAL,len=X] {..yaddayadda</HTML>} C->S [chan=2,MSG=TLS-SETUP,len=X] {start TLS negotiation} S->C [chan=3,MSG=TLS-SETUP,len=X] {TLS negotiation reply} ...TLS negotiation completes for chan=2 ... more unprotected objects may be pulled over chan=1 in the meantime C->S [chan=2,msg=HTTP20-REQUEST,flag=TLS,len=X] {TLS(request)} S->C [chan=2,msg=HTTP20-REPONSE,flag=TLS,len=X] {TLS(reponse)} S->C [chan=2,msg=HTTP20-BODY,flag=TLS,len=X] {TLS(body part 1)} S->C [chan=2,msg=HTTP20-BODY,flag=TLS,FINAL,len=X] {TLS(body part 2)} If we do something like that, the HTTP-router does not have to terminate the TLS in order to route the traffic, provided the routing criteria is available outside the TLS protection. But of course it is still possible to terminate the HTTP at the HTTP router if that is desirable. A variation of the above is to do the TLS setup on channel=0 and allow all channels to flag individual containers for SSL protection in that TLS session, simply by setting the TLS flag in the container, but not mandate that they do so. This would allow secure sites to limit TLS processing to those components of the webpage which actually needs it. (How that is indicated graphically to the user is also an interesting question). -- 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 14:37:05 UTC