Re: [TLS] matching identity, by default

[Marsh Ray <[e-mail]>]

James Manger wrote:
> Marsh,
> 
>> In other words, an endpoint could
>> renegotiate an anonymous connection ten times to provide ten different
>> certificates, and the other party can securely treat all data sent over
>> that connection as having been authenticated to all ten certificates!
> 
> This point about all data being authenticated by all certs is a good
> point to emphasis.
> Unfortunately, it does not mean typical applications wont get confused
> (ie have vulnerabilities) when they hadn't explicitly anticipated that
> 10 certs could be renegotiated.

Yep.

>> I have a driver's license issued by Kansas and a passport issued by the
>> US Dept of State, yet I do not assume two different identities.
>> Sometimes, I am even requested to provide both!
> 
> Consider turning up to a Whitehouse check point, showing your
> credentials to a guard, and "renegotiating" whenever you like by showing
> another credential. A controller talking to the guard on the phone asks:
> [controller] What is the name on the credential?
> [guard] Marsh Ray
> [controller] Type of credential?
> [guard] passport
> /now you show the guard your driver license/
> [controller] Issuer of credential?
> [guard] Kansas
> 
> The controller thinks he has authenticated Marsh Ray with a passport
> issued by Kansas.

lol - good example

> If you happen to have a library card under a fake name and you showed
> that first, the controller might think he has authenticated Bugs Bunny
> with a Passport from the US Dept of State. Ouch! That might allow the
> wrong person into a Whitehouse party ;-)
> 
> In this analogy, the guard is a TLS library, the controller is an
> application, your cards are certificates, and the protocol of showing
> your cards is TLS (with the fix!).

In real applications, there's also the possibility you could end up
authenticated as Kansas.

> Is the error the controller's fault or the guards fault? The
> application's or the TLS library's (or the protocol's for not providing
> sufficient guidance)?

Oh there's probably enough blame to go all around.

> This suggests another way for a TLS library to ensure it doesn't confuse
> an application that doesn't explicitly stated it is prepared for
> renegotiations.

I think it's becoming clear that very few application developers
realized that TLS had this capacity for renegotiation, much less that
their TLS library was doing it automatically.

'No renegotiation' is probably a good default.

> A library could tell the application only about one peer identity it
> authenticates (probably the first it authenticates).
> For instance, Java's HttpsURLConnection.getServerCertificates() method
> could return the same set of certificates for the life of the object
> (the life of the TLS connection), and simply not tell the application
> about any different certificates from renegotiations. The TLS library
> could still renegotiate and switch to new sessions, but the application
> would be blissfully unaware -- and still secure.
> 
> Somehow this behaviour doesn't feel quite right, but I think it would be
> ok.

Does seem a bit busted. The application may be renegotiating for the
explicit purpose of dropping credentials, such as when switching to a
new identity.

There's no solution short of disabling renegotiation by default, seeing
what breaks, and helping app developers fix it securely. But that's a
decision for each library vendor independently, not for the TLS wire
protocol spec.

> It might be easier to implement than comparing identities across
> negotiations, and it would cope with those (somewhat unbelievable) niche
> cases of renegotiating with a re-issued certificate etc.

SSL/TLS has been around long enough, and has been popular enough, that
it's pretty much guaranteed to have some of everything in operation. Any
change to the semantics of the protocol or widely-used interfaces is
going to break something. It's a question of how much you break, whether
anything ends up less secure as a result, and whether the result ends up
being easier or harder to understand.

Solutions that involve adding new logic (such as keeping the old
certificate and showing it to the application in place of the new) seem
to have a lot of potential for breaking things in subtle and silent ways.

- Marsh