TSL is a security protocol that provides privacy and data integrity over Internet communications. TSL is quickly become a standard practice for building secure web apps.
After reading this article you will be able to:
Why Use HTTPS?
What Is Web Application Security?
Brute Force Attack
Transport Layer Security, or TLS, is a widely adopted security protocol designed to facilitate privacy and data security to communications over the Internet. A primary use case of TLS is securing the communication between web applications and servers, such as web browsers loading a website. TLS can also be used to secure other communications such as email, messaging, and voice over IP (VOIP). In this article we will focus on the role of TLS in web application security.
TLS was proposed by the Internet Engineering Task Force (IETF), an international standards organization and the first version of the protocol was published in 1999. The most recent version is TLS 1.2, which was published in 2008; version 1.3 is currently very close to publication and already in use by some web applications.
TLS evolved from a previous security protocol called Secure Socket Layer security (SSL), which was developed by Netscape. TLS version 1.0 actually began development as SSL version 3.1, but the name of the protocol was changed before publication in order to indicate that it was no longer associated with Netscape. Because of this history, the terms TLS and SSL are sometimes used interchangeably.
HTTPS is an implementation of TLS encryption on top of the popular HTTP protocol which is used by all websites as well as some other web services. Any website that uses HTTPS is therefore employing TLS security.
TLS encryption can help protect web applications from attacks such as data breaches, and DDoS attacks. Additionally, TLS-protected HTTPS is quickly becoming a standard practice for websites. For example, Google’s Chrome browser is cracking down on non-HTTPS sites and everyday Internet users are starting to become more wary of websites that don’t feature the HTTPS padlock icon.
Transport layer security is implemented on the application layer of the OSI model, which means it can be used on top of a transport-layer security protocol like TCP. There are three main components to TLS: Encryption, Authentication, and Integrity.
A TLS connection is initiated using a sequence known as the TLS handshake. The TLS handshake starts with a syn/syn ack/ack exchange similar to the one used in TCP, and then establishes a cypher suite for each communication. The cypher suite is a set of algorithms that specifies details such as which shared encryption key will be used for that particular session. TLS is able to set the matching encryption keys over an unencrypted channel thanks to a technology known as public key cryptography. The handshake also handles authentication, which usually consists of the server proving its identity to the client. This is done using public keys. Public keys are encryption keys that use one-way encryption, meaning that anyone can unscramble the key to ensure its authenticity, but only the original sender can generate the key.
Once data is encrypted and authenticated, it is then signed with a message authentication code (MAC). The recipient can then verify the MAC to ensure the integrity of the data. This is kind of like the tamper-proof foil found on a bottle of aspirin; the consumer knows no one has tampered with their medicine because the foil is intact when they purchase it.
Because of the complex process involved in setting up a TLS connection, some load time and computational power must be expended. The client and server must communicate back and forth three times before any data is transmitted, and that eats up precious milliseconds of load times for web applications, as well as some memory for both the client and the server.
Thankfully there are technologies in place that help to mitigate the lag created by the TLS handshake. One is TLS False Start, which lets the server and client start transmitting data before the TLS handshake is complete. Another technology to speed up TLS is TLS Session Resumption, which allows clients and servers that have previously communicated to use an abbreviated handshake.
These improvements have helped to make TLS a very fast protocol that shouldn’t noticeably affect load times. As for the computational costs associated with TLS, they are mostly negligible by today’s standards. For example, when Google moved their entire Gmail platform to HTTPS in 2010, there was no need for them to enable any additional hardware. The extra load on their servers as a result of TLS encryption was less than 1%.