httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Date Fri, 28 Aug 2015 13:26:56 GMT
As long as we are waiting for the *real* experts to chime in, I took a first stab
refactoring the code a tiny bit and adding an additional check against the selected

If the r->hostname does not match the SNI servername, the r->hostname is used to
check if it matches the sslconn->server. That catches the case where a vhost has
ServerAlias or even wildcard and the client somehow got the notion to use the TLS
connection for such hosts as well. I think this is risk free as the same server_rec 
should be selected on a new connection with r->hostname in SNI.

(It could be that the match is not the only one and that a vhost in the list *before* the
current one would be selected. Hmmm...)

Where I want to go with this the following test:

  if (r->hostname does not match SNI) {
     server_rec *rs = ssl_find_vhost_for(r->hostname);
     if (sslconn->server != rs) {
        SSLSrvConfigRec *conncfg = mySrvFromConn(c);
        SSLSrvConfigRec *reqcfg = mySrvConfig(r->server);
	if (!compatibleSslParams(conncfg, reqcfg)) {
            return HTTP_MISDIRECTED_REQUEST;
  /* all fine, process request */

Where "compatibleSslParams" needs to be defined. I think it needs to match at least

 - enabled
 - cipher_server_pref
 - insecure_reneg
 - server
   - pks (complete match of everything)
   - protocol
   - cert_chain
   - stapling_*
   - srp???
   - ocsp_*
   - ssl_ctx_*???
 - strict_sni_vhost_check
 - fips
 - compression
 - session_tickets???

If this works, one could think about introducing some kind of "equivalence number" to speed
up the checking, since in certain HTTP/2 setups there might be a good percentage of requests
requiting this verification.



> Am 28.08.2015 um 10:54 schrieb Ruediger Pluem <>:
> On 08/28/2015 10:35 AM, Stefan Eissing wrote:
>>> Am 28.08.2015 um 10:32 schrieb Ruediger Pluem <>:
>>> On 08/28/2015 09:32 AM, Stefan Eissing wrote:
>>>>> Am 28.08.2015 um 03:37 schrieb Roy T. Fielding <>:
>>>>>> +                if (r->connection->keepalives > 0) {
>>>>>> +                    return HTTP_MISDIRECTED_REQUEST;
>>>>>> +                }
>>>>>>                return HTTP_BAD_REQUEST;
>>>>>>            }
>>>>>>        }
>>>>> IIRC, it is applicable to HTTP/1.1 as well. Think misdirected requests
>>>>> an absolute request URI that points to some other server.  I don't think
the conditional
>>>>> is needed at all -- just return HTTP_MISDIRECTED_REQUEST.
>>>> Thanks for clarifying this.
>>>>> Hmm, I wonder how this impacts Google's desire to allow multiple hosts
to reuse
>>>>> the same SPDY connection ... was that dropped for h2?
>>>> It wasn't. Our implementation currently just goes the easy way. It needs
to check that server/vhost from request and SNI indeed use the same certificate and if not,
maybe even if altnames/wildcards match. But I am not sure that is a good idea.
>>> The issue is a little bit more complex. You need to ensure that the server/vhost
from the request is using the same SSL
>>> parameters as the SNI host like protocols, ciphers, etc. Otherwise you would
need to renegotiate. And as far as I
>>> remember some parameters are not renegotiable. See comments above this code.
>> Hmm, I see. Since you know this more intimate than me: is checking the mod_ssl config
of both for equality of certain members the way to solve this? It should either have the individual
settings or the merged ones from the base server, right?
> Interesting approach. I hope our SSL experts will chime in :-).
> And yes the configs should have the individual settings or the merged ones from the base
server which could be the
> default values.
> Regards
> Rüdiger

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

View raw message