How HTTPS Works to Keep You Secure 🔐 and How it Differs From HTTP
With all the noise over the past couple of years about upgrading every website to use HTTPS & SSL, and with good reason.
If you need to know why use HTTPS there are numerous reasons.
There are many benefits to upgrading to HTTPS, including better search engine listings and performance. You also will be able to use more functionality in browsers. HTTPS is once of the three core requirements to be a progressive web app.
HTTPS is also required to unlock modern browser features like service workers and hardware APIs like WebUSB and Bluetooth access.
SSL means secure socket layer. But that protocol has been deprecated and replaced by Transport Layer Security (TLS). Because so many got used to using the SSL acronym we still use it, the two are interchangeable today, but the actual encryption is TLS, not SSL today.
In the past SSL certificates were expensive. That has changed today as most certificates are free. If you pay for a certificate you are buying a certificate with a more rigorous screening process and possibly insurance.
So how does HTTPS or SSL work?
HTTPS is a secure form of the HTTP protocol. It wraps an encrypted layer around HTTP, Transport Layer Security (TLS). Clients and servers communicate using HTTP it is now secure because of the TLS wrapper.
Why is HTTPS important?
What Is the Difference Between HTTPS and HTTP?
Is HTTPS Secure?
Is HTTPS Encrypted?
Attackers can't read the data crossing the wire and you know you are talking to the server you think you are talking too.
HTTPS is an acronym that stands for Hyper Text Transport Protocol Secure. The 'secure' part is important because it makes a huge difference.
HTTP is 'plain text', or a binary file (like an image) anyone can read or see.
HTTPS is based on public/private-key cryptography. There is a key pair:
- The public key is used for encryption
- The secret private key is required for decryption.
A certificate is a public key with a label identifying the owner.
How HTTP Works
Before diving into how HTTPS works, let's review how HTTP works.
HTTP is a request response protocol to communicate asynchronously between client and server.
For websites and pages the browser acts as a client and a web-server like Apache or IIS acts as server. The server hosts the files (like html , audio , video files etc) and returns are responds to client requests with the data. Depending on the request a response contains the status of the request.
The process involves a series of messages that go back and forth between the client and server. The process starts with initiating a connection. After that a process known as TCP slow start kicks in. At this point data is passed between the two parties via data packets and often requires multiple round trips.
TCP slow start is designed to gradually expand the amount of data traversing the wire each round trip. The initial packet size is 16kb and doubles on subsequent round trips until a max size is reached. This can vary, but tends to be around 4MB for most connections.
This process is used because the server does not know how much bandwidth the client can handle. Rather than overflowing the client the server uses a gentle size and continues to increase until a limit is found.
The HTTPS Stack
HTTPS requires a TLS certificate to be installed on your server. You can apply certificates to different protocols, like HTTP (web), SMTP (email) and FTP. An SSL or TLS certificate works by storing your randomly generated keys (public and private) in your server. The public key is verified with the client and the private key used in the decryption process.
HTTP is just a protocol, but when paired with TLS or transport layer security it becomes encrypted.
You may know TLS by another acronym, SSL. Secure socket layer or SSL was the original way we secured the Internet. As we evolved our standards, we retired SSL, but the acronym remains the more popular term for TLS.
If you look at a network Stack diagram HTTP is at the top, on top of TLS, which sits on top of the TCP and IP layers.
I know those are a lot of acronyms but don't worry.
When HTTP is combined with TLS you get HTTPS This secure version of HTTP.
The HTTPS Handshake
When your browser connects to an HTTPS server, the server will answer with its certificate. The browser checks if the certificate is valid:
- the owner information need to match the server name that the user requested.
- the certificate needs to be signed by a trusted certification authority.
If one of these conditions is not met, the user is informed about the problem.
When HTTP is used, a series of handshakes takes place.
The initial request is sent to the server for a verification. When the server responds that it is the desired server the client then sends a hello message.
At this point the communication becomes encrypted.
Is to exchange encryption keys or ciphers.
At this point the reader communication can proceed. The initial handshakes steps take place in a matter of milliseconds.
When HTTPS is used, Which Element of the Communication is Encrypted?
Once the HTTPS handshake is complete all communications between the client and the server are encrypted. This includes the full URL, data (plain text or binary), cookies and other headers.
The only part of the communication not encrypted is what domain or host the client requested a connection. This is because when the connection is initiated an HTTP request is made to the target server to create the secure connection. Once HTTPS is established the full URL is used.
This initialization only needs to occur once for each unique connection. This is why HTTP/2 has a distinct advantage over HTTP/1.1 since it multi-plexes connections instead of opening multiple connections.
The Passive Attacker
First, we need to look at how HTTP works. This stands for hypertext transport protocol and is how we move data across the Internet.
By design HTTP is not encrypted. This means that the data moving across the wire is visible to anybody who has access.
Bad guys can passively read packets moving across the Internet. This means they can read the text that you are sending and receiving. This is why using a secure protocol is important when transferring personal and sensitive data.
Let's take a common example, the coffee shop. Many of us go to coffee shops, restaurants and other public places with public Wi-Fi to do work and just hang out.
But if you knew what the bad guys could see you may second think the strategy.
Wi-Fi is uniquely susceptible because it is well, airborne. This means anybody with the intent of can see the traffic going across the air.
Attackers have been known to hang out in public Wi-Fi settings and just absorb the Internet traffic around them. They can then use sophisticated analysis to determine sensitive data that you may not have considered.
Are you doing research on important stock price?
Maybe you're researching data for important work project and that back I just happens to be a corporate spy.
Of course this is contrived but should serve the purpose to get your mind thinking about what might transpire.
So using HTTP, your Internet sessions are public domain. You have no true privacy.
Blocking the Passive Attacker
When using HTTPS, the passive attacker I described earlier no longer can read your data. That's because the actual data is wrapped by an encryption layer.
The only two parties that can read the data or the server and your browser.
The TLS (the acronym for Transport layer Security) layer acts like shield, blocking unwanted eyes from watching your conversation.
The Active Attacker or Man In the Middle Attack
Sometimes attackers are more aggressive. They set up their own infrastructures to reroute request. This is known as a Man in the Middle Attack.
Without using HTTPS you have no a surety you are talking to the desired server. And the server cannot determine if it really is talking to you.
With HTTPS, there is a level of data integrity that protects you from an attacker intercepting your requests and the server's responses. The certificates require that each end know how to encrypt and decrypt the data and only they know how to do this.
If you are wondering which TCP/IP protocol is a secure form of HTTP it is HTTPS.
I think getting into the details of how the encryption algorithms actually work is a little above the point of this post. But let's just say it will just be a bunch of gobbledygook without the keys to decrypt and encrypt the packets.
When you establish a secure connection to a remote server you are effectively blocking this active attack. A bag I cannot install something on an Internet router, for example, that would intercept request and route them to his server.
Just in case you think the bad guy fake a certificate, he can't, we at least he can't forge the certificate or try to decrypt the data with the public key. He won't have access to the private key.
See I told you encryption can be complex!
The certificate contains the public key of the web server. The attacker's proxy does not have the matching private key.
If the proxy forwards the real certificate to the client, it cannot decrypt information the client sends to the web server.
The attacker may try to forge the certificate and provide his own public key. This will destroy the signature of the certification authorities. The browser will warn about the invalid certificate.
Is HTTPS Secure?
From a purely technical sense yes. There are ways to attack and potentially hack the protocol, but they require compromising components outside the control of the client and server. And these attacks are not simple attacks.
- Break into any Certificate Authority
- Compromise a router near any Certificate Authority
- Compromise a Certificate Authority's recursive DNS server
- Attack some other network protocol, such as TCP or BGP
- A government could order a Certificate Authority to produce a malicious certificate (only speculative)
These attacks essentially mean the issuing authority is compromised. While CA's tend to be extra freaky about their security, nothing is absolutely perfect, but like I said and attack on these points is not a simple attack.
You should also note, TLS does not secure your server, it secures connections between your server and the client. If a hacker gets into your server it most likely will be another type of attack. They just can't sniff the data being transferred between the two nodes.
Wrapping it Up
HTTPS should be used everywhere. The excuses of the past are no longer valid.
By using HTTPS you are providing your visitors a secure connection. They can also have confidence the communication is with your server and not someone passively or actively peeking in.