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

From: Peter Gutmann <[email-masked]>
Date: Sat, 9 May 2015 12:55:42 +0000

Martin Rex <[email-masked]> 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 :-).

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 May 2015 15:59:58 +0200 (CEST)

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

You're obviously confusing application bugs with TLS bugs.

As previously mentioned, all TLS specifications up to and including TLSv1.2
have been extremely clear that the name contained in the certifcates
is a matter of the protocols & software layers on top of TLS,
and none of TLS business:

https://tools.ietf.org/html/rfc5246#page-5

                                  the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS. 

For (a part) of our code I am providing an abstraction that loads
the (external) TLS implemenation, provides configurability for certain
default behaviour, performs the client-side caching magic, and it
does provide an rfc2818 section 3 server endpoint identity check for
convenience, which the API caller can use or override.

The TLS(!) implementation itself, however, does not get to see the
server hostname.

Now the fashion this has been wrapped by higher application layers, it
is currently not possible for the _end_user_ to configure our (programmatic)
HTTPS client to skip server certificate path validation or server
endpoint identity checking, and some of the top-level apps programmers
are unhappy, because they have to properly document how to configure
their scenarios so that both checks succeed.

-Martin