Let's say an attacker wants to intercept your ``secure'' transactions
with hugebank.com. Here's what happens:
(1) The attacker obtains two IP addresses, say 1.2.3.4 and 9.8.7.6.
He also obtains a domain name, say secure-banking.dom.
(2) The attacker sets up a DNS record for hugebank.secure-banking.dom
pointing to 1.2.3.4. He sets up an SSL HTTP server on 1.2.3.4
that looks just like hugebank.com.
(3) The attacker sets up an HTTP server on 9.8.7.6 to respond to
hugebank.com with a redirection to hugebank.secure-banking.dom.
(4) You connect to hugebank.com. The attacker forges a DNS response
to convince your browser to connect to 9.8.7.6. Your browser is
automatically redirected to hugebank.secure-banking.dom.
(5) You see the familiar home page for HugeBank. Your browser informs
you that your connection to hugebank.secure-banking.dom is
cryptographically protected and immune to eavesdropping.
(6) Because you're a paranoid freak, you manually check the server
certificate. You see a signed document from VeriSign telling you
that hugebank.secure-banking.dom is ``HugeBank Secure Banking.''
(7) You have now been lulled into a false sense of security. You type
in your account number and password. Ten thousand other people do
the same thing. The attacker steals all your money.
The main difficulty for the attacker is to guess the time and ID of your
DNS request---but he won't bother if your name server is vulnerable to
buffer overflows! He'll simply break in and forge cache entries.
> Even if the attackers monitored all your network communications, they
> still would not have your web server's private key and its passphrase.
The attacker doesn't need that information. The client used an insecure
procedure to obtain the server's key, and ended up with the attacker's
key instead.
---Dan
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:12:21 PDT