Subject: Re: [TLS] Asking the browser for a different certificate

From: Martin Rex <[email-masked]>
Date: Sat, 27 Mar 2010 02:14:10 +0100 (MET)

Peter Gutmann wrote:
> 
> Martin Rex <[email-masked]> writes:
> > 
> >IMHO there are a number of defects in the TLS protocol related to client
> >certificate authentication, and some of them should probably be fixed at the
> >TLS protocol level.  But fixes at the TLS protocol level may take a huge
> >amount of time before they become a useful feature in the installed base...
> 
> Yeah, because this is going to affect the vast numbers of users of
> SSL client certs :-).

The non-users of SSL client certs are much more affected.

Currently, if you enable a Web Server to request a client cert
in the initial handshake, the users without SSL client cert suffer
the worst user experience of all.  Would the browser be able to
tell the server in a ClientHelloExtension "Don't bother sending
me a CertificateRequest, because I don't have one", then
the server could skip the CertificateRequest message if the
application/configuration allows the handshake to complete without
client certificate.

> 
> >[Issues]
> 
> Couldn't a lof of this be handled via TLS extensions?

Sure.  Preferably with one single TLS extension that carries all the
necessary signals.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Sat, 27 Mar 2010 11:59:23 -0500

On 3/26/2010 8:14 PM, Martin Rex wrote:
>
> Would the browser be able to

That would be a significant information leak.

Consider an attacker passively sniffing public wifi in a coffee shop
near a targeted organization. Now he sees who has his smart card in the
reader and activated.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Mon, 29 Mar 2010 19:45:20 +0200 (MEST)

> near a targeted organization. Now he sees who has his smart card in the

To me this sounds extremely farfetched.

The ClientHello also "leaks" the maximum protocol_version that your
client supports, the cipher_suites and compression algs your client
is willing to use.

The reason why a client may be sending that information may be manyfold,
not necessarily a presence of a Smartcard.  A client could implement
a caching of a users decision to present a client cert, e.g. on a
per-server basis, or for a specific amount of time (for the next X hours).

For those users that use SmartCards enabled for TLS client cert
authentication, you will see their entire certificate flying by
in the clear in the regular TLS handshake when they connect
to the TLS server for which they plugged their SmartCard in the
first place.

And would you make your client include a "certificate URL extension"
even when the client does not have a client certificate.  Well, maybe
-- if you are the CIA and ordering your constant daily batch of pizzas.  :)

Maybe you should not use any secure authentication protocols like
Kerberos or TLS if you want to entirely hide that fact, that you possess
secure client credentials.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Mon, 29 Mar 2010 13:47:48 -0500

> To me this sounds extremely farfetched.

Really? It's pretty standard stuff

http://www.google.com/search?q=wifi+penetration+testing

> client supports, the cipher_suites and compression algs your client

Yes, there are lots of ways existing TLS clients can be fingerprinted.

> not necessarily a presence of a Smartcard.

True.

Still, as more TLS extensions get used in practice, I think each
extension's potential for info leakage needs to be well understood and
well documented.

> A client could implement

As you know, many web servers request the client cert under an existing
encrypted session via renegotiation specifically because they don't want
that to happen.

Passing the TLS record content type in plaintext (so the renegotiation
becomes visible to a passive observer) is another info leak that would
be good to fix.

> -- if you are the CIA and ordering your constant daily batch of pizzas.  :)

A. I think everyone should be able to order their pizzas over TLS! :-)

B. All cryptography used to be super secret spy stuff. But the trend has
been only accelerating over the years that data security practices that
were formerly considered paranoid are increasingly necessary for
business to resist corporate espionage and individuals to retain some
online privacy from intrusive ISPs and governments.

> secure client credentials.

Yep, those with the highest security requirements are better off
connecting only through a VPN, or not remotely at all. To some degree
this can be considered a failure of the existing security protocols.

Your "I don't have any client certs" extension suggestion is probably
not that big a deal, it's hard to tell. I think the deeper problem is
that TLS client authentication requires the client to transmit and sign
with his cert before he is able to strongly authenticate the server.

- Marsh

---

From: Kyle Hamilton <[email-masked]>
Date: Mon, 29 Mar 2010 12:36:52 -0700

I thought this was what the ADH ciphers were supposed to handle:
create a private channel, and then authenticate each end of that
channel inside the protection of the ciphered channel.

