How the Secure Socket Layer – SSL works

I ran across few great articles explaining what SSL is, why we use it and how it works.
I made some modifications to the original docs.
You run into SSL or Secure Socket Layer every time you access your bank’s online portal, or any site that uses https protocol [aka secure protocol]. HTTPS uses SSL layer to convey information on a server-client highway. It protects confidential informations, your identity, password, bank account information by encrypting traffic between you, your browser and remote server. The server is responsible for advertising, establishing and maintaining secure communication as it sends among other things certificate claiming its validity and DN and public key over secure socket. This initial exchange takes split second and is tremendously important in todays digital world.
It follows reasonable expectation that you would not want to leave your front door open, while expecting the home to be safe.
Again as in real life, you are one that decides whether you want to use insecure, or compromised web site. You are warned by your browser that remote server certificate is invalid, and that can happened for various reasons.
So here is deeper look into what is happening in this mysterious digital electronic highway.
Again, most of this article has been compilation of publicly available documents from Oracle blogs, and public domain articles.
The rest is my interpretation of the same.
SSL uses PKI and Symmetric Key Technologies.
It uses Symmetric Encryption, Public/Private Key (Asymmetric) Encryption, and Digital Signatures.
How an SSL Connection is established?
Lets say we want to access the following site via SSL:
  • The browser and web server establish the SSL protocol version, Ciphersuite, and a Session ID. The Protocol and Ciphersuite negotiated depends on the version of the browser and the web server used. SSL Protocol versions are SSLV2, SSLV3 and TLSV1, with SSLV3 being the most common. The SSL Ciphersuite outlines the following:
    • The Key Exchange Algorithm – how the client and server exchange symmetric keys, i,e RSA or Diffie-Hellmann)
    • The Symmetric Encryption Algorithm e.g. RC4 128bit or DES 56bit
    • The Message Digest function i.e. MD5 (128bit), or SHA-1 (160bit)
    • For the purposes of this explanation the negotiated Ciphersuite is RSA-RC4128-MD5
  • The server sends the certificate to the browser
  • The browser takes the certificate, and checks via the trusted CA certificate that the certificate is valid. It contains the validity date, DN of the Issuer CA, the webserver’s public key and the CA’s digital signature
  • The client checks that the certificate is valid as per today’s date and the certificates validity period.
  • It then checks that the Issuer DN matches the DN on the clients list of trusted CA’s certificates. These are stored in the browsers trusted certificate list. If it matches one of the trusted CA’s certificates then we have proved that the issuing CA is trusted. In this case the certificate for was issued by “OU = Secure Server Certification Authority ,O = RSA Data Security, Inc., C = US”. As this is a common certificate provider it ships with most browsers by default.
  • Next the digital signature is decrypted using the CA’s public key, which it has as it is contained within the CA’s certificate stored in the browser. Then the original certificate is put through the hash to produce a digest. If the two digests match we know that the certificate was issued by the trusted CA and has not been tampered with.
  • Next, the Subjects Common Name (CN) from the Subjects DN, is checked against the hostname of the server where the certificate came from, to prove it came from the server. In this case we made a connect to , so the browser checks the Subjects CN matches. As the certificate has “CN =” then this test is passed
  • If everything checks out, the browser can now trust that it has the servers public key. In this example all the tests succeed. If however it doesn’t check out then the user is informed of the problem via a warning message. Lets say for example that the Certificate had expired, in this scenario the warning message would be displayed: “The security certificate is expired or not yet valid”
  • Now the browser has the webservers public key, the browser requests that the server proves it’s identity again by sending a randomly piece of generated data for it to digitally sign.
  • The server produces a digest of the data using the hash, encrypts it with its private key, and sends the digital signature.
  • The browser receives the digital signature and decrypts it using the servers public key to produce a digest, and then puts the original random data though the hash algorithm to produce another digest.
  • If the two digests match then the server has proven it’s identity.
  • The browser and server then exchange symmetric encryption keys using the Key Exchange Algorithm (KEA) defined in the negotiated ciphersuite. In our example the negotiated KEA was RSA .
  • At this point the SSL Handshake is complete and these symmetric keys are then used to encrypt and decrypt data over the session using the encryption algorithm negotiated at the beginning of the session i.e RC4128
  • Any data transmitted is also put through the negotiated hash algorithm (MD5) to prevent tampering
