httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: pgp trust for https?
Date Tue, 08 Nov 2005 12:02:03 GMT
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.

Mime
View raw message