The "public WiFi" attack is much less far-fetched than you might
think.  10 years ago, it was preposterous -- nobody provided public
network links except libraries.  Now, though, you have airports that
offer free wifi.  Mineta San Jose International Airport provides a
link to an ipsec driver that will allow you to tunnel your wireless
packets via ipsec to their router; this suggests that they take
information-disclosure security very seriously.  Much more seriously
than you seem to be.

It's not just airports, though.  Between Santa Cruz and San Jose,
there's a fleet of buses operated by Amtrak that have wifi on board.

Information-disclosure vulnerabilities are things that I'd like to see
mitigated as much as possible.  Yes, I know it's impossible to know
that you're talking to the entity that you think you are, without
authenticating -- and it's impossible to authenticate without
providing some uniquely-identifying information.  However, limiting
that disclosure of information to one endpoint, most likely not on the
same subnet you are, mitigates a LOT of problems with someone near you
identifying you.

(Of course, requiring the client to identify itself before proceeding
with a handshake... that's something I wish that TLS provided for.  I
find it odd that ipsec provides for it -- but evidently computer
credentials for ipsec are supplicant-based, while user credentials for
TLS are applicant-based.)

-Kyle H

On Mon, Mar 29, 2010 at 10:45 AM, Martin Rex <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 29 Mar 2010 13:03:09 -0700

> channel inside the protection of the ciphered channel.

There is no way to know if you've negotiated ADH with an attacker.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Mon, 29 Mar 2010 15:02:17 -0500

On 3/29/2010 2:36 PM, Kyle Hamilton wrote:
> Of course, requiring the client to identify itself before proceeding
> with a handshake... that's something I wish that TLS provided for.

That should be supported by the TLS protocol, although you will need the
TLS library to call back into your code to give you a chance to abort
the handshake.

Nothing prevents you from defining an application protocol which assigns
the roles of TLS client and TLS server opposite from the underlying
transport layer. E.g., client makes a TCP connection to server, then the
TCP server sends a Client Hello to the TCP client. Once that connection
was established you could renegotiate to get mutual authentication.

You might have the client send a little initial hint if you want session
resumption to work in the usual direction. That's not part of TLS, but
it's not much different than using starttls in the middle of some other
protocol.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Mon, 29 Mar 2010 23:56:23 +0200 (MEST)

> encrypted session via renegotiation specifically because they don't want

I'm not sure that this was the original motivator for implementing
it that way, and that it is always a conscious decision of Web Server
admin, whose Web Server operates that way.

Another reason might be the desire to serve clients with certs and client
without certs from the same Server port, in particular for users
without client certs using non-Microsoft Browsers -- because of
the negative user experience impact of the CertificateRequest message
with most browsers default settings.

If you configure MS IIS6 on W2K3sp2 for "optional" client certs,
i.e. mixed access for clients with and without client certs, then
TLS session caching effectively doesn't work for clients without
client certs -- because they will be forced through a renegotiation
on each connect (including TLS session resumes).  I don't know what
particular problem there is why MS IIS6/W2K3sp2 does not cache
the meta-information that the client had actively declined a prior
CertificateRequest on renegotiation.

Although TLS renegotiation might "hide" client certs from
passive observers, like sniffable wifi environments, the attacker
could insert fake data into the TLS handshake without much hazzle,
e.g.  a fake ServerHello+ServerCertificate+CertificateRequest+ServerHelloDone
followed by some Fatal SSL Alert (bad_certificate,unsupported_certificate,
unknown_ca) and use an empty list of CAs in the CertificateRequest
message.  That will likely elicit the client cert in the clear
from those browsers that would be sending/using it to the real server.

Although this is going to result in a connection failure for that
particular TLS handshake, the attacker does not necessarily care--
if his objective is to obtain the client's TLS client cert.

> becomes visible to a passive observer) is another info leak that would

Things would become less clear to off-the-shelf network analyzers
that visualize network traffic, but you will gain little by this
for any competent traffic analysis near the client if that is
the only change to the protocol.

The size difference between
   ChangeCipherSpec+Finished
vs.
   Certificate+CertificateVerify+ChangeCipherSpec+Finished
is pretty significant.

And in regular usage scenarios, TLS renegotiation will result in a
new TLS session ID, and the change of the TLS session ID is going to be
visible on new/parallel/later network connections to the same server.

> A. I think everyone should be able to order their pizzas over TLS! :-)

Absolutely!

> this can be considered a failure of the existing security protocols.

Hiding this level of information (availability of secure client creds)
from traffic analysis will be pretty difficult.