Symmetric Encryption
  • Both parties in the conversation use the exact same symmetric keys for encryption and decryption. The symmetric key is kept secret between both parties
  • All data is encrypted into a cipher using the symmetric key and transmitted over the network.
  • The recipient takes the cipher and decrypts it using the same symmetric key
  • How the symmetric key is generated on both sides of the conversation is dependant on the Key Exchange Algorithm
  • Examples of Symmetric Key Excahnge Algorithms are RSA and Diffie Hellman
  • All Browsers use RSA Key Exchange Algorithm when exchanging Symmetric Keys
  • Products like Advanced Security Option for Oracle Net can use RSA or Diffie-Hellman for key exchange
  • Each symmetric key uses a Symmetric Key Encryption Algorithm. The most common Encryption Algorithms are: RC4 and DES
  • The longer the key the more secure the data and RC4 and DES can encrypt at different key lengths
  • RC4 can encrypt at 256, 126, 56, and 40bits – DES can encrypt at 3DES168, 3DES112, 56 and 40 bits
  • Advantages: Extremely quick encryption and decryption
  • Disadvantages: Key deployment is complex

PKI Encrpytion

  • Different to symmetric encryption in that both parties in the conversation have their own individual private and public key pair.
  • What one key does the other key undoes i.e if you encrypt with the public key you decrypt with the corresponding private key.
  • Encryption always uses the recipients public key i.e if a client wishes to send data to the server, it encrypts it with the servers public key. The servers private key is then used to decrypt it
  • The private key must be kept private and nobody but the owner should have access to it
  • Public and Private Keys are always generated using one algorithm (RSA)
  • Public/Private Keys have a key length also. The longer the key the stronger the encryption
  • Common key lengths (strongest first) are: 2048, 1024, 512bits
  • In Internet SSL connections, the most common public key length is 1024bits
  • Also known as ‘Asymmetric Encryption’
  • Advantages: Key deployment is easier
  • Disadvantages: Encryption/Decryption is extremely slow. Everyone wishing to have a conversation would have to have their own public/private key pair
  • Note: Bulk Encryption with private/public keys never happens in reality due to slowness and the fact everyone has to have a public/private key pair. It is only ever really used for performing authentication and symmetric key exchange. See the later SSL section.

Digital Signatures

  • Digital Signatures determine the authenticity of the message i.e has it been tampered with it.The data to be sent is put through a one way hash algorithm to produce a Digest
  • The digest is then encrypted using the encryption key to produce a Digital Signature
  • The recipient takes the Digital Signature and decrypts it using the relevant key to produce the Digest
  • The recipient takes the original data and puts it through the same algorithm the sender used, to produce a Digest
  • The recipient compares the two digests, and if they match then the message has not been tampered with
  • The most common One-Way Hash Algorithms are MD5 and SHA1


  • If using public/private keys, how do we know if the public key we have received is from the server itself or from elsewhere?
  • Some method of authentication is needed and Certificates provide this
  • A certificate is a means by which a client or server can identify the third party with whom it is having a conversation
  • To prove the server is who it says it is, it has a Certificate, which associates its public key with the real identity of the server itself.
  • A certificate includes the following information:
    • Subject Name – the owners distinguished name
    • Subject’s Public Key
    • Issuer – the issues distinguished name
    • CA’s digital signature – a hash of all the data in the webservers certificate, encrypted with the CA’s private key
    • Certificate Validity Dates -when the certificate is valid from, and its expiry date
    • Administration information – Version/Serial Number
    • Extended information – constraints, browser flags etc
  • So if a browser connects to, the contents of the certificates are as follows:
    • Subject Name: “CN =, OU = Global IT, O = Oracle Corporation, L = Redwood Shores ,S = California, C = US”
    • Subjects Public Key: RSA (1024 Bits)
    • Issuer: OU = Secure Server Certification Authority ,O = RSA Data Security, Inc., C = US
    • Signature Algorithm: sha1(RSA)
    • Valid From: 16 June 2003 00:00:00, Valid To: 15 June 2005 23:59:59
    • Version: V3
    • Serial Number: 7731 4540 FD6E 1385 2512 6234 3A22 A271
    • Using all this information, the client can determine whether or not the public key in the certificate is from the server itself. A more indepth look into how a client uses these details can be found in the ‘How an SSL Session is established section
  • More on types of Certificate later

