Fixing SSL (was Re: Dutch Transport Card Broken)

[Eric Rescorla]

At Thu, 31 Jan 2008 03:04:00 +0100,
Philipp Gühring wrote:
> 
> Hi,
> 
> > 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 the 
> 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 data 
> that can be used for identity theft

I don't find this at all convincing. There are a variety of different
threat vectors here:

1. Phishing.
2. Pharming (DNS spoofing).
3. Passive attacks.

In the case of phishing, the fact that the client sends its certificates
in the clear is totally irrelevant, since the client would simply send
its identity encrypted under the server's certificate. The only
fix for this alleged privacy leak in the phishing context is for
the client to refuse to deliver his certificate to anyone but people
who present valid certs that he otherwise trusts.

Now, this is potentially an attack if the attacker is passive but
on-path, either via pharming or via subverting some router, but
I'm unaware of any evidence that this is used as a certificate
disclosure attack vector.


> > (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.

No, if it were *convenient* people would use it. I know of absolutely
zero evidence (nor have you presented any) that people choose not
to use certs because of this kind of privacy issue--but I know
of plenty that they find getting certs way too inconvenient.


> > That the phisher gets to see the client's identity?
> 
> Validated email addresses for spamming. Spear-phishing perhaps, ...

Validated email addresses are not exactly hard to obtain.


> > 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, ...)

If those applications do not force the client to do proof of possession
of the private key, then they are fatally broken. It's not our job
to fix them.


> > > We have the paradox situation that I have to tell people that they should
> > > use HTTPS with server-certificates and username+password inside the HTTPS
> > > 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)

No, it just leaks the password to the phishing server. Yeah, that's totally
a lot better.



> > 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 always 
> get ignored there, it seems.

Because the arguments they present are handwavy and unconvincing, just like
yours.



> > If you have 
> > an actual credible security argument you should post it to
> > tls at ietf.org.
> 
> Do you think the the security arguments I summed up above qualify on the tls 
> list?

It's an open list. Feel free to make these arguments.


> Should I go into more detail? Present practical examples?

I would certainly find practical examples more convincing than the ones
you've presented.



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

There's already a solution: double handshake. You do an ordinary
handshake with server auth only and then you do a second handshake
with client auth. This hides the certificate perfectly well.  Yes, you
have to do two private key ops on the server, but if this issue is as
important as you say, this is a tradeoff you should be happy to make.
I've pointed this out on the TLS mailing list a number of times, but
maybe you missed it.


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

Fundamentally, this *is* the fix. Even if SSL guaranteeed that nobody
but the person you were handshaking with got the certificate, this
is still incredibly brittle because any random server can ask you
for your cert and users can't be trusted not to hand them over.
The basic premise of certs is that they're public info. If you
want to carry private data around in them then you should encrypt
that data.



> > > 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 

If you have a connection with a .01 BER, then you need to run some sort
of error correction over the link, not complain that TCP doesn't solve
your problem. As a thought experiment, consider that a .01 BER used
with a standard 1500-byte MTU means that nearly every TCP packet will
contain at least one error. If the TCP checksum caught all such errors
and dropped the packets, the effect on the TCP congestion control would
be catastrophic in terms of throughput. TCP was not designed to operate
correctly in settings with this kind of error rate.

More to the point, SSL/SSH are doing you a favor here: they're telling
you about bit errors that would otherwise be undetected corruption in
the file you moved around. The fix for this is to use client software
that can resume.

-Ekr

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com