To add to the examples Philipp has mentioned, I've been closely involved in
the design and implementation of a number of projects for the Spanish
government using SSL + client certificates; indeed, the new Spanish ID card
includes two certificates, one for authentication and the other for digital

There are some examples of services using SSL+client certs at:

Jim Cheesman

-----Mensaje original-----
En nombre de Philipp Gühring
Enviado el: jueves, 31 de enero de 2008 3:04
Para: Eric Rescorla
CC: Cryptography; Rasika Dayarathna
Asunto: Re: Fixing SSL (was Re: Dutch Transport Card Broken)


> Huh? What are you claiming the problem with sending client certificates
> in plaintext is 

* It´s a privacy problem
* It´s a security problem for people with a security policy that requires
their identities to be kept secret, and only to be used to authenticate to 
the particular server they need
* It´s an availability problem for people that need high-security 
authentication mechanisms, combined with high-privacy demands
* It´s a identity theft problem in case the certificate contains personal
that can be used for identity theft

Quoted from Lynns email:
>i.e. the x.509 identity digital certificates from the early 90s, were 
>more and more overloaded with personal information ... and by the
>mid-90s, lots of institutions were starting to realize all that personal
>information represented significant privacy and liability issues ... and
>the RPO digital certificates were born.

* It´s a liability issue

(Lynn, can you go into more details here? On the other hand, I would say
self-explaining ...)

> (as if anyone uses client certificates anyway)? 

Guess why so few people are using it ...
If it were secure, more people would be able to use it.

If you want a "public" example of client certificate usage:
(You need a (free) client certificate from to be able to
this page)

There are ISPs out there who provide internet access based on client 
certificates, authenticated in HTTPS sessions

Creative Commons is running a registry for digital works, based on authors 
client certificate authentication:

