W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: multiplexing different hosts on a single SSL connections

From: Safruti, Ido <ido@akamai.com>
Date: Fri, 8 Jun 2012 02:08:34 -0500
To: Roberto Peon <grmocg@gmail.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <CBF6F1CF.37733%ido@akamai.com>
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<mailto:grmocg@gmail.com>>
To: Ido Safruti <ido@akamai.com<mailto:ido@akamai.com>>
Cc: "ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>" <ietf-http-wg@w3.org<mailto: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.


On Thu, Jun 7, 2012 at 7:07 PM, Safruti, Ido <ido@akamai.com<mailto:ido@akamai.com>> wrote:
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
Received on Friday, 8 June 2012 07:09:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:00 UTC