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

[Michael D'Errico <mike-list at pobox.com>]

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