You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2015/08/27 00:15:19 UTC
HTTP_MISDIRECTED_REQUEST
Should this exception have a protocol version guard for HTTP/2.0 requests,
and leave the response as HTTP_BAD_REQUEST for HTTP/1.1 and earlier?
@@ -203,6 +204,9 @@
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
APLOGNO(02032)
"Hostname %s provided via SNI and
hostname %s provided"
" via HTTP are different", servername, host);
+ if (r->connection->keepalives > 0) {
+ return HTTP_MISDIRECTED_REQUEST;
+ }
return HTTP_BAD_REQUEST;
}
}
RE: HTTP_MISDIRECTED_REQUEST
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
> -----Original Message-----
> From: Stefan Eissing
> Sent: Montag, 31. August 2015 11:48
> To: dev@httpd.apache.org
> Subject: Re: HTTP_MISDIRECTED_REQUEST
>
>
> > Am 28.08.2015 um 15:49 schrieb Eric Covener <co...@gmail.com>:
> >
> > On Fri, Aug 28, 2015 at 9:26 AM, Stefan Eissing
> > <st...@greenbytes.de> wrote:
> >> 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.
> >
> > Long term we need to block these name-based renegotiations because
> > we'll be at TLS1.3. I don't know how to ween people off, but making
> > up an H2 requirement might be one way to ease people into it.
>
> I am not the expert on TLS renegotiation, I am just aware that certain TLS
> parameters can be changed on an existing connection if both parties agree.
> And I am aware that this has been used in attacks and the feature seems to
> be frowned upon nowadays.
>
> I see mod_ssl code that checks for renegotiations based on directory
> configurations, so it is request based. And it will fail miserably in
> HTTP/2 connections as there is no longer *the one current* request on a
> connection.
>
> What would be the most common scenarios for TLS renegotiation be that we
> should users warn about when enabling HTTP/2? Is requiting a client cert a
> common use here?
Everything that you configure in directory context. Be it client certs or SSL ciphers.
Regards
Rüdiger
Re: HTTP_MISDIRECTED_REQUEST
Posted by Ronald Masaya <ro...@gmail.com>.
Adobotalk.com youtube.com
ronaldmasayarm
On Aug 31, 2015 5:48 PM, "Stefan Eissing" <st...@greenbytes.de>
wrote:
>
> > Am 28.08.2015 um 15:49 schrieb Eric Covener <co...@gmail.com>:
> >
> > On Fri, Aug 28, 2015 at 9:26 AM, Stefan Eissing
> > <st...@greenbytes.de> wrote:
> >> 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.
> >
> > Long term we need to block these name-based renegotiations because
> > we'll be at TLS1.3. I don't know how to ween people off, but making
> > up an H2 requirement might be one way to ease people into it.
>
> I am not the expert on TLS renegotiation, I am just aware that certain TLS
> parameters can be changed on an existing connection if both parties agree.
> And I am aware that this has been used in attacks and the feature seems to
> be frowned upon nowadays.
>
> I see mod_ssl code that checks for renegotiations based on directory
> configurations, so it is request based. And it will fail miserably in
> HTTP/2 connections as there is no longer *the one current* request on a
> connection.
>
> What would be the most common scenarios for TLS renegotiation be that we
> should users warn about when enabling HTTP/2? Is requiting a client cert a
> common use here?
>
> //Stefan
>
> <green/>bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>
>
>
>
Re: HTTP_MISDIRECTED_REQUEST
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 28.08.2015 um 15:49 schrieb Eric Covener <co...@gmail.com>:
>
> On Fri, Aug 28, 2015 at 9:26 AM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>> 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.
>
> Long term we need to block these name-based renegotiations because
> we'll be at TLS1.3. I don't know how to ween people off, but making
> up an H2 requirement might be one way to ease people into it.
I am not the expert on TLS renegotiation, I am just aware that certain TLS parameters can be changed on an existing connection if both parties agree. And I am aware that this has been used in attacks and the feature seems to be frowned upon nowadays.
I see mod_ssl code that checks for renegotiations based on directory configurations, so it is request based. And it will fail miserably in HTTP/2 connections as there is no longer *the one current* request on a connection.
What would be the most common scenarios for TLS renegotiation be that we should users warn about when enabling HTTP/2? Is requiting a client cert a common use here?
//Stefan
<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: HTTP_MISDIRECTED_REQUEST
Posted by Eric Covener <co...@gmail.com>.
On Fri, Aug 28, 2015 at 9:26 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
> 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.
Long term we need to block these name-based renegotiations because
we'll be at TLS1.3. I don't know how to ween people off, but making
up an H2 requirement might be one way to ease people into it.
Re: HTTP_MISDIRECTED_REQUEST
Posted by Stefan Eissing <st...@greenbytes.de>.
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 <rp...@apache.org>:
>
>
>
> On 08/28/2015 10:35 AM, Stefan Eissing wrote:
>>
>>> Am 28.08.2015 um 10:32 schrieb Ruediger Pluem <rp...@apache.org>:
>>> On 08/28/2015 09:32 AM, Stefan Eissing wrote:
>>>>
>>>>> Am 28.08.2015 um 03:37 schrieb Roy T. Fielding <fi...@gbiv.com>:
>>>>>> + 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
Re: HTTP_MISDIRECTED_REQUEST
Posted by Ruediger Pluem <rp...@apache.org>.
On 08/28/2015 10:35 AM, Stefan Eissing wrote:
>
>> Am 28.08.2015 um 10:32 schrieb Ruediger Pluem <rp...@apache.org>:
>> On 08/28/2015 09:32 AM, Stefan Eissing wrote:
>>>
>>>> Am 28.08.2015 um 03:37 schrieb Roy T. Fielding <fi...@gbiv.com>:
>>>>> + 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
>
>
>
Re: HTTP_MISDIRECTED_REQUEST
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 28.08.2015 um 10:32 schrieb Ruediger Pluem <rp...@apache.org>:
> On 08/28/2015 09:32 AM, Stefan Eissing wrote:
>>
>>> Am 28.08.2015 um 03:37 schrieb Roy T. Fielding <fi...@gbiv.com>:
>>>> + 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?
//Stefan
<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: HTTP_MISDIRECTED_REQUEST
Posted by Ruediger Pluem <rp...@apache.org>.
On 08/28/2015 09:32 AM, Stefan Eissing wrote:
>
>> Am 28.08.2015 um 03:37 schrieb Roy T. Fielding <fi...@gbiv.com>:
>>> + 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.
Regards
Rüdiger
Re: HTTP_MISDIRECTED_REQUEST
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 28.08.2015 um 03:37 schrieb Roy T. Fielding <fi...@gbiv.com>:
>> + 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.
Maybe I get time today to look into this...
//Stefan
<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: HTTP_MISDIRECTED_REQUEST
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
> On Aug 26, 2015, at 3:15 PM, William A Rowe Jr <wrowe@rowe-clan.net <ma...@rowe-clan.net>> wrote:
>
> Should this exception have a protocol version guard for HTTP/2.0 requests, and leave the response as HTTP_BAD_REQUEST for HTTP/1.1 and earlier?
>
> @@ -203,6 +204,9 @@
> ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server, APLOGNO(02032)
> "Hostname %s provided via SNI and hostname %s provided"
> " via HTTP are different", servername, host);
> + 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.
Hmm, I wonder how this impacts Google's desire to allow multiple hosts to reuse
the same SPDY connection ... was that dropped for h2?
....Roy