Re: [TLS] Summarizing identity change discussion so far

[<[e-mail]>]

Marsh Ray wrote:

> [e-mail] wrote:
> > The security considerations section of this draft has to describe the
> > fact that even with this fix, renegotiation does things that will
> > surprise application developers,
> 
> Does it? This fix ensures that the same party is on each end for the
> entire connection.
> 
> This rules out a MitM switching connections around. So the only
> remaining issues must involve a client or server being able to switch
> between certificates that he actually does have the private key for.
> Clients are already expected to validate the server cert for any
> protection.
> 
> My impression is that the most surprising thing about renegotiation for
> most app developers is that it can happen at all, and that their TLS
> library may be silently handling it by default. If we make any
> recommendations for TLS libraries it should be to not do renegotiation
> unless the application asks for it by registering a callback.

I think the fact that "getPeerCertificate()" and similar API calls
can return a different value each time they're called would be a
surprise to most app developers.

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

Well, although the example in James Manger's email is not real (in the
sense that it's not from real code), I think it's plausible, and it
doesn't involve an app 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...

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

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

Best regards,
Pasi