"Nick Maynard" <[EMAIL PROTECTED]>; [EMAIL PROTECTED]:03
GMT-5
The problem is: SSL is *NOT* usable for virtual hosting. You need an
separate socket for each SSL vhost, so you'll probably prefere
several independent httpd's - maybe then stripped down w/o any vhost
support.
You're right - SSL is not usable for name-based vhosts. However it
should be fine for normal vhosts. Are you suggesting I use a separate
httpd for every SSL host I have? That's a waste of resources, and
horribly inefficient. Can metuxmpm deal with non name-based SSL
vhosts?
Hi. I hang out mostly on the users list, but have played with basic
HTTPS configuration (using SSL or TLS). As I understand, HTTPS works
fine with any VirtualHost, so long as it is based on a unique ip:port
combination. That is the current alternative to name-based virtual
hosting. It doesn't necessarily mean you need a unique ip address, if
you're willing or able to use non-standard ports. Otherwise it does
require unique ip addresses and port 443. That is IP Based Virtual
Hosting. I guess it is somewhat of a misnomer. It should be Socket
Based Virtual Hosting, but IPBVH implies that only default ports are
used. If you must use a single ip:port combination for HTTPS, then it's
not possible, due to the point at which the SSL/TLS layers takes over to
ensure the ultimate security of the connection.
I'm not an expert with SSL or TLS, but my intuitive response would be to
modify the HTTPS protocol to establish an unsecured connection, send the
host header (ignore anything else) to pick the right certificate, and
then use that to secure the connection. But my intuition also tells me
that this would probably open up some avenues for attacks which might
seriously degrade the effectiveness as compared to securing a connection
from the outset, or otherwise add many levels of complexity and possibly
inefficiency to ensure the connection is secured after some data was
transferred. It would be great to have a compromise to allow some host
header data be sent to an unsecured socket for the purposes of NBVH, and
then hand off to another socket to respond securely.
It may be my naivety, but I think anything is possible if perhaps not
easy, because we tell the computer what to do, the computer doesn't tell
us what to do, or else we have given it too much power and need to step
back. Until I find the time to educate myself about the HTTPS, SSL and
TLS protocols, and practice using something like OpenSSL and the Apache
2.x module programming, then I personally can't explore the feasability
or implementation of such things. But hopefully someone else beats me
to it.
Leif