The Austrian governmental inhabitant register is using client certificates
about 10,000 users all around Austria since 2001. (If I remember the details


And there are hundreds of internal systems I heard of that are using client 
certificates in reality every day.

> That the phisher gets to see the client's identity?

Validated email addresses for spamming. Spear-phishing perhaps, ...

> So what? 

Why doesn´t SSH leak the client identity in plaintext?

The problem isn´t a key-agreement problem. The problem is a 
client-authentication problem. 

> It doesn't let them impersonate the client to anyone. 

It does let them impersonate the client to anyone who doesn´t care about the

public key. (There are applications that just use the DN+Issuer information 
that they normally extract out of the certificates, ...)
But impersonation is just one threat out of the huge SSL/TLS threat-model.

> Certificates 
> shouldn't contain sensitive information anyway.

There are CA´s on this planet that put things like social security numbers 
into certificates.

(I guess those CA´s would say that SSL shouldn´t leak certificates in 
plaintext anyway.) Shovling around responsibility won´t help us. Let´s fix 
the problems. (Yes, we are already trying to get those CA´s to stop doing 
that ... but it´s a bit like asking credit card companies to not print those

sensitive creditcard numbers on those credit cards ...)

And there are a lot of people who would be interested to use certificates
more applications than pure identity. (which aren´t necessarily sensitive, 
but they are personal related data)

Where does the SSL specification say that certificates shouldn´t contain 
sensitive information? I am missing that detail in the security
section of the RFC.

There is a market demand for using sensitive information in certificates, 
dating back to the mid 90's (according to Lynn), and showing itself in 
various forms like Stefan Brands credentials, Attribute Certificates, and 
even the OACerts by Jiangtao Li and Ninghui Li. 
I have been talking to many people about client certificates and client 
authentication, and a lot of them are interested in using client
for authentication, and also to add other attributes to the certificates.

> > We have the paradox situation that I have to tell people that they
> > use HTTPS with server-certificates and username+password inside the
> > session, because that´s more secure than client certificates ...
> No it isn't more secure.

Using username+password inside HTTPS does not leak the client´s identity in 
cleartext on the line. (If I am wrong and HTTPS leaks usernames sent as HTTP

Forms or with HTTP Basic Authentication, please tell me)

> > Does anyone have an idea how we can fix this flaw within SSL/TLS within
> > reasonable timeframe, so that it can be implemented and shipped by the
> > vendors in this century?

Do we have any more ideas how we can get this flaw fixed before it starts 
hurting too much?

> This gets discussed on the TLS mailing list occasionally, but the
> arguments for making this change aren't very convincing.

Yes, there are regularly people popping up there that need it, but they
get ignored there, it seems.

I think we have the boiling frog problem here. (Frog not recognizing that
water in the pot gets hotter and hotter, since it happens to slowly and not 
at once ...)
Since all those people asked one after each other on the list, they were all

ignored, since everyone had just one single case and one single argument.
If they had come up at the same time and coordinated their arguments ...
(But I don´t think that we can blame all those people for not coordinating 
their arguments.)

We have an issue here. And the issue isn´t going to go away, until we 
deprecate SSL/TLS, or it gets solved.

> If you have 
> an actual credible security argument you should post it to

Do you think the the security arguments I summed up above qualify on the tls

list? Should I go into more detail? Present practical examples?
Or does it take a Slashdot article with some governmental CA´s certificates 
that contain social security numbers, some SSL sniffing logfiles, ... for
responsible people to react? Or is it possible that we can pro-act and fix  
this issue, without giving SSL and TLS a bad name in the press?
I am not interested in reading "SSL leaks personal details" in the media.

Has anyone counted the amount of people that asked for it in all the years
the TLS mailinglist? 

I see several possible options:
* We fix SSL  
Does anyone have a solution for SSL/TLS available that we could propose on
TLS list? 
If not: Can anyone with enough protocol design experience please develop it?

* We deprecate SSL for client certificate authentication.
We write in the RFC that people MUST NOT use SSL for client authentication.
(Perhaps we get away by pretending that client certificates accidently
into the specification.)

* We switch from TLS to hmmm ... perhaps SSH, which has fixed the problem 
Hmm, there we would have to write all the glue RFCs like "HTTP over SSH" 
again ...

* We will all have to answer nasty questions, why we didn´t do anything
it that SSL leaks personal certificates in plaintext ...

* We change the rules of the market, and tell the people that they MUST NOT 
ask for additional data in their certificates anymore

* Does anyone have any better and perhaps more realistic options?

Come on guys, let´s solve this issue together before it hurts.

Ok, what I can do to get it fixed?

Different topic: Fixing TCP/SSL

> > TCP could need some stronger integrity protection. 8 Bits of checksum
> > isn´t enough in reality. (1 out of 256 broken packets gets injected into
> > your TCP stream)  Does IPv6 have a stronger TCP?
> Whether this is true or not depends critically on the base rate
> of errors in packets delivered to TCP by the IP layer, since
> the rate of errors delivered to SSL is 1/256th of those delivered
> to the TCP layer. Since link layer checksums are very common,
> as a practical matter errored packets getting delivered to protocols
> above TCP is quite rare.

Try to send a DVD iso image (4GB) over a SSL or SSH encrypted link with bit 
errors every 10000 bits with a client software like scp that cannot resume 
downloads. I gave up after 5 tries that all broke down in average after 1
(In that case it was a hardware (bad cable) initiated denial of service 
attack ;-)

The problem is that you can´t work around this issue with standard software.

You can´t tell Putty or OpenSSH or any normal IP stack or any network card
add more protection there, to solve that problem. You could try to setup
tunneling to get more protection, but that´s usually highly impractical for 
copying a single file from one computer to the next.

If the link layer gives you 1/256, and the TCP layer gives you 1/65536, and 
the SSL layer demands 0/16777216, then end up with 1/16777216 too much.

(And there is no guarantee that the link layer actually gives you the 1/256.

It could also give you 1/1)

Best regards,
Philipp Gühring

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to