mailing list archives
TLS servers with overbroad certificates may mishandle diverted connections
From: Matt McCutchen <matt () mattmccutchen net>
Date: Sun, 13 Mar 2011 22:31:22 -0400
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
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
In October, I manually tested a selection of about 20 of my favorite web
sites with multiple subdomains; most were affected, though only one
tool, but I decided to go ahead and publicize the issue first.
Previous discussion on the IETF TLS list:
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
- TLS servers with overbroad certificates may mishandle diverted connections Matt McCutchen (Mar 14)