Martin Rex wrote:
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_!
Because a malicious client could theoretically establish a secure
connection using one server domain and then ask for pages from a
different domain. If the server does not check for this, it could
potentially leak sensitive information.
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.
Virtual hosting does indeed allow for separate content for each
domain. Or am I misunderstanding you?
The reason for the server name extension is because, for HTTPS, the
TLS layer is negotiated prior to the client sending its HTTP request
containing the Host: header. A server that hosts multiple domains
needs to use the SNI to negotiate the proper secure connection using
a certificate with a matching commonName or dNSName.
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.
Perhaps it was originally a client feature, but my test server
has two certificate chains for two different domains, and it
negotiates TLS using one or the other depending on the SNI. The
server name is then made available to the application layer. I
don't know of any other way to do this since they share an IP
address. (For anyone interested in testing against my server,
see http://mikestoolbox.com.)
And I'm curious: why do you call matching the commonName weak?
Mike
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