httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Sylvester <peter.sylves...@edelweb.fr>
Subject Re: [SPAM?]: RE: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Thu, 12 Dec 2013 09:55:07 GMT
On 12/12/2013 10:28 AM, Plüm, Rüdiger, Vodafone Group wrote:
>
>> -----Original Message-----
>> From: Kaspar Brand [mailto:httpd-dev.2013@velox.ch]
>> Sent: Donnerstag, 12. Dezember 2013 07:01
>> To: dev@httpd.apache.org
>> Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
>>
>> On 12.12.2013 00:15, William A. Rowe Jr. wrote:
>>> The rest of the SNI hostname processing steps are where the problem
>>> lies.  We still need to perform http headers -> vhost translation after
>>> the connection is established.  If there's any desire to do SNI hostname
>>> validation, that has to be limited to comparing that hostname to the
>>> ServerName/ServerAlias entries, not to the HTTP Host: which has a
>>> different semantic meaning and is the only hostname of interest to
>>> httpd as an HTTP server.
>> The logic in ssl_hook_ReadReq was added with r757373. It wasn't in the
>> initial version of the patch for SNI support (r606190). I didn't find
>> prior discussion of r757373 on the mailing list, but perhaps it was
>> motivated by this statement in RFC 6066 (RFC 4366 at the time):
>>
>>                                              If the server_name is
>>     established in the TLS session handshake, the client SHOULD NOT
>>     attempt to request a different server name at the application layer.
>>
>> I never really understood the reasoning for turning this into a "reject
>> requests if the SNI extension and the Host header differ" (see e.g. [1],
> The reason is that you can define SSL parameters in Virtual hosts like SSLCiphers or
SSLProtocols.
> If Host header and SNI host match you can be sure that the parameters that you set in
the virtual host from which
> your request is being served have been used. If you allow a mismatch between SNI host
and host header you might
> serve the request on a SSL connection that does not match your SSL parameters set up
for the particular virtual host.
>
> Regards
>
> Rüdiger
SHOULD NOT does leave all things open to the server.
This was implemented 10 years ago.
Clients used sslv2, and 32bit xp today still cannot do sni.

Anyway: I am puzzled about the problem:


- There is some matching of the SNI value to some value X
   from a server definition.
- X should be "compatible" to what is send later in the Host:

If there is some proxying involved then X should be the shared
value?

If there is NO SNI, that's another story










Mime
View raw message