Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

[Martin Rex <[e-mail]>]

Simon Josefsson wrote:
> 
> One attack could works like this:
> 
> 1) Client establish an client-authenticated HTTPS session with a TLS SNI
> for blog.example.org and sends a HTTP GET with a Host: header for
> internal-website.example.org.
> 
> 2) The server TLS code authenticate and authorize the client (using the
> certificate) for use with the blog.example.org domain.  The server HTTP
> code serves the internal-website.example.org web page to the client.
> 
> This system would be insecure but still compliant with RFC 4366bis as
> far as I can tell, which seems suboptimal.  Adding a requirement for
> servers to check for this attack would solve the problem.

I do not see why you consider this a vulnerability in the _server_!

This is exactly how virtual hosting works.  Virtual hosting
does NOT seperate content.  And neither will the use of TLS
provide any such content seperation.  The use or non-use of
server name indication does not make a difference.

Server Name Indication is a feature for the _client_ side, and was
invented to accomodate virtual hosting when HTTP over TLS is used
and the client performs weak server endpoint identification
that is suggested by rfc-2818, section 3.1.


If you can coerce a Browser into sending a Host: header field
different to the host that is used for server endpoint identification,
then this might possibly be considered a problem in the *client*.


When using Reverse Proxies with re-encryption, there may be
a by-design difference in the SNI as supplied by the client
(matching the hostname of the reverse proxy) and the
host header field that the backend server is going to see/use.


-Martin