[144779] in cryptography@c2.net mail archive
Re: Client Certificate UI for Chrome?
daemon@ATHENA.MIT.EDU (Ben Laurie)
Wed Aug 26 10:09:47 2009
In-Reply-To: <E1MaYmY-0004Xa-CF@wintermute02.cs.auckland.ac.nz>
Date: Wed, 26 Aug 2009 11:26:59 +0100
From: Ben Laurie <benl@google.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: jamesd@echeque.com, cryptography@metzdowd.com
On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmann<pgut001@cs.auckland.ac.nz> w=
rote:
> More generally, I can't see that implementing client-side certs gives you=
much
> of anything in return for the massive amount of effort required because t=
he
> problem is a lack of server auth, not of client auth. =A0If I'm a phisher=
then I
> set up my bogus web site, get the user's certificate-based client auth
> message, throw it away, and report successful auth to the client. =A0The =
browser
> then displays some sort of indicator that the high-security certificate a=
uth
> was successful, and the user can feel more confident than usual in enteri=
ng
> their credit card details. =A0All you're doing is building even more subs=
trate
> for phishing attacks.
>
> Without simultaneous mutual auth, which -SRP/-PSK provide but PKI doesn't=
,
> you're not getting any improvement, and potentially just making things wo=
rse
> by giving users a false sense of security.
I certainly agree that if the problem you are trying to solve is
server authentication, then client certs don't get you very far. I
find it hard to feel very surprised by this conclusion.
If the problem you are trying to solve is client authentication then
client certs have some obvious value.
That said, I do tend to agree that mutual auth is also a good avenue
to pursue, and the UI you describe fits right in with Chrome's UI in
other areas. Perhaps I'll give it a try.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com