Re: multiplexing different hosts on a single SSL connections

That is one of the ideas we've had for SPDY/4.
Specifically, with name resolution push and with cert data push, a server
could prove that it was authoritative for a domain, and prove that the
client should send requests down the connection.
Of course, name resolution push will be interesting for load balancing,
brownout avoidance, and other goodies, but... I haven't had time to write
up the whitepaper on all this yet. <rueful grin>

-=R

On Fri, Jun 8, 2012 at 12:08 AM, Safruti, Ido <ido@akamai.com> wrote:

> Hi Roberto, thanks for the note,
> I know that currently this is the way chrome works.
> However, assuming multiplexing will be part of http/2.0, and performance
> as well I am wondering if we can extend that notion.
> Can the server send a validation on an existing SSL connection to validate
> it is also good for another domain/cert.
> Obviously we would want to use another cert for the connection, so that
> you won't be able to decipher one hosts message by having the cert of
> another.
>
> Anyhow – I'll move it to spdy dev, but it looks like a TLS issue.
>
> From: Roberto Peon <grmocg@gmail.com>
> To: Ido Safruti <ido@akamai.com>
> Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> Subject: Re: multiplexing different hosts on a single SSL connections
>
> If the cert you got from the original connection matches the new host you
> wish to go to, AND the DNS resolution for that host overlaps with the IP of
> the connection you already have, then Chrome will attempt to reuse the
> connection.
>
> spdy-dev is probably a better list for discussing this, since this is a
> SPDY implementation question.
>
> -=R
>
> On Thu, Jun 7, 2012 at 7:07 PM, Safruti, Ido <ido@akamai.com> wrote:
>
>> Hi,
>> I remember reading some ideas about how to enable that on the spdy group.
>> Obviously there are different security and privacy considerations for
>> doing that, but there are some performance benefits, especially for
>> proxies/intermediate.
>>
>> I am not sure it is in the scope of HTTP/2.0 and if this mailing list the
>> right place to discuss this?
>> Is it covered/discussed as part of some other effort?
>>
>> - Ido
>>
>
>