Re: [TLS] matching identity, by default

[Marsh Ray <[e-mail]>]

James Manger wrote:
> 
> 1. HttpsURLConnection https = (HttpsURLConnection)
> url.openConnection(); 2. serverName =
> https.getPeerPrincipal().getName(); 3. in = https.getInputStream(); 
> in.read()... 4. colour =
> isEVCertificate(https.getServerCertificates()[0]) ? green: white;
> 
> Unfortunately this is insecure.

Yep.

> If a TLS renegotiation completed between steps 2 & 4 then the
> serverName may have come from a different certificate than the one
> whose Extended Validation status was checked.

Yep.

> An attacker defeats a weak domain-validation (DV) process to get a
> cert for paypal.com; and gets an extended-validation cert for
> Attacker Corp. Now the attacker can fool the client's user: initially
> negotiating with the DV cert then renegotiating with the EV cert. The
> client indicates to its user that paypal.com was strongly identified
> -- which is wrong.

Or he may even be able to start with an EV cert for "evil.example.com".

> This example is a little contrived, but I don't think the
> vulnerability in the code would be obvious to even a security-aware
> programmer.

It is usually how example code is shown, especially for scripting languages.

> The fact that calls to getServerCertificates() and
> getPeerPrincipal(), or multiple calls to either of these methods, can
> return different identity information each time is highly likely to
> surprise app developers -- which is a recipe for vulnerabilities.
> 
> TLS libraries ensuring that any authenticated peer identity does not
> change across renegotiations -- unless the app has explicitly
> indicated it is expecting this -- should be a requirement.

It's completely fixed by draft-ietf-tls-renegotiation, no additional
constraints on the certs are necessary.

> P.S. Java's HttpsURLConnection often uses a default HostnameVerifier
> that probably mitigates the specific example above, but not minor
> variations.

Yep.

- Marsh