From the previous post we talked about TCP and UDP protocols. There we talked about the reliable data transmission. The connection created between the server and the client must be secure to prevent eavesdropping or other kind of data security violations. For this purpose we can use Transport Layer Security or the TLS protocol. Actually TLS is the successor to the mostly known SSL or the Secure Socket Layer. From the previous post we talked about layers in the TCP architecture. Both TLS and SSL are on the application layer of that architectue.


Here the security concerns about three things,

  1. Encryption : A mechanism to obfuscate what is sent from one computer to another.
  2. Authentication : A mechanism to verify the validity of provided identification material.
  3. Integrity : A mechanism to detect message tampering and forgery.


In TCP we talked about the three way handshaking in creating the connection between the client and the server. Same thing should happen in the TLS as well. In the TLS handshake procedure an encrypted tunnel should be negotiated before sending data. The client and the server must agree on the version of the TLS protocol, choose the ciphersuite, and verify certificates if necessary. Those are the things done in the TLS handshaking. Same as the three way handshaking, this TLS handshaking will increase the latency.


In the encryption step it uses one of the two methods below,

  1. Symmetric key cryptography (Private key) : Use the same key for both encryption and decryption.
  2. Asymmetric key cryptography (Public key) : Use the public key for encryption and the private key for decryption.

Using the openssl speed <encryption_algorithm> method we can find the speed pf differnet algorithms.


How ever using the Public key encryption can provide the best security and the Private key encryption can provide the efficiency.

The extra latency and computational costs of the full TLS handshake impose a serious performance penalty on all applications that require secure communication. To help mitigate some of the costs, TLS provides an ability to resume or share the same negotiated secret key data between multiple connections.

  1. Session Identifiers : When the server sends the “Server Hello” message, it can include a session identifier. The client should store it and present it in the “Client Hello” message of the next session. If the server finds the corresponding session in its cache and accepts to resume the session, it will send back the same session identifier and will continue with the abbreviated SSL handshake. Otherwise, it will issue a new session identifier and switch to a full handshake.
  2. Session Tickets : In the last exchange of a full SSL handshake, the server can include a “New Session Ticket” message which will contain the complete session state. Therefore, this state is encrypted and integrity protected by a key known only by the server. This opaque datum is known as a session ticket.


Authentication is an integral part of establishing every TLS connection. After all, it is
possible to carry out a conversation over an encrypted tunnel with any peer, including
an attacker, and unless we can be sure that the computer we are speaking to is the one
we trust, then all the encryption work could be for nothing. There are three types used,

  1. Manually specified certificates : Every browser and operating system provides a mechanism for you to manually import any certificate you trust. How you obtain the certificate and verify its integrity is completely up to you.
  2. Certificate authorities : A certificate authority (CA) is a trusted third party that is trusted by both the owner of the certificate and the party relying upon the certificate.
  3. The browser and the operating system : Every operating system and most browsers ship with a list of well-known certificate authorities. Thus, you also trust the vendors of this software to provide and maintain a list of trusted parties.

By clicking on the padlock sign on the browser you can get information about the chain trust and certificate authority.





As we talked earlier TLS handshake procedure add an extra latency and computational costs to the communication process. So TLS optimization is needed in order to provide more efficient mechanism.

  1. Do TCP optimization.
  2. Replicate or cache your data and services on servers.
  3. Session caching and stateless resumption.
  4. Consider about the TLS record size.
  5. Disable TLS compression.
  6. Minimize the size of your certificate chain.
  7. Enable OCSP stapling.
  8. Append HTTP Strict Transport Security.
  9. Upgrade TLS libraries to latest release.

Hope now you have an idea about what is TLS and how to do TLS optimizations for better performance. See you soon with another interesting topic. Thank You!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s