[114369] in cryptography@c2.net mail archive
RE: Fixing SSL (was Re: Dutch Transport Card Broken)
daemon@ATHENA.MIT.EDU (Jim Cheesman)
Thu Jan 31 15:15:31 2008
From: "Jim Cheesman" <jcheesman@grupoburke.com>
To: "=?iso-8859-1?Q?'Philipp_G=FChring'?=" <pg@futureware.at>,
"'Eric Rescorla'" <ekr@networkresonance.com>
Cc: "'Cryptography'" <cryptography@metzdowd.com>,
"'Rasika Dayarathna'" <dayarathna@gmail.com>
Date: Thu, 31 Jan 2008 19:24:39 +0100
In-Reply-To: <200801310304.01613.pg@futureware.at>
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
signature.
There are some examples of services using SSL+client certs at:
http://www.mir.es/MIR/Servicios_Telematicos/ConCertificacion/
Regards,
Jim Cheesman
-----Mensaje original-----
De: owner-cryptography@metzdowd.com =
[mailto:owner-cryptography@metzdowd.com]
En nombre de Philipp G=FChring
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)
Hi,
> Huh? What are you claiming the problem with sending client =
certificates
> in plaintext is=20
* It=B4s a privacy problem
* It=B4s a security problem for people with a security policy that =
requires
the=20
their identities to be kept secret, and only to be used to authenticate =
to=20
the particular server they need
* It=B4s an availability problem for people that need high-security=20
authentication mechanisms, combined with high-privacy demands
* It=B4s a identity theft problem in case the certificate contains =
personal
data=20
that can be used for identity theft
Quoted from Lynns email:
>i.e. the x.509 identity digital certificates from the early 90s, were=20
>becoming
>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=B4s a liability issue
(Lynn, can you go into more details here? On the other hand, I would say
it=B4s=20
self-explaining ...)
> (as if anyone uses client certificates anyway)?=20
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:
https://secure.cacert.org/
(You need a (free) client certificate from www.CAcert.org to be able to
access=20
this page)
There are ISPs out there who provide internet access based on client=20
certificates, authenticated in HTTPS sessions
Creative Commons is running a registry for digital works, based on =
authors=20
client certificate authentication:
http://www.registeredcommons.org/
The Austrian governmental inhabitant register is using client =
certificates
for=20
about 10,000 users all around Austria since 2001. (If I remember the =
details
correctly) http://zmr.bmi.gv.at/pages/home.htm
And there are hundreds of internal systems I heard of that are using =
client=20
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?=20
Why doesn=B4t SSH leak the client identity in plaintext?
The problem isn=B4t a key-agreement problem. The problem is a=20
client-authentication problem.=20
> It doesn't let them impersonate the client to anyone.=20
It does let them impersonate the client to anyone who doesn=B4t care =
about the
public key. (There are applications that just use the DN+Issuer =
information=20
that they normally extract out of the certificates, ...)
But impersonation is just one threat out of the huge SSL/TLS =
threat-model.
> Certificates=20
> shouldn't contain sensitive information anyway.
There are CA=B4s on this planet that put things like social security =
numbers=20
into certificates.
(I guess those CA=B4s would say that SSL shouldn=B4t leak certificates =
in=20
plaintext anyway.) Shovling around responsibility won=B4t help us. =
Let=B4s fix=20
the problems. (Yes, we are already trying to get those CA=B4s to stop =
doing=20
that ... but it=B4s 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
for=20
more applications than pure identity. (which aren=B4t necessarily =
sensitive,=20
but they are personal related data)
Where does the SSL specification say that certificates shouldn=B4t =
contain=20
sensitive information? I am missing that detail in the security
consideration=20
section of the RFC.
There is a market demand for using sensitive information in =
certificates,=20
dating back to the mid 90's (according to Lynn), and showing itself in=20
various forms like Stefan Brands credentials, Attribute Certificates, =
and=20
even the OACerts by Jiangtao Li and Ninghui Li.=20
I have been talking to many people about client certificates and client=20
authentication, and a lot of them are interested in using client
certificates=20
for authentication, and also to add other attributes to the =
certificates.
> > 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=B4s more secure than client certificates ...
>
> No it isn't more secure.
Using username+password inside HTTPS does not leak the client=B4s =
identity in=20
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
a
> > 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=20
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
always=20
get ignored there, it seems.
I think we have the boiling frog problem here. (Frog not recognizing =
that
the=20
water in the pot gets hotter and hotter, since it happens to slowly and =
not=20
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=B4t think that we can blame all those people for not =
coordinating=20
their arguments.)
We have an issue here. And the issue isn=B4t going to go away, until we=20
deprecate SSL/TLS, or it gets solved.
> If you have=20
> an actual credible security argument you should post it to
> tls@ietf.org.
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=B4s =
certificates=20
that contain social security numbers, some SSL sniffing logfiles, ... =
for
the=20
responsible people to react? Or is it possible that we can pro-act and =
fix =20
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
on=20
the TLS mailinglist?=20
I see several possible options:
* We fix SSL =20
Does anyone have a solution for SSL/TLS available that we could propose =
on
the=20
TLS list?=20
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
slipped=20
into the specification.)
* We switch from TLS to hmmm ... perhaps SSH, which has fixed the =
problem=20
already.
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=B4t do =
anything
about=20
it that SSL leaks personal certificates in plaintext ...
* We change the rules of the market, and tell the people that they MUST =
NOT=20
ask for additional data in their certificates anymore
* Does anyone have any better and perhaps more realistic options?
Come on guys, let=B4s 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=B4t 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=20
errors every 10000 bits with a client software like scp that cannot =
resume=20
downloads. I gave up after 5 tries that all broke down in average after =
1
GB.
(In that case it was a hardware (bad cable) initiated denial of service=20
attack ;-)
The problem is that you can=B4t work around this issue with standard =
software.
You can=B4t tell Putty or OpenSSH or any normal IP stack or any network =
card
to=20
add more protection there, to solve that problem. You could try to setup
some=20
tunneling to get more protection, but that=B4s usually highly =
impractical for=20
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=20
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=FChring
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to =
majordomo@metzdowd.com
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
