Re: [TLS] Summarizing identity change discussion so far

[Marsh Ray <[e-mail]>]

Hello all,

I'm wearing a warm red and gray hat today.

[e-mail] wrote:
> Marsh Ray wrote:
> 
>>> and can cause security vulnerabilities for some of them.
>> Do we know of any examples? I can only think of some very subtle and
>> hypothetical ones that require client and server apps that are already
>> coded for switching identities intentionally.
> 
[...]
> 
> I guess an even worse example would be something like this:
> 
>   conn = openTlsConnection(host, port)
>   if not verifyCertChain(conn.getPeerCert()):
>      raise "Not a valid cert"
>   if conn.getPeerCert().getName() != expected_name:
>      raise "Name in certificate doesn't match"
>   # continue...

_After_ renegotation is fixed (and/or disabled by default) though, how
is this a problem? RI proves the data has come from the same remote
endpoint. That same remote endpoint has proven that he can supply an
acceptable cert, too.

In order for this example to be a problem, the legitimate client would
have to renegotiate specifically for the purpose of dropping certain
cert credentials. This would seem to imply that the application code was
expecting cert changes.

This is not to say that there's no application that could be confused by
such a change, only that I haven't seen any real examples. Nelson
suggested a test tool used internally with NSS might do something
agressive with certs and renegotiation like that.

I don't think it's inherently broken. It seems reasonable to me for one
party to say "By the initial handshake and two subsequent renegotiations
I have proven posession of the private keys for these three certificates".

With renegotiation fixed, credentials supplied on different handshakes
may legitimately be treated as additive. This is how https client
certificates often work: an initial anon-client connection adds a client
cert to the connection by renegotiating.

The actual credentials policy should be documented as part of the app
protocol on top of TLS. Most of them would document "no renegotiation"
and I think that should be the default for implementations.

> Most TLS libraries seem to support both callback and get() style
> functions for accessing/checking certificates.

Most script-language bindings to OpenSSL seem not to support the
callback mechanism very well. Just a data point.

> Although using the callback-style APIs might be more common (and in
> some sence nicer, since it allows you to abort the handshake 
> a bit earlier -- but an app developer might not care about this very 
> much), I think it would be a surprise to most app developers that 
> using the get-style APIs might not be secure.
> 
> (And I wouldn't be surprised at all if real applications using
> those get() style APIs are found...) 

You know they exist when all example code for some very popular
implementations and languages does it that way.

- Marsh