On Wed, Mar 10, 1999 at 10:35:11AM +0100, Ralf S. Engelschall wrote
(to the sw-mod-ssl mailing list):
> On Wed, Mar 10, 1999, Juergen Rensen wrote:
>> I tried to setup
>> virtual SSL hosts on the same IP address, but Apache always returned one
>> and the same default site. Has this changed?
> No, this cannot be changed. It's the chicken and egg problem HTTP
> over SSL/TLS always will have unless the SSL/TLS protocol provides
> information similar to the Host: header of HTTP. But because that
> can be considered to be not really belong to the SSL/TLS layer it
> will be never added to TLS, I think.
I've thought about proposing an addition for the HTTP over TLS
internet draft[1] that could make this possible (although I haven't
written it down and sent it to the draft author for lack of time until
now). While the right solution would be to convert from the current
protocol to something different where the HTTP/1.1 hostname is sent in
clear before TLS starts up (and such protocols have been proposed),
for some situations a kludge might be helpful that does not change the
current protocol structure. Namely: Change the current draft that
requires that
If the hostname does not match the identity in the certificate, user
oriented clients MUST either notify the user (clients MAY give the
user the opportunity to continue with the connection in any case) or
terminate the connection with a bad certificate error.
to somethong along the lines of the following Q&D-attempt:
If the hostname does not match the identity in the certificate
or the certificate does not provide a hostname or if no certificate
is available, the client SHOULD send a "null request" that includes
a HTTP "Host" header identifying the host that it tries to connect
to. This request allows the host to demand TLS renegotiation using
a certificate matching the requested hostname. If this does not
happen, the client MUST [... error handling as in current draft
...].
Rationale: A "null request" means any valid HTTP request that does
not require the client to reveal any more data about the HTTP
request it actual wants to perform except the server hostname.
E.g., the client can send the request "HEAD / HTTP/1.1" accompanied
by the appropriate "Host" header. The client behavior described
above makes it possible to use name-based virtual hosts [RFC2068]
with TLS. However, because it is not supported by [m]any browsers
and because it causes some overhead on the HTTPS connection,
such name-based virtual hosts should be used only [... insert
appropriate warning here, I can't think of a good wording --bm].
E.g., a HTTPS server that offers public access to one virtual host
and offers restricted access to other virtual hosts might use the
certificate for the public virtual host whenever a new TLS session
is started; then most clients won't detect any unusual behavior,
and only the limited user base allowed access to the
access-restricted virtual hosts will have to use browsers that
allow the server to renegotiate by sending appropriate "null
requests".
[1] <draft-ietf-tls-https-02.txt>, which claims to be from September
1998, but which nevertheless cites RFC 2246 (published in January
1999.)
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
