On 12/12/2013 10:28 AM, Plüm, Rüdiger, Vodafone Group wrote:
-----Original Message-----
From: Kaspar Brand [mailto:[email protected]]
Sent: Donnerstag, 12. Dezember 2013 07:01
To: [email protected]
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
