Re: [TLS] Summarizing identity change discussion so far

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> > 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.

The above code sample provide by Pasi is about client-side code,
as indicated by "openTlsConnection" and the comparison
"conn.getPeerCert().getName() != expected_name"

So this is more about server certificates changing then clients
using different credentials.  And it is about apps coding above TLS,
and not about details of TLS implementations.

Since a non-negligible amount of clients will need allow old renegotiation
for a little while, one might want to think about mitigating unexpected
changes the server certificate.


> 
> 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".

There are a lot of applications scenarios where this either doesn't
make any sense or will cause endless problems, support calls and confusion.

Would you want your browser to send *ALL* your WWW-authenticate
credentials to every server and let the server pick (AFAIK the
protocol doesn't even allow that).

In most Audit log facilities, you can only log *ONE* identity for
which an operation was attempted (and failed or succeeded), and not
an arbitrary set of identites.


As soon as you have larger distributed systems, your TLS endpoint
might be a reverse proxy at the perimeter of the backend server farm.

The reverse proxy is going to forward the initially authenticated cert
to the backend application, the backend application will perform an
authentication, create a backend session and issue a session identifier.
>From that point on, all requests carrying that session ID will be
processed under this backend session context, and the reverse proxy
will often forward all requests with that session identifier to the
same backend host (because of the backend state identified by
the session id).  To the backend server, it is entirely irrelevant
how many TCP connections there are established between a client
and the revers proxy -- and for protocols like HTTPS, these will
be terminated quite often.  For HTTPS, a client that shows a
different cert after renegotiation just doesn't make any sense
most of the time.  If the client wants to use a different cert,
he should open a new network connection.

If the reverse proxy or the backend wants to mitigate session-id-stealing
it might employ a memcmp() on the certificates forwarded by the
reverse proxy, and will rightfully abort if that changes.


A client architecture which allows the use of different client
certificates on different connects and does not reliably distinguish
TLS sessions established with different client properties
(anonymous, client cert A, client cert B, ...) is probably broken.


>
> 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.

Nope, that is not how it works.
A client that has not been previously authenticated
performs a client cert authentication.  That is a highlander operation.
Which of the TLS implementation actually keeps a set of certs/cert-chains 
for a TLS peer crowd created through renegotiation and has API calls
to iterate through them?  The implementations that I know have
only APIs to request "THE" peer certificate.

So if there actually are apps today that can handle a multitude
of client identites on a SSL/SecurityContext handle, they will likely
have to implement that at the app layer, because very few, if any
TLS implementations provide "a set of TLS peers".


-Martin