Secure Sockets Layer

SSL works based on two keys, a private and a public key, known as a ‘keypair’. The process works something like this:

1. You click on an item, then click “Add to Cart“, and then click “Go to Checkout“.

2. This sends the customer to a secure, https website – and requests an SSL session to the site’s server.

3. The client browser will negotiate an ‘SSL Handshake’ with that server.

4. The server responds, automatically sending the customer its digital certificate, which authenticates the site.

5. Customer’s Web browser generates a unique “Pre-Master Secret Key” – it encrypts the Pre-Master key, using the site’s Public key so that only the site’s server can read the key.

6. The Pre-Master encrypted key is sent to the server, which decrypts the Pre-Master key with the private key.

7. Both customer and site server then create the final Master Secret Key (also called a session key. , which will be used for this session only.

8. A secure session is now established. The session key is now used to encrypt all communications between the customer’s browser and the site server until the transaction is completed.

In a nutshell, the client uses the public key to authenticate the private key’s signature.

These key pairs (public and private) are sometimes called Write and Read keys.

• The peers will have to agree upon how to do encryption/decryption.
• They exchange a Premastersecret; this is done with any of the key exchange algorithms available: RSA, Diffie-Hellman, or Fortezza-DMS.

When receiving the PreMastersecret, a Mastersecret is computed, and the PreMastersecret is erased from memory. This MasterSecret is used to generate key material, which is partitioned into the following secrets and keys:

• client write MAC secret.
• server write MAC secret.
• client write key = server read key.
• server write key = client read key.
• server write Initialisation Vector, IV.
• client write IV

To create an SSL session, a user will be taken to a domain whose URL begins with https.

• Then the client browser will verify any information contained in that site’s certificate.
• The client browser will also check that the Certification Authority (CA) is trusted by verifying the signature on that server’s certificate.
• Finally, the client browser will check that the browser’s domain name matches that of the certificate and will pop up a warning message if it does not trust one of the fields.
• Should the user continue with the transaction, it would be at his or her own risk – your credit card details could be going to a fraudulent site.
• You can view the certificate by right-clicking on the page, go to page properties, then certificates details, or alternatively, click on the padlock in the bottom right-hand corner (although this does not always appear).
• If all is in order, you can continue.

If all of the above comply, your credit card information should be secure. Nothing is, however, foolproof, as the aim of encryption is not to be unbreakable, as new technology is continuously being developed, but rather to make it inconvenient, so that the time needed to break it would put anyone off from trying!

Common SSL Session Key Exchange Algorithms used during handshake:

Common SSL Session Key Exchange Algorithms, used during handshake:   
 NULL,RSA,Diffie-Hellman RSA,Diffie-Hellman DSS,DHE_DSS,
 DHE_RSA,DH_anonymous, Fortezza/DMS  

 Common SSL Secret Key Algorithms for encryption:   
 NULL,  RC2,  RC4, IDEA, DES, 3DES, Fortezza   

 Common SSL Hash Algorithms for MAC:   
 NULL , SHA , MD5   

 Common SSL Certificates types:  
 X.509 v1,X.509 v2,X.509 v3 

NOTE: Some people download trial-ware that times out after 30 days, and to get around this, they set their PC clocks back by a year. Or, in some cases, their PC clock is off, for whatever reason. But if the clock is off – the SSL site certificates will cause a warning box to pop up because the browser compares the certificate dates with the system clock and warns you of the discrepancy.

TLS (Transport Layer Security) – SSL version 3.0, released in 1996, was later used as a basis to develop Transport Layer Security (TLS), an IETF standard protocol.TLS was first defined in RFC 2246: “The TLS Protocol Version 1.0“.Both the SSL and TLS protocols are layered beneath application protocols such as HTTP, SMTP, and NNTP and above the TCP transport protocol, which is part of the TCP-IP protocol suite.

TLS RFC’s include:

RFC 2712: “Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)“. The 40-bit cipher suites defined in this memo are included only to document that those ciphersuite codes have already been assigned.

RFC 2817: “Upgrading to TLS Within HTTP/1.1”, explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection.This allows unsecured and secured HTTP traffic to share the same well-known port (in this case, http: at port 80 rather than https: at port 443).

RFC 2818: “HTTP Over TLS“, distinguishes secured traffic from insecure traffic by using a separate ‘server port’.

RFC 3268: “AES Ciphersuites for TLS“. Adds enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites to the previously existing symmetric ciphers, like RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and Triple DES.

HTTPS (HyperText Transfer Protocol Secured) – HTTPS is simply an encrypted, secure form of HTTP.While both SSL and TLS can add security to any protocol that uses TCP, they are most commonly used in the HTTPS access method.

E-Commerce (Electronic Commerce) – SSL is the cornerstone of Internet E-Commerce.We have all seen HTTPS pop up as the beginning of a URL when we have gone to buy something on the Internet.HTTPS is used to secure World Wide Web pages for applications such as Electronic commerce.Both protocols use public-key cryptography and public key certificates to verify the identity of endpoints.

Like SSL on which it was based, TLS is a modular protocol designed to be extended, supporting forwards and backward compatibility and negotiation between peers.

Both TLS and SSL involve several basic phases:

• Peer negotiation for algorithm support.
• Public key encryption-based key exchange and certificate-based authentication.
• Symmetric cipher-based traffic encryption.

Some early SSL implementations were limited to 40-bit symmetric keys because of US Government restrictions on the export of cryptographic technology.

• The 40-bit keyspace was explicitly imposed to be small enough to be breakable by brute force search by law enforcement agencies wishing to read the encrypted traffic while still presenting obstacles to less-well-funded attackers.
• A similar limitation was required of Lotus Software’s Notes’ product in export versions.
• After several years of public controversy, a series of lawsuits, and eventual Government recognition of changes in the market availability of ‘better’ cryptographic products (within and without the US), some aspects of the export restrictions have been relaxed.

The 40-bit key size limitation has mostly gone away. Modern implementations use 128-bit (or longer) keys for symmetric key ciphers.