Re: Public Key Infrastructure: An Artifact...
Bram Cohen <bram@gawth.com> writes:
Unless that problem is fixed, man in the middle is hardly made more difficult - for example, Mallory could break into some random machine on the net and steal it's public key, then hijack local DNS and when someone goes to amazon.com redirect them to amazon.hackeddomain.com, and then proxy to amazon.com - now even SSL says the connection is safe.
Are you sure that works? I would think the SSL client would do a connection to the URL the user typed, www.amazon.com, and check the name in the cert to see if it (approximately) matches. If some DNS redirection is done in the background so that amazon.com gets mapped to amazon.hackeddomain.com, the client will not be aware of this (will it?) and so it will still throw up a warning when it sees a cert for hackeddomain.com on a connection to amazon.com. Ob
On Sat, 18 Nov 2000 obfuscation@beta.freedom.net wrote:
Bram Cohen <bram@gawth.com> writes:
Unless that problem is fixed, man in the middle is hardly made more difficult - for example, Mallory could break into some random machine on the net and steal it's public key, then hijack local DNS and when someone goes to amazon.com redirect them to amazon.hackeddomain.com, and then proxy to amazon.com - now even SSL says the connection is safe.
Are you sure that works? I would think the SSL client would do a connection to the URL the user typed, www.amazon.com, and check the name in the cert to see if it (approximately) matches.
When the user goes to www.amazon.com, they get a plaintext http redirect to amazon.hackeddomain.com, which does check. -Bram Cohen
participants (2)
-
Bram Cohen
-
obfuscation@beta.freedom.net