> -----Original Message----- > From: Daniel Rogers [mailto:[EMAIL PROTECTED] > Sent: Montag, 6. März 2006 03:17 > To: dev@httpd.apache.org > Subject: SSL enabled name virtual hosts > > > I am not convinced by the argument that name based SSL virtual hosting > is impossible.
It's not only an argument, it's a demonstrable fact. I did read your posting and you clearly do understand a good deal about HTTP but there are a couple of key points that are leading you to wrongthink: - You're right that since apache can't see the host header, it uses the cert from the default VH to establish the SSL session. Thereafter, it *can* see the host header and so can route the requests successfully. This give a lot of people the illusion that SSL-NBVH is possible. The big problem is that you don't get authentication because the default cert, generally, will not match the requested site. For professional SSL, authentication is every bit as essential as encryption so this won't do. - Using an extra port (444, etc) immediately gives you access to multiple SSL VHs. But they are then port-based VHs, not name-based. SSL VHs have to be distinct at the TCP/IP layer, so changing ports achieves that. NBVHs are degenerate at TCP/IP and only distinct at HTTP. But using an extra port is not a professional solution - anything other than port 80 and 443 will not wash on the commercial internet. - Using SubjectAltName to allow for an "all-purpose" certificate sounds like a good idea and would be fine in a research environment where you are making your own certs. But I don't think it would be very practical in a commercial situation. If you are a web-hosting company, are you really going to get a new certificate every time a site wants an SSL VH? Who sells these certs? How expensive are they? As has been pointed out, the problem is already solved at the technical level by upgrading to TLS within HTTP/1.1 (rfc 2817). The real problem is waiting for browsers to support it... Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. > 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 > [EMAIL PROTECTED] > > Diese E-mail ist eine private und persönliche Kommunikation. Sie hat keinen Bezug zur Börsen- bzw. Geschäftstätigkeit der SWX Gruppe. This e-mail is of a private and personal nature. It is not related to the exchange or business activities of the SWX Group. Le présent e-mail est un message privé et personnel, sans rapport avec l'activité boursière du Groupe SWX. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
