Re: [TLS] matching identity, by default

[Marsh Ray <[e-mail]>]

Martin Rex wrote:
> Marsh Ray wrote:
>>> 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.
> 
> That is a pretty bold statement and doesn't match the question.
> 
> Unless you and Nasko have made a U-turn on your position about "lockdown
> of established identities during renegotiation", the change of
> the certificate will continue to be possible, and therefore
> "can return different identity information each time" remains valid.

Yes, it will be possible for authentication credentials/certificates to
change. That's one of the primary purposes of renegotiation.

No, it will not be possible for a MitM or other network-level attacker
to coordinate the change.

> The TLS renegotiation vulnerability allowed to pass along the
> TLS endpoint during renegotiation freely, an in particular to
> unsuspecting TLS peers.
> 
> The secure renegotiation will ensure that the endpoint of
> a renegotiated TLS session will be tied securely to the
> endpoints of the enclosing TLS session.

It ensures continuity-of-identity of the client and server across all
the [unnamed things between handshakes] on the connection.

This is not the same as saying the certificates never change, but it
restores the missing and essential property that everyone thought they
were getting when they made a connection with the "secure sockets layer"
protocol.

In a sense, it takes the authentication which is currently per-session
and makes it cumulative across the entire connection. Applications may
not treat it that way, but at least one important case (HTTPS) does.

> And if one does _not_ use any of the plain RSA ciphersuites (but instead
> the DHE ones), then even an attacker in possession of the
> server's long term credential (like a disgruntled admin)
> will not be able to manipulate the renegotiation and get someone
> else to authenticate injected requests.

Someone in possession of an RSA private key can do anything that cert
represents except decrypt a previously-captured DH session. It's
debatable whether or not this is even an "attack" since he has the
primary (and usually only) credentials.

> What the renegotiation fix also not fixes is any potential
> security vulnerabilites from the interleaving of
> application data during the renegotiation handshake.

Yes, but I suspect that those attacks are greatly mitigated by
preventing a MitM from monkeying around with the renegotiation in the
first place.

- Marsh