Secure Socket Layer

None of the techniques presented so far are really secure. The HTML pages send to your browser can be read by anyone, passwords can be sniffed and session ID's can be hijacked.

You should use HTTP on top of SSL (HTTPS) if you are handling sensible data.

SSL uses public-key encryption (slow, but secure) to establish a connection (the SSL handshake) and uses symmetric key encryption (fast, not as secure) after the connection has been established. If RSA Key Exchange is used the handshake works as follows:

  1. The browser connects to an SSL enabled server and asks the server to authenticate itself, sending a client_hello message containing the supported SSL version number and cipher algorithms
  2. The server selects the strongest cipher suite it supports and responds with a server_hello message, containg this information (and optionally request the browser to authenticate itself)
  3. The server sends its certificate.
  4. The client verifies the server certificate, which contains (among other things): the servers public-key, the server-name (e.g. www.itu.dk), a validity period and information about the Certificate Authority (CA) that has signed the certificate (e.g. Verisign or Thawte).
  5. The client sends a client_key_exchange message containing a 48 byte pre-master secret encrypted with the public key from the server certificate
  6. The client computes a shared master secret based on the pre-master secret.
  7. The server computes the same shared master secret based on the pre-master secret. Only the server having the private key can do this.
  8. The client and server starts communicating using symmetric key encryption based on the shared master secret.
This procedure takes time, but fortunately the results are cached, so it is only needed once.

You can read a more detailed Introduction to SSL (Sun) and look at netscape's site.