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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf