The Pound proxy web page says that "one can not do named virtual hosts
on HTTPS, because the protocol does not support it".   This used to
be true, but necessary specification got ratified as standards track
RFC in August 2006.  Apprently it is not well known...

The RFC 4366 defines extensions mechanism on TLS, and few extensions.
One of those is "Server Name Indication", whereby the TLS client tells
the TLS server, which virtual server subsystem it is interested in.

With that extension, the server can pick a certificate from among
multiple possible certificates.

The Apache HTTPS 2.2.12 (soon to be released) and 2.3 / 2.4 series
have this TLS extension enabled in their HTTPS (TLS) codes.

All you need is OpenSSL 0.9.8j.


The specification for this was written 3 years ago, high time it gets
implemented and deployed.  Anybody familiar with the code interested
in implementing this at Pound ?



Related to this is  TLS session cache.  Running Pound proxy behind
a load-balancer will permit sessions to spread over multiple server
nodes in the Pound setup.   This can have a penalty of requiring
costly Diffie-Hellman setup of symmetric session keys every time
a new connection is formed.

One approach is to use  Distcache, and Apache HTTPD supports it, but
the distcache is not N-way redundant.  Indeed it is obvious single
point of failure.

A separate project would be to make discache into fully redundant
in-memory cache server to be usable within this kind of server
clusters.

If the session-cache does not respond within about 0.1 seconds,
wait time approaches that of new DH handshake, and should be
abandoned in favour of doing actual handshake, and then pushing
the new data to session cache.

Best Regards,

  Matti Aarnio, Helsinki

Matti Aarnio wrote:[...]

Any idea what the browser support is like?  I was under the impression 
that this wasn't really worth implementing yet because browser support 
made it a nonstarter.  But maybe that's changed?

Regards,[...]

From Wikipedia (http://en.wikipedia.org/wiki/Secure_Sockets_Layer):

"SSL v2 is disabled by default in Internet Explorer 7,[8] Mozilla Firefox 2
and Mozilla Firefox 3,[9] and Safari. After it sends a TLS ClientHello, if
Mozilla Firefox finds that the server is unable to complete the handshake,
it will attempt to fall back to using SSL 3.0 with an SSL 3.0 ClientHello in
SSL v2 format to maximize the likelihood of successfully handshaking with
older servers.[10] Support for SSL v2 (and weak 40-bit and 56-bit ciphers)
has been removed completely from Opera as of version 9.5.[11]"

I vaguely remember having to enable TLS support in IE once long ago for some
web sites ... so I think this is more accepted now that you we might think.
[...]

On Mon, Jun 22, 2009 at 12:46:46PM -0400, Dave Steinberg wrote:[...]

I found following documents enlighting in this regard:

  https://www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf
  http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Lack of browser support may or may not be important, TLS clients exist also
on machine-to-machine applications.  And for that matter:  I can hear browser
developers thinking that ignoring this feature is good choice because there
are no servers offering it...   (Just that microsoft chooses not to implement
it on all of their browser lines is great way to limit the number of clients..)
[...]

Best Regards,  Matti Aarnio