HP3000-L Archives

October 2001, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Ken Hirsch <[log in to unmask]>
Reply To:
Ken Hirsch <[log in to unmask]>
Date:
Mon, 1 Oct 2001 22:18:16 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (32 lines)
Pete Osborne <[log in to unmask]> wrote:



> Hmmm. Now how exactly does that work?
>
> As I understand it.... When I connect to a site over https, I receive
their
> certificate or public key. When I send data to the site, it is encrypted
> using their public key and can only be unencrypted by their private key
which
> they keep locked away with a PEM phrase & restrictive permissions. Now,
how
> exactly is the data that is sent to my browser efrom the web server
> encrypted? How does my browser unencrypt it?

The client, after receiving and verifying the server's certificate,
generates a large random number, encrypts it using the public key found in
the certificate and sends it to the server.  The server decrypts it and uses
the random number as the basis for a key that is used for the remainder of
the session (or until one of them requests renegotiation).   This key is
used for both directions with a symmetric encryption algorithm.

The asymmetric key (public/private) is used only for exchanging keys and
verifying the certificate.  It is much slower than the symmetric algorithms.

Gory details at http://home.netscape.com/eng/ssl3/ssl-toc.html or, for the
successor to SSL, see http://www.rfc-editor.org/rfc/rfc2246.txt

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2