More on Certificates

Server Certificates can be obtained from many online vendors, or software can be bought or downloaded that allows you to generate you own certificates e.g: OpenSSL. As there are many different vendors it is impossible to go through what everyone calls their server certificates, so we will outline the ones issued by two of the main Interent vendors: Verisign and Thawte.

Server Certificates:
There are 2 major types of server certificates, and their marketing name varies depending on the Certificate Authority issuing the certificate.
1. Global Server ID’s (GSID) (issued by Verisign)
Global Server Certificates, sometimes known as Server Gated Cryptography or 128bit certificates, are certificates that enable all browsers to use 128bit symmetric encryption, even if the browser is an Export browser where only 40bit symmetric encryption is allowed. A GSID usually has two parts, the certificate itself, and an extra intermediate certificate, which is used to provide the step-up. This is useful because of past export regulations where only Export browsers could be used outside the US. Now export regulations are relaxed new browsers can use 128bit encryption world-wide. As outlined earlier the names of these certificates vary. Thawte for example, calls these certificates 128bit SuperCerts. These types of certificates should not be necessary at this point in time as all the latest browsers support 128bit symmetric
2. Secure Server Certificates (issued by Verisign)
These are sometimes called 40bit certificates. However, they will allow 128bit bulk encryption or higher if both the web server and client browser support 128 bit symmetric encryption or higher. This sounds illogical but it is down to the ciphersuites used for generating the symmetric key. Thawte calls these certificates SSL Certificates.
In reality there is no such thing as a 40bit or 128bit certificate. They both support the same levels of encryption, it’s just that GSID’s will allow old export type browsers to use SSL Symmetric Encryption at 128bit. The certificates can be said to have a key size, but it refers to the length of the public key contained in the certificate (I.e 512/1024/2048 bits). The names of the Certificates were chosen purely for marketing reasons.
Client Certificates:
In most Internet applications the server sends a certificate to the client for the purposes of server authentication. In SSL it is also possible for a server to ask a client to authenticate itself to provide extra security. This is not common practice in most Internet applications, but is common in web based Intranet applications. In this scenario, both the client and server both have a certificate, and the server will perform the authentication against the client as well. If client authentication is desired, then a client certificate needs to be issued for your browser/application. These are available via Internet vendors like
Verisign or Thawte, and also using commercially avalaible software like Oracle Certificate Authority, Netscape Certificate Server, RSA Keon Server. If a browser is used, then the private key for the corresponding client certificate is stored within a browser database usually protected with a password. If using somebody like Versign or Thawte for the client certificates, then all the private key generation is performed by a combination of the browser and the Web site. During generation you will be asked for a PIN which you will need to enter when you make a SSL connection if the server requires client authentication. Client certificates are sometimes referred to as Personal Certificates. Client certificates contain the same information as a server certificate, however they do not have a User Common Name (CN). Instead, they tend to have this attribute set to your full name or email address. When a server authenticates the client, it therefore does not do validation against a hostname.
Oracle online documentation:

Leave a Reply

Your email address will not be published. Required fields are marked *