TSL & SSL

SSL (Secure Sockets Layer) is the predecessor to TSL (Transport Layer Security). These protocols have been established to provide a secure means of transmitting information over the internet. Example uses could be email, web-surfing, instant messaging, etc. Save it be for a few differences, SSL and TSL work the same way.

TSL/SSL establish a secure connection in the following steps:

• Peer negotiation for algorithm support
  • Client initiates the contact with the server. The client and server then determine a common algorithm and configuration to use.
• Key exchange and authentication
  • Private/Public key system is used. Using the private key to encrypt, an identical session key is delivered back to the client. The session key will remain valid throughout the predetermined duration (usually in minutes) or until the client or server terminates the session or connection.
• Symmetric cipher encryption and message authentication
  • Message is authenticated using a Certificate Authority.

Note the following from Wikipedia -

How it works

“SSL handshake with two way authentication with certificates.

A TLS client and server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection’s security.

• The handshake begins when a client connects to a TLS-enabled server requesting a secure connection, and presents a list of supported ciphers and hash functions.

• From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision.

• The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA), and the server’s public encryption key.

The client may contact the server that issued the certificate (the trusted CA as above) and confirm that the certificate is authentic before proceeding.

• In order to generate the session keys used for the secure connection, the client encrypts a random number with the server’s public key, and sends the result to the server. Only the server can decrypt it (with its private key): this is the one fact that makes the keys hidden from third parties, since only the server and the client have access to this data.

• From the random number, both parties generate key material for encryption and decryption.

This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes.

If any one of the above steps fails, the TLS handshake fails, and the connection is not created.”

See http://en.wikipedia.org/wiki/Secure_Sockets_Layer#How_it_works

(Information gathered from “Principles of Information Security”, Whitman/Mattord, pg 382-383)

Secure-HTTP

Secure-HTTP (designated as ‘https’ in the browser bar) is simply an extended version of HTTP that provides – you guessed it – security. Secure-HTTP is essentially SSL applied over HTTP – but it works differently in a few distinct ways.

• In a difference to SSL, a secure-HTTP is established to send a single message over the internet at a time, so secure-HTTP must establish a new connection each time it is used.
• Establishing a session entails the client and server having compatible cryposystems and an agreeing configuration.
  • The client can then send the serer its own public key so that the server can create a session key. The client’s public key is then used to encrypt the server’s session key. Both the client and server now having identical session keys, the transmission begins.
• Secure-HTTP support is built into modern browser for nearly universal use. Examples of use are email, banking, shopping, etc.

(Information gathered from “Principles of Information Security”, Whitman/Mattord, pg 382-383)