It's doable for passive ob servers near the server if there are many
clients and "onion routing" is used.  But when the passive observer
is very close the the client he wants to observe (like on his network
segment), it becomes quite difficult for the client to hide from
traffic analysis with existing protocols, so that it hides even the
mere fact that the client uses secure/cryptographic credentials
for authentication.

> with his cert before he is able to strongly authenticate the server.

I would describe it a "don't bother to CertificateRequest me" extension,
and it could also be used by any (background) service that performs
downloads under TLS-protection with no access to the interactive
user's credentials/smartcard.

-Martin

---

From: Dale Gustafson <[email-masked]>
Date: Mon, 29 Mar 2010 18:49:05 -0400

FWIW, the more vexing problem is the browser that *always* requires the 
user to select a TLS-client certificate whenever there are two or more 
that satisfy website requirements.

See CA Siteminder's "certificate or forms" authentication method for one 
workable approach to providing user-auth service to a diverse user base, 
many of whom have no acceptable certificate for some (or all) use cases.

Best,

--dg

---

From: Kyle Hamilton <[email-masked]>
Date: Mon, 29 Mar 2010 16:22:45 -0700

> There is no way to know if you've negotiated ADH with an attacker.

There's no way to know if you've negotiated ADH with an attacker --
but you've only got one attacker, Mallory.  If you have a whole bunch
of Eve's out there, who's to say they won't be able to put two and two
together and pinpoint you for attack even if you haven't connected to
a Mallory?

There is no way to know that Mallory will not broadcast the fact that
you connected with him under the pretense of being someone else, but
if he does that he's admitting to digital fraud and deceit anyway.

In most cases, I believe that security policies should make it more
expensive to recover a message than the message is worth -- but not an
order of magnitude more.  Maybe twice as expensive.  The more CPU time
used in attacking, the more electricity must be used (many, many watts
get dissipated as heat), which costs money.  The more sets of eyes
looking at it, the more costly it becomes.

-Kyle H

---

From: Bruno Harbulot <[email-masked]>
Date: Tue, 30 Mar 2010 01:22:50 +0100

Hello,

On 27/03/2010 01:14, Martin Rex wrote:
> Peter Gutmann wrote:
>>
>> Martin Rex<[email-masked]>  writes:
>>>

A browser that would know it has no certificate to send would also know 
it doesn't need to prompt the user for one. As such, it could just send 
an empty Certificate message in response to the CertificateRequest 
(which is what already happens in Firefox, if you choose 'ask me which 
one to choose' and press 'Cancel'), without offering the user to choose 
a certificate amongst an empty list. That sounds purely a user-interface 
problem, then.
What would such a ClientHelloExtension add for this purpose (except 
saving a few bytes... although it seems that the CertificateRequest 
message can be one of the largest during the handshake if the 
certification_authorities list is long)?

Best wishes,

Bruno.

---

From: Marsh Ray <[email-masked]>
Date: Mon, 29 Mar 2010 20:22:24 -0500

On 3/29/2010 6:22 PM, Kyle Hamilton wrote:
> but you've only got one attacker, Mallory.

You can't know that, either.

If there were some way to know this (say IP hop count), you could simply
get a trusted party to "attack" you and thus gain immunity from other
attacks.

> If you have a whole bunch

This is a somewhat different question.

Yes, the possibility of detection and plausible deniability raise the
stakes for Mallory in the real world. But one of the main purposes of
TLS is to eliminate the possibility of such attacks. Therefore, TLS
itself cannot rely the tiniest little bit on the hope that some other
factor will mitigate mitm.

> if he does that he's admitting to digital fraud and deceit anyway.

Did you know your employer or your cell phone ISP is MITMing your
connections with trusted root certs pre-installed on the client they
gave you? They will of course have very reasonable explanations for why
this makes their network run better. When governments do it, they
needn't offer any explanations.

An interesting test case occurred the other day. It seems China (or the
DNS system itself) accidentally began MITMing and modifying DNS packets
for Chile and some of the US by broadcasting its own i.root-servers.net.

http://www.computerworld.com/s/article/9174132/China_s_Great_Firewall_spreads_overseas
https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005260.html

They modified DNS replies for Facebook, Twitter, and YouTube to redirect
them for something. Pakistan did something similar with YouTube's IP
netblock a few years back.

It only took network operators few days to figure out what was going on,
and these events were actually causing outages. Imagine a
narrowly-focused attack which had been tested to work well in advance.
These examples were done remotely with DNS and BGP. If the attacker
actually controls a network link or router, it could be done without
modifying source and dest addresses as seen by either the client or the
server.

> looking at it, the more costly it becomes.

The defender must succeed every time, but the attacker only needs to
succeed once.

Therefore, strategies involving relative costs or design complexity tend
to favor the attacker as message volume and/or value increases.

- Marsh

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 30 Mar 2010 10:24:44 -0400

What is this, a little geek humor? Jerry Seinfeld doing TLS standup?  It
gave me a good chuckle anyway.

If there exists an atomic mutual authentication protocol (nothing about
either party is revealed to the other until both become aware of the
other's authenticated identity), then it hasn't been written up as a TLS
ciphersuite.  Until that magic happens, ADH is a pretty standard way of
reducing ID exposure from an infinite number of attackers down to 1
active party and 0 passive parties.  That's a fairly significant
reduction.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marsh Ray

---

From: Marsh Ray <[email-masked]>
Date: Tue, 30 Mar 2010 09:50:35 -0500

On 3/30/2010 9:24 AM, Kemp, David P. wrote:
> ADH is a pretty standard way of
> active party

It doesn't reduce it to one active party because Malloy can't know any
better than Alice or Bob if one of his connections is itself being MITM'd.

One could imagine amusing scenarios where AT&T and China bump into each
other on the wire and begin to argue "hey, buddy, go get your own
Facebook connection".

http://mashable.com/2010/01/16/att-facebook-error/
https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005260.html

> and 0 passive parties.  That's a fairly significant
> reduction.

Defeating passive eavesdropping is important, but it's sufficient in
general.

In the past, people were on shared Ethernet and would naturally be in a
position to quietly observe every packet going by.

For several common types of attacks today it's no harder to modify the
packets than it is to observe them. Think of China and Pakistan DNS- and
BGP-jacking YouTube for recent examples.

- Marsh

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 30 Mar 2010 11:29:58 -0400

Neither AT&T nor China can authenticate themselves as facebook.com
(assuming the browser trust list is properly managed, all trusted
issuers are trustworthy, the user won't confuse facebook.com.cn with
facebook.com, etc.).  ADH does not protect against data stealing or
session hijacking in general; authenticated TLS performs that function.
The ADH tunnel protects just one small piece of data (the certificates)
from eavesdropping during the TLS authentication handshake.

If AT&T and China and 10 other players all insert themselves between the
user and facebook.com, they can all learn the identities of the user and
of facebook.  But none of them can view or modify any data sent over
mutually-authenticated TLS.

Social networking sites are not a useful example because they don't use
TLS for most pages and they don't do client authentication for the few
pages that do use TLS.  But if banking / medical sites actually used
client-authenticated TLS for all pages (instead of little
phish-prevention pictures and personal-knowledge questions and
passwords), then AT&T would be out of luck.

Dave

-----Original Message-----
From: Marsh Ray [mailto:[email-masked]] 
Sent: Tuesday, March 30, 2010 10:51 AM
To: Kemp, David P.
Cc: TLS Mailing List
Subject: Re: [TLS] [POSSIBLE SPAM] Re: Asking the browser for a
different certificate
Importance: Low

It doesn't reduce it to one active party because Malloy can't know any
better than Alice or Bob if one of his connections is itself being
MITM'd.

http://mashable.com/2010/01/16/att-facebook-error/
https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005260.ht
ml

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Tue, 30 Mar 2010 10:53:55 -0500

On 3/30/2010 10:29 AM, Kemp, David P. wrote:
> facebook.com, etc.).

My understanding is that cell phone carriers install their own trusted
root cert for that purpose. I don't know about China, but I would assume
it's at least sometimes the case.

"Below is a list of trusted root certificates which are pre-installed
with the iPhone 3.0 software"
http://support.apple.com/kb/HT3580

> ADH does not protect against data stealing or

DHE ciphersuites do not protect the client cert info. On an initial
handshake, the client cert info is passed in-the-clear before the Change
Cipher Spec message takes effect. When client certs are passed on
renegotiation, any effective ciphersuite protects the client cert info,
not just DHE ones.

But unless the client refuses to pass his client certificate except
during a renegotiation that occurs inside an well encrypted connection
with a strongly authenticated server, the client cert info is available
to active attackers. I don't know of any client apps that do this, it's
probably not allowed behavior for https.

> mutually-authenticated TLS.

I don't think facebook.com actually supports TLS mutual auth (i.e.,
client certs).

> passwords), then AT&T would be out of luck.

Or maybe those sites just wouldn't work on an iPhone, or from behind
corporate SSL-intercepting firewalls.

- Marsh