Re: Public Key Infrastructure: An Artifact...
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.
Still confused... The original connection to www.amazon.com is an SSL connection, right? We are following an https: URL? (Otherwise, SSL would not even come into the picture.) If you do a DNS hack to redirect www.amazon.com to amazon.hackeddomain.com, the latter site will not be able to complete SSL handshaking without triggering a browser warning, will it? Are you suggesting that the server would reply to the SSL handshake with a NULL transform? I just checked my browser (Netscape) and it did not offer NULL as an option. The only ciphersuites offered in the client_hello message were: V2CipherSpec SSL_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; V2CipherSpec SSL_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; V2CipherSpec SSL_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; V2CipherSpec SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 = { 0x04,0x00,0x80 }; V2CipherSpec SSL_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 }; V2CipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; The server must choose from this list, and all of these require the server to respond with an RSA certificate. So it looks to me like the SSL protocol will not allow the redirection attack to work without triggering a user alert, unless there is some subtlety here... Ob
On Sun, 19 Nov 2000 obfuscation@beta.freedom.net wrote:
When the user goes to www.amazon.com, they get a plaintext http redirect to amazon.hackeddomain.com, which does check.
Still confused...
The original connection to www.amazon.com is an SSL connection, right? We are following an https: URL? (Otherwise, SSL would not even come into the picture.)
No, the attacker interferes with the very first connect to www.amazon.com, probably at the DNS level, and that's almost always done plaintext. -Bram Cohen
obfuscation@beta.freedom.net wrote:
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.
Still confused...
The original connection to www.amazon.com is an SSL connection, right? We are following an https: URL? (Otherwise, SSL would not even come into the picture.)
If you do a DNS hack to redirect www.amazon.com to amazon.hackeddomain.com, the latter site will not be able to complete SSL handshaking without triggering a browser warning, will it?
[snip]
So it looks to me like the SSL protocol will not allow the redirection attack to work without triggering a user alert, unless there is some subtlety here...
Definitely depends on the implementation, and perhaps browser settings.
participants (3)
-
Bram Cohen -
Dennis Glatting -
obfuscation＠beta.freedom.net