Subject: [TLS] Proposal for detecting fraudulent certificates

From: Florian Weimer <[email-masked]>
Date: Mon, 26 Sep 2011 14:29:49 +0000

I have submitted draft-weimer-tls-previous-certificate-00, which intents
to facilitate detection of fraudulent certificates used in the wild:

<http://tools.ietf.org/html/draft-weimer-tls-previous-certificate-00>

The basic idea is to use leaks from mobile clients moving between
networks with and without a clear path to the server.  The previous
server certificate chain is included in the client hello, so the server
receives it when the client transitions to a network with a clear path.

This draft prompted my previous question about extension size limits.
Unfortunately, that issue makes this very simple idea somewhat
complicated, but I tried to add a fairly straightforward workaround.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Martin Rex <[email-masked]>
Date: Mon, 26 Sep 2011 18:05:57 +0200 (MEST)

> complicated, but I tried to add a fairly straightforward workaround.

Having the client send _only_ the servers certificate and not the
entire certificate path should IMO be sufficient for the purpose you
outline.

I don't know why you think the 64 KByte TLS extension size limit would
be a problem.

A non-marginal fraction of the installed base of TLS will puke when
encountering a TLS handshake message that is split/fragmented across
TLS record boundaries (which have a limit of 16 KByte).  The currently
most likely situation where this occurs (and the only one that
I've seen in the wild so far) are the CertificateRequest handshake
message contains a large number (60+) of certification_authorities.
Usually, the server tries to stuff the server response
(ServerHello,Certificate, CertificateRequest,ServerHelloDone)
into one single 16 KByte SSL Record, so even fitting the Server's
certificate chain alone should not normally be a problem.

But I don't see how this extension could realistically work in a
sane fashion.  The TLS implementation in TLS servers is not normally
keeping a history of previous TLS Server certificates which it ever
used (and might not have a persistence of its own for such a purpose),
usually not even across process restarts, and having TLS backends of
a Web-Server-Farm or hot-backups keep such a history in a consistent
fashion is even more unlikely.

And end users would probably prefer their TLS clients to tell them right
away when a server credential changes unexpectedly, rather than
a TLS server telling them, after they come home from a several weeks
trip through some contry YYY, that their last several week of connect(s)
had all been MITMd...

-Martin

---

From: Florian Weimer <[email-masked]>
Date: Mon, 26 Sep 2011 16:21:29 +0000

> entire certificate path should IMO be sufficient for the purpose you

I don't think it is.  The certificate itself is not proof of fraud if an
intermediate CA is involved.  More importantly, you cannot tell an
intercepting corporate proxy (whose certificate is not rooted in the
browser PKI) from a certificate which is.

> I don't know why you think the 64 KByte TLS extension size limit would

The wire format allows for larger server chains (up to 16 MB).  This
could be abused to bypass detection (just use a certificate with a
logotype extension).  I just felt I had to say something about that.

> fashion is even more unlikely.

The TLS server doesn't have to keep this information.  It just has to
log it or export it over an out-of-band mechanism to the application
(similar to what's already done for client certificates).  Client hellos
are clear text, so you would see the extension on an IDS host, too.

> trip through some contry YYY, that their last several week of connect(s)

This has UI issues which appear to unsolvable.  And even in web
browsers, not all TLS activity is user-initiated (e.g., software and
filter list updates).

Thanks for your comments.

---

From: Max Pritikin <[email-masked]>
Date: Mon, 26 Sep 2011 11:21:53 -0500

In the extreme case an invalid sub-CA certificate would be missed by this method unless clients send the entire chain, so I understand the author's motivation for completeness. 

The intention of this idea is to give web server administrators a tool for discovering fraudulent certificates in the wild. The concern isn't so much that a few individuals, perhaps even ones on a several week trip through evil country YYY, get MitM'd but rather that the web site administrator receives a clue within some "reasonable" timeframe. 

What defines "reasonable" and if it is sufficient to drive implementations toward supporting this extension is a harder question. 

- max

On Sep 26, 2011, at 11:05 AM, Martin Rex wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Mon, 26 Sep 2011 18:42:17 +0200 (MEST)

> browser PKI) from a certificate which is.

The Web Server certificate nails down the public&private key for the
server.  If a MITM has access to the servers private key, then
you've lost already, because that MITM can perform a perfect
impersonation for the client (the only thing that the MITM could
not do is a client-certificate authentication to the real server
(unless the real server lacks rfc5746 renegotiation protection).

> logotype extension).  I just felt I had to say something about that.

The client could decide to not talk to such TLS servers at all
(while theoretically not "standards compliant", it is what a
 non-marginal fraction of the installed base is doing...)

Are you aware of this Microsoft Hotfix:
http://support.microsoft.com/kb/2541763

(Curiously, Search on support.microsoft.com seems unable to find
 this hotfix for keywords.  I know about it because it was offered
 by Windows Update--my Windows machines are on "manuall install").

-Martin