[114359] in cryptography@c2.net mail archive
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
daemon@ATHENA.MIT.EDU (Philipp =?iso-8859-1?q?G=FChring?=)
Thu Jan 31 12:51:35 2008
From: Philipp =?iso-8859-1?q?G=FChring?= <pg@futureware.at>
To: Eric Rescorla <ekr@networkresonance.com>
Date: Thu, 31 Jan 2008 03:04:00 +0100
Cc: Cryptography <cryptography@metzdowd.com>,
Rasika Dayarathna <dayarathna@gmail.com>
In-Reply-To: <20080130170327.DF3EB5081A@romeo.rtfm.com>
X-MDaemon-Deliver-To: cryptography@metzdowd.com
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 acc=
ess=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 detail=
s=20
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=20
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 number=
s=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 th=
ose=20
sensitive creditcard numbers on those credit cards ...)
And there are a lot of people who would be interested to use certificates f=
or=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 considerati=
on=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 certificat=
es=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 shou=
ld
> > use HTTPS with server-certificates and username+password inside the HTT=
PS
> > 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 HTT=
P=20
=46orms 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 alw=
ays=20
get ignored there, it seems.
I think we have the boiling frog problem here. (Frog not recognizing that t=
he=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 al=
l=20
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 coordinatin=
g=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 tl=
s=20
list? Should I go into more detail? Present practical examples?
Or does it take a Slashdot article with some governmental CA=B4s certificat=
es=20
that contain social security numbers, some SSL sniffing logfiles, ... for t=
he=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 slip=
ped=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"=20
again ...
* We will all have to answer nasty questions, why we didn=B4t do anything a=
bout=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?
=2D------------------------
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 i=
nto
> > 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 G=
B.
(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 softwa=
re.=20
You can=B4t tell Putty or OpenSSH or any normal IP stack or any network car=
d to=20
add more protection there, to solve that problem. You could try to setup so=
me=20
tunneling to get more protection, but that=B4s usually highly impractical f=
or=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=
=2E=20
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
