On Sun, Nov 06, 2005 at 10:19:25PM +0000, Nick Kew wrote: > I'll sign my server. Same as I'll sign an httpd tarball if I roll one > for public consumption. You sign your server. Where's the problem?
The problem is that you'll have no protection against man-in-the-middle attacks, whereby an attacker impersonates you, or intercepts your traffic (decrypting it and re-encrypting it, allowing them to read and/or modify all communication on your supposedly 'secure' connection) For example, an attacker could redirect requests for www.yourdomain.com to their server, perhaps by spoofing the DNS, or by unplugging the cable somewhere between your ISP and your server and inserting their own server. Clients would be none the wiser. The attacker doesn't have your private key, so they would create their own key pair. As a result, the connecting client would see a *different* key than the one they would see if they connect to your server directly. The problem is, they have no way of telling which key is the one which belongs to you, and which one is the one which belongs to the attacker. If the client knows you personally, they can phone you up and ask for you to read the key fingerprint over the phone, or fax it to them. That doesn't scale very well. So generally the client has to rely on a third-party to sign the key: they trust the third-party to check your identity (i.e. you are the person who really owns www.yourdomain.com), and then they sign your key to confirm that you are the real owner. The attacker's key won't be signed, so the client's browser can tell the difference between your server and the attacker's server. Regards, Brian.
