Subject: Re: [TLS] cipher suites for protecting client credentials

From: Florian Weimer <[email-masked]>
Date: Tue, 20 Mar 2012 15:37:21 +0000

* Peter Gutmann:

> Hannes Tschofenig <[email-masked]> writes:
>
>>Just a thought that came to my mind: How often is client authentication via
>>certificates used in TLS in the real world?
>
> Use is practically nonexistent except for a small number of stovepipe
> applications, and certainly widespread public use is nonexistent.

What would qualify as "widespread use"?  Perhaps tens of thousands of
users in Germany who rely client certificate authentication in browsers
to access specific applications?

I recently had to debug a handshake issue, and even though the whole
service is wrapped in a quite different way, it does use Internet
Explorer, TLS and a client certificate underneath.  I was quite
surprised.

> So this approach is "solving" a problem that practically doesn't
> exist.

I'm not sure if the added complexity is worth the effort.  If this is
somehow addressed, the next thing on the list is the Server Name
Indication and the server certificate, I guess.

-- 
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: Tom Ritter <[email-masked]>
Date: Tue, 20 Mar 2012 15:52:14 -0400

> Indication and the server certificate, I guess.

My immediate reaction is that exposing the personal details of a user
connecting to a service is an issue, but exposing the details of the
service is less important.

It's not very difficult to set up a filter that watches all TLS
connections in a home/company/ISP/country (depending on your access)
and look for client certificate connections that include an email
address ending in .mil, or google.com, or acme.com where acme is any
of the 1000 interesting defense contractors, software manufacturers,
certificate authorities, or organizations whose employees enjoy
privileged access to something valuable.  It's a very scalable, very
low-noise, very good ROI type of espionage.  So I think encrypted
client certs that defend against such a passive adversary is a very
nice way to shut that down.  That's my biggest interest in this.

If I wanted to target an endpoint, like
vpnserver.oakridgelaboratory.gov, I could filter for a SNI
extension...  but it'd be easier and more interesting to just resolve
the domain name, and watch all IP traffic - a technique TLS can't
solve.  Protecting SNI/Server cert doesn't help there.  Protecting
them *does* help then you don't know the endpoint, but have a keyword
("oakridgelaboratory.gov")... but you would catch all TLS traffic
(noisy, low ROI). And when you have a target like that, the 'smart
attacker'* would just enumerate dns names, get IP addresses, and go
back to the IP logging.  There are lists of IP addresses that belong
to the RIAA, MPAA, and anti-piracy companies that are used in
blacklist firewalls to protect folks pirating.  I imagine there's
similar lists for "interesting and valuable IP space".

* i.e. me if I were into that sort of thing

-tom