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
server_rec.
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
SSLSrvConfigRec
- 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.
Cheers,
Stefan
> Am 28.08.2015 um 10:54 schrieb Ruediger Pluem <[email protected]>:
>
>
>
> On 08/28/2015 10:35 AM, Stefan Eissing wrote:
>>
>>> Am 28.08.2015 um 10:32 schrieb Ruediger Pluem <[email protected]>:
>>> On 08/28/2015 09:32 AM, Stefan Eissing wrote:
>>>>
>>>>> Am 28.08.2015 um 03:37 schrieb Roy T. Fielding <[email protected]>:
>>>>>> + 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
>>>>> containing
>>>>> 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
