- From: イアンフェッティ <ifette@google.com>
- Date: Mon, 2 Apr 2012 07:52:06 -0700
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: ChanWilliam(陈智昌) <willchan@chromium.org>, ietf-http-wg@w3.org, Peter Lepeska <bizzbyster@gmail.com>
- Message-ID: <CAF4kx8dt=2m6viL_6Hf8OAj1v7RzYBVS38wSt6WV28DY6KZWpQ@mail.gmail.com>
I didn't mean to suggest that. Rather, I was responding to your assertion
that "But the basic HTTP-router just needs to figure out which
webserver this goes to and the primary criteria seems to be:
Host: / URI pattern match / session-cookie"
What i was getting at is that if your "http router" is also doing SSL
termination, it's keeping an SSL context around and doing nontrivial
operations on the data already, at which point I'm not sure of the
tradeoffs involved in trying to pull "routing" information further up.
As for creating multiple SSL contexts for each "stream" / "channel" in the
über TCP connection, now on the client you're keeping multiple SSL contexts
around, not clear what you are proposing for compression contexts, and
whether that involves additional roundtrips, etc.
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...
On Mon, Apr 2, 2012 at 7:36 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:
> 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:52:35 UTC