Re: [TLS] Update spec to match current practices for certificate chain order

[Peter Gutmann <[e-mail]>]

Martin Rex <[e-mail]> writes:

>A TLS client should not know or care about the hostname of the server it is
>talking to, and there is no requirement what kind of stuff is contained in
>the server's certificate.

Which is far too true, unfortunately, particularly among Android and iOS apps,
as recent research (e.g. "Why Eve and Mallory Love Android: An Analysis of
Android SSL (In)Security" and "The most dangerous code in the world:
validating SSL certificates in non-browser software") has pointed out.  Still,
not caring whether the supposed www.bankofamerica.com presents a cert for
www.qwertyuiop.com doesn't strike me as a sound security strategy.

>Our TLS client does _not_ know the server's hostname (it gets a connected
>socket).

So it's like all the insecure Android and iOS apps?

>I find it quite appalling how many broken TLS implementations out there fail
>to properly encode an ordered list of certificates into the Certificate
>handshake message.

That's really small beans compared to the huge numbers of apps that don't care
about what they're connecting to, one's a trivial (and arguably irrelevant)
protocol violation, the other is reducing the security of the TLS handshake to
anon-DH [0].

Peter.

[0] Whether browser PKI as currently practiced is much better than anon-DH to
    begin with is a debate for a different mailing list :-).