The server certificate is sent during the SSL negotiation, and browser
verification of identity is done before ever sending any data to the
server (even the GET /urlname HTTP/1.1\nHost: name.server.com\n\n
information). There is no way for the SSL client to tell the SSL server
what name it's trying to reach during the negotiation, so there's no way
for the SSL server to determine which credentials it needs to give to the
client.
HTTP/1.1 name-based virtual hosts rely on the client giving the 'Host:'
header to tell the server software what server they're trying to reach.
Since this happens at the HTTP layer, it's too late for the SSL
negotiation.
(It might be useful to change the SSL/TLS spec to give the client the
ability to specify the host it's trying to reach, but that violates one of
the security aspects of SSL: it would either force the client to perform
an unauthenticated key negotiation with the server before getting the
server certificate, and then renegotiating after the certificate was
received... OR it would force the client to send the name of the server it
was trying to reach in the clear, before any cipher negotiation was done.)
Your approach wouldn't work, because of the key/certificate presentment
problem described above.
You -CAN-, however, have multiple SSL servers running on different ports
of the machine with different certificates; you'll just have to be
prepared to accept that someone doing a portscan of your machine will see
the names of the certificates the server is presenting. (Which is a
larger security hole, in my opinion, than the protocol-modification idea
above.)
---
Mat Butler, Winged Wolf <[EMAIL PROTECTED]>
SPASTIC Web Engineer SPASTIC Server Administrator
----Begin FurryCode v1.3----
FCWw5amrsw A- C+ D H+++ M+++++[servercoder] P+ R++ T+++ W Z++ Sm++
RLCT/M*/LW* a cl/u/v++++>+++++ !d e- f>++++ h++ iwf+++ j p->+ sm++
----End FurryCode v1.3----
On Thu, 16 Mar 2000, Blair Lowe wrote:
> Just some crazy ideas:
>
> 1. Have the webserver behing the firewall, and have a separate
> private (eg. 192.168.x.x) IP address for each virtual host. This
> solves the problem of having to have multiple Internet addresses.
>
> Make the firewall, or some DMZ box translate the incomming request
> for a.domain.at:443 to the private IP address.
>
> 2. Do the same thing, but go from port 443 on the translation box to
> a unique port on the virtual host box. I believe that the virtual
> host box can run a different SSL connection as long as the port is
> distinct. Incoming connections would think that they are going in on
> port 443.
>
> Anyone want to test this theory (or flame it)? I'd love to hear the
> results (comments)!
>
> Blair.
>
> At 08:57 -0500 2000/03/16, Martin Helie wrote:
> >Hello,
> >
> >I seem to have read something about apache and modssl not being too friendly
> >towards name based virtual hosts, but was wondering if anyone had more
> >info...
> >
> >So far, I have been able to allow _one_ virtual host to access port 443, but
> >if I enable SSL for any other vhosts, things get kind of weird.
> >
> >Are my only options to get IP addresses for each host, or run multiple
> >instances of httpd configured differently? Any other ideas?
> Computer Engineering Inc. http://www.compeng.net
> Phone: 780 499 5687 (9 - 5 MST) Fax: 780 435 0693 (24 Hours)
> All email advice that is provided for free is without warrantee: use
> at your own risk.
> ______________________________________________________________________
> Apache Interface to OpenSSL (mod_ssl) www.modssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
