In this comprehensive beginner's guide, we explain how HTTPS can be used to keep prying eyes and malicious actors away from the sensitive data transmitted by users from their web browser to your website, and how you can keep your web server secure with TLS/SSL encryption.
HTTPS (Hypertext Transfer Protocol Secure) is an extension of HTTP (Hypertext Transfer Protocol), that transmits encrypted data via SSL/TLS (Transport Layer Security). This means that even if the connection between a web browser (client), and the web server (server) is intercepted, the messages transmitted cannot be read. In this way, HTTPS is more secure than HTTP.
Because of this, HTTP will always be faster than HTTPS. However, the benefits of user privacy far outweigh any small impact on performance.
What is the HTTPS protocol?
HTTPS is a cryptographic protocol (the Hypertext Transfer Protocol Secure), that prevents data transmissions to and from web servers and browsers from being intercepted by unauthorized users. This reduces the likelihood of man-in-the-middle (MITM) attacks, although HTTPS alone is not enough to prevent MiTM attacks.
In order to utilize HTTPS, a website must first obtain an SSL/TLS certificate from a trusted certificate authority (CA), validating its identity and enabling encryption to create a secure connection. You can't use HTTPS without an SSL/TLS certificate. To create one:
Generate an encrypted Certificate Signing Request (CSR) for the SSL/TLS certificate
Buy an SSL/TLS certificate
Configure the SSL/TLS certificate
Verify the SSL/TLS certificate
Download and install the SSL/TLS certificate
This Public Key Infrastructure (PKI) system is used to authenticate users and devices and enables secure data sharing among validated clients (web browsers)/web servers (websites).
Why use TLS/SSL to encrypt your HTTPS data?
HTTPS data is encrypted and decrypted using the latest version of Transport Layer Security (TLS), the encryption protocol that replaces the previous and more commonly known Secure Socket Layer (SSL) protocol.
TLS/SSL encryption brings a number of significant benefits, leading to a trusted user experience:
Protection of sensitive user data from authorized access with secure key exchange
Protection from data interception attacks like packet sniffing and unauthorized surveillance
Compliance with data protection regulations that mandate the use of encryption to protect sensitive data
Ensuring data confidentiality by preventing private messages from being deciphered
Data integrity through cryptographic verification that the data has not been altered in transit
How is HTTPS data encrypted and decrypted?
There are four main steps in HTTPS SSL/TLS data encryption and decryption, which are outlined in detail below.
Step 1. TCP handshake
A TCP-synchronized message is sent to the server.
The server acknowledges the request.
The client and server establish a TCP connection.
Step 2. Certificate check
Agreement on how communication will take place, the version of TLS that will be used, and encryption algorithms/cipher suites (asymmetric encryption).
User and machine SSL certificates are exchanged that contain the public key, host name, and expiry dates to validate that the two parties are who they say they are.
The SSL certificate is validated and identity verified.
Step 3. Key exchange
An agreement in complete isolation that’s unique to their session through the creation of a unique pair of keys.
The client generates a session key and encrypts it using the public key.
The server receives the encrypted session key and decrypts it with the private key.
Step 4. Data transmission
Encrypted data flows between the client and server.
Because they hold the same session key, encrypted data is transmitted securely bi-directionally (symmetric encryption).
Why does HTTPS switch to symmetric encryption during data transmission?
Public Key Infrastructure (PKI) utilizes asymmetric and symmetric encryption, both of which have a distinct role to play in secure communications.
Asymmetric encryption: two different keys
Asymmetric encryption makes the HTTPS protocol possible. With asymmetric encryption, two separate keys are used for encryption and decryption. One of which is private, one of which is public. The public key is designed to be shared with anyone and is used to encrypt data that someone with the comparable private key can then decrypt. The private key (not to be shared with other users) is used to decrypt data that has been encrypted with the comparable public key.
The result is that secure, initial communication can take place without the need for the exchange of a secret key between the client and web server. Furthermore, by virtue of the private key encryption, communication can be confirmed as authentic and altered.
Symmetric encryption: the same key
Symmetric encryption uses a single key exchanged between the two parties during their session to encrypt and decrypt data, converting it from plaintext into ciphertext.
Why the shift to symmetric encryption during HTTPS transmission?
Both encryption methods play distinct roles in securing HTTPS transmissions. The initial, asymmetric encryption is used to verify the two parties and agree on the encryption they're going to use to communicate during their session. The subsequent symmetric encryption ensures the data sharing between the two verified parties during their session isn't intercepted.
It is also important to note that because asymmetric encryption only goes one way (from the client to the web server), if the server were to try and send encrypted data back to the client with their public key, anyone could be able to decrypt it! And because asymmetric encryption requires more resources, it is unsuitable for the transmission of lots of data during long sessions.
The shift from asymmetric to symmetric encryption is therefore designed to address as many different scenarios as possible. Because, as with all things security-related, utilizing an array of protocols and tools is a much more effective way of keeping data secure, than relying on a single method. The end result is that TLS/SSL is able to get the best of both worlds and mitigate any downsides.
What challenges do legacy applications present for HTTPS?
Before HTTPS there was HTTP, and so some older, legacy applications are still in existence that were not designed for TLS/SSL cryptography. This can lead to errors and broken protocols which can, in turn, introduce security vulnerabilities.
If you have legacy applications you need help with, or indeed modern apps that aren't performing in your technology stack as intended, or want support with an SSL/TLS configuration, speak to one of our technical experts.
Thinking of offloading TLS/SSL encryption to the load balancer?