hello hello hello,i recently posted a similar issue with the topic "Weirdo intepretation of SSLprotocol order" on this distlist (may 7th 2015)
I found that (at least on) Apache 2.2.29 64bit Prefork, the sslProtocol order is only challenged once for the whole server, that is the first occurence to appear. I think this is your problem too...
Someone asked me to build a backported dist of httpd, or at least a patch.. however, time never got to me...
The general solution seems to be running httpd 2.4.13+, but its unclear to me, whether the problem resides in openssl maybe.. however, its not fixed out of the blue. And i know, this doesnt answer your question, but it may make things a little clearer :)
br Congo On 2015-06-17 00:37, karl karloff wrote:
So that does not actually help in the case of SSLv3 because SNI is an extension to TLS. It seems like this is not possible in Apache given the usage of OpenSSL as the SSL/TLS library. Does that sum it up? Thanks, Karl ----------------------------------------Date: Tue, 16 Jun 2015 23:54:39 +0200 From: ylavic.dev@xxxxxxxxx To: users@xxxxxxxxxxxxxxxxSubject: Re: VirtualHosts, SSLProtocol, and SSLCipherSuiteOn Tue, Jun 16, 2015 at 10:48 PM, karl karloff <karlkarloff@xxxxxxxxxxx> wrote:I am attempting to set up more than one subdomain on :443 in this example.so something like sslv3.example.com:443 responds with SSLv3 only tlsv1.example.com:443 responds with TLSv1.0 only ... I wasn't aware that could be achieved using the ServerName directive.The underlying IP/interface should be the same for all subdomains, but each subdomain responds by accepting only a single SSLProtocol.Does that make sense?It does, however there is a limitation currently in OpenSSL in that it can't renegotiate the protocol. Hence this configuration will work only with browsers/clients supporting (and advertising) the Server Name Indication (SNI), which allows to select the correct VirtualHost before the negotiation occurs. Otherwise, Apache HTTPd will have to negotiate before being able to read the requested Host header, and hence determine the VirtualHost. Thus it will do the negotiation occording to the parameters (protocol, ciphers, ...) of the first vhost declared on the listening IP:port. If finally the determined vhost is not the one used for the negotiation, it will ask for a renegotiation which, as said above, won't take the SSLProtocol into consideration due to OpenSSL not being able to do that (the SSLCipherSuite can be renegotiated though). So all should be fine with SNI only. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|