On Sat, 8 Apr 2006 01:39:37 -0700, David Schwartz <davids@webmaster.com> wrote:
>
> "Todd and Margo Chester" <ToddMargoChester@invalid.com> wrote in message
> news:e174ib$le1$1@emma.aioe.org...

>> Can someone point me to a explanation of how https
>> works? Is https the correct route to go?
>
> It's basically this:
>
> 1) The client connects to the server.
>
> 2) The server sends the client proof that it is in fact the server the
> client has asked for.
>
> 3) The client and server negotiate a shared secret known only to them
> using a mechanism such that no third party intercepting the communication
> could determine the shared secret.
>
> 4) The rest of the communication is encrypted and validated using that
> shared secret.

To add some essential detail:

2a: The server sends the client (1) the server's public key,
and (2) a certificate attesting that that public key
belongs to the client's internet address, signed by some
certification authority like Verisign.

2b: The client verifies that the public key and client
address are indeed the ones for which the certificate
was generated, and verifies that the certificate is
valid by referring to the client's database of
certificate-issuers' public keys (web browsers come with
this database built in).

3: The key-negotiation protocol guarantees to the client that
no eavesdropper can reconstruct the correct key without knowing
the private key that corresponds to the server's public key.

For Todd and Margos' application, it is significant that the
server has no guarantee of the client's identity. For normal
Web commerce, that doesn't matter, since the merchant (server)
will accept anybody's credit card number, but the customer
(client) doesn't want to give his credit card number to just
anybody.

I believe there are provisions for bi-directional SHTML
authentication, but I don't know.

Don't Todd and Margo really want a Virtual Private Network
(VPN)?

--
To email me, substitute nowhere->spamcop, invalid->net.