Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: domain of daniel@phasevelocity.org
 designates 66.92.189.46 as permitted sender)
Subject: SSL enabled name virtual hosts
From: Daniel Rogers <daniel@phasevelocity.org>
To: dev@httpd.apache.org
Content-Type: text/plain
Date: Sun, 05 Mar 2006 18:16:46 -0800
Message-Id: <1141611406.20703.58.camel@spike.phasevelocity.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Hello all

Pardon me for being dense.

Also, I haven't searched the archives on this subject, the archive
search page was down, so I hope I am not starting a flame by rehashing
what I suspect could be a rather heated topic.


I am not convinced by the argument that name based SSL virtual hosting
is impossible.  Yes.  I understand that in order to understand your ssl
configuration you need to pick a virtual host context.  Since you don't
have the hostname the server was requested as at the time of the SSL
negotiation, you end up falling through to the default SSL host.

However, this seems like an artifact of the config file data data
organization and/or an apache implementation limitation, rather than a
limitation on the protocol itself.

For example:
Suppose  I wanted to mangle apache into doing something like name
virtual hosting for SSL enabled clients.  Here is how I envision this
being possible:

- Tell apache to listen on a new port (say, 444).
- For the default first host on port 443, I create a script, which reads
the http Host: header and then issues the exact same request on port 444
of the machine and echo's the output.
- Now create name based virtual host definitions for port 444 anywhere
you would like to have name based SSL virtual hosts.

Granted, there are some pretty serious limitations with this design.
For example:

-you would probably only want port 444 available from local interfaces
(which can be enforced with a firewall).  

-you can't create access rules based on ip address or ssl status from
within apache.

-You need to filter the response headers to keep up the facade, as it
were.  (for example, making sure you filter redirects to redirect to the
proxy script and not what the virtual host thinks it is).

-the named based virtual SSL hosts would effectively all have the
same SSL certificate.  This, however, can be dealt effectively and
completely with the SubjectAltName field of the server cert.

-numerous other issues with the documents you are serving being shown a
different port number than is actually being served.

This would have the effect that people are looking for.  One ssl enabled
host, which presents a different DocumentRoot based on the Host: http
header.  The code to do this would only be a few hundred lines in php or
perl, if you rely on an already existing http request class.

However, I don't see why this couldn't be implemented in apache, and
remove all the limitations I mentioned above, except for the need for a
certificate with a subjectAltName. For example, suppose you have a
second name virtual host style configuration directive that
looked something like:

<SSLNameVirtualHost *:443>
/all ssl options here/
</SSLNameVirtualHost>

Then, instead of picking a virtual host definition in order to be able
to negotiate the SSL session, the SSLNameVirtualHost statement would
have all that it needed to negotiate the SSL session, then, after the
SSL session is negotiated, the virtual host definitions could be
consulted for a suitable virtual host to serve to the client.  This
would allow the virtual host to define access controls again.  This
would also mean that it would be impossible to specify SSL options in a
particular virtual SSL host definition, but I would certainly be willing
to accept that limitation, especially compared to our choices now (and I
bet others would as well).

In fact, the fact that the ssl negotiation parameters have to be the
same for all the name virtual hosts would be the only significant
limitation.  And because you can use subjectAltName to specify alternate
hostnames in a SSL certificate will almost completely mitigate this
limitation for most people.

Is there any reason why this can't be implemented in apache?

Again, to be clear, I made name based virtual ssl hosts work.  The
documentation says this is impossible.  It is not.  It would, however,
work worlds better if implemented from within apache.

-- 
Daniel Rogers
daniel@phasevelocity.org