[18840] in cryptography@c2.net mail archive
Re: HTTPS mutual authentication alpha release - please test
daemon@ATHENA.MIT.EDU (cyphrpunk)
Fri Nov 4 17:26:56 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Thu, 3 Nov 2005 22:54:38 -0800
From: cyphrpunk <cyphrpunk@gmail.com>
To: Nick Owen <nowen@wikidsystems.com>
Cc: cryptography@metzdowd.com
In-Reply-To: <436A519E.60300@wikidsystems.com>
On 11/3/05, Nick Owen <nowen@wikidsystems.com> wrote:
> The token client pulls down a hash of the certificate from the
> WiKID server. It pulls the certificate from the website and performs a
> hash on it. It compares the two hashes and if they match, presents the
> user with the OTP and the message:
> "This URL has been validated. It is now safe to proceed."
Let me see if I understand the attack this defends against. The user
wants to access https://www.citibank.com. The phisher uses DNS
poisoning to redirect this request away from the actual citibank
machine to a machine he controls which puts up a bogus citibank page.
To deal with the SSL, the phisher has also managed to acquire a fake
citibank certificate from a trusted CA(!). He fooled or suborned the
CA into granting him a cert on citibank.com even though the phisher
has no connections with citibank. He can now use this bogus cert to
fool the client when it sets up the SSL connection to citibank.com.
Is this it? This is what your service will defend against, by
remembering the hash of the "true" citibank certificate?
Has this attack ever been used, in the history of the net?
CP
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
