[18851] in cryptography@c2.net mail archive
Re: HTTPS mutual authentication alpha release - please test
daemon@ATHENA.MIT.EDU (cyphrpunk)
Mon Nov 7 09:47:26 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Thu, 3 Nov 2005 14:26:55 -0800
From: cyphrpunk <cyphrpunk@gmail.com>
To: Nick Owen <nowen@wikidsystems.com>
Cc: cryptography@metzdowd.com
In-Reply-To: <43662F15.7060400@wikidsystems.com>
On 10/31/05, Nick Owen <nowen@wikidsystems.com> wrote:
> The system works this way: Each WiKID domain now can include a
> 'registered URL' field and a hash that website's SSL certificate. When
> a user wants to log onto a secure web site, they start the WiKID token
> and enter their PIN. The PIN is encrypted and sent to the WiKID server
> along with a one-time use AES key and the registered URL. The server
> responds with a hash of the website's SSL certificate. The token client
> fetches the SSL certificate of the website and compares it the hash. If
> the hashes don't match, the user gets an error. If they match, the user
> is presented with registered URL and the passcode. On supported
> systems, the token client will launch the default browser to the
> registered URL.
What threat is this supposed to defend against? Is it phishing? I
don't see how it will help, if the bogus site has a valid certificate.
> Most one-time-password systems suffer from man-in-the-middle attacks
> primarily due to difficulties users have with validating SSL
> certificates. The goal of this release is to validate certificates for
> the end user, providing an SSH-esque security for web-enabled
> applications such as online banking.
What does it mean to "validate a certificate"? Aren't certs
self-validating, based on the key of the issuer? Again, what is this
protecting against?
CP
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
