TLS servers with overbroad certificates may mishandle diverted connections

[Matt McCutchen <matt () mattmccutchen net>]

If I make a TLS connection to example.com, a MITM attacker can divert
the connection to any server that bears a certificate valid for
example.com, regardless of the data in DNS.  If such a server is not
intended to handle requests for example.com and responds in an improper
way, the attacker will have broken the integrity of TLS.  This situation
is especially likely to arise with wildcard certificates.  The impact
may range from a mere nuisance to JavaScript injection or worse
depending on the application and how the server responds.

To test a server, simply view its certificate, choose a DNS name for
which the certificate is valid but for which the server is not listed in
DNS, and map that name to the server in your hosts file.  Point your
favorite client to that DNS name and see how the server responds.  For
SNI clients, a TLS failure (preferably an "unrecognized_name" fatal
alert) is ideal; the client is already obliged not to rely on anything
it sees before a successful TLS handshake.  An application-level error
such as HTTP 400 or 403 is probably harmless in real-world scenarios.
An HTTP redirect to a non-TLS site is bad: if it happens on a request
for a JavaScript file, the attacker can now inject malicious code.

In October, I manually tested a selection of about 20 of my favorite web
sites with multiple subdomains; most were affected, though only one
admitted JavaScript injection.  I plan to release an automated testing
tool, but I decided to go ahead and publicize the issue first.

Previous discussion on the IETF TLS list:

http://www.ietf.org/mail-archive/web/tls/current/msg07133.html

-- 
Matt

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/