HTTP Lessons – Lesson 5 – Security
HTTP Lessons – Lesson 1 – Overview of basic concepts
HTTP Lessons – Lesson 2 – Architectural Aspects
HTTP Lessons – Lesson 3 – Client Identity
HTTP Lessons – Lesson 4 – Client Authentication Mechanisms
HTTP Lessons – Lesson 5 – Security
HTTP Lessons – Glossary
HTTP series If you've followed along, you're now ready to embark on your HTTP security journey. It'll be a fun one, I promise.
Many companies have suffered security breaches. Just to name a few: Dropbox, LinkedIn, MySpace, Adobe, Sony, Forbes, and many more have been at the receiving end of malicious attacks. Many accounts have been compromised, and you own an account on at least one of them.
Actually you can check it out here, Have I Been Pwned.
My email address was found on 4 different websites that were victims of a security breach.
Web application security has many facets, too many to cover in one article, but let's start at the beginning. First, let's learn how to secure our HTTP communications.
In this article, you will learn more about:
- Do you really need HTTPS?
- Basic concepts of HTTPS
- SSL-TLS
- TLS handshake
- Certificates and Certificate Authorities
- Certificate chains
- HTTPS vulnerabilities
There's a lot to cover, so let's get started.
Do you really need HTTPS?
You might be thinking, “Surely not all websites need to be secured.” Unless a website serves sensitive data or handles any form submissions, buying certificates and slowing it down just to get that little green checkmark in the URL bar that says “Secure” would be excessive.
If you have a website, it's very important that it loads as quickly as possible, so try not to load unnecessary things.
Why would you go through the hassle of migrating to HTTPS to secure your website when it didn't need to be protected in the first place? And you have to pay for it.
Let's see if it's really worth it.
HTTPS encrypts your messages and solves the MITM problem
In the previous installment of the HTTP series, we discussed different HTTP authentication mechanisms and their security flaws. The problem that both basic and Digest authentication fail to address is a man-in-the-middle attack. A man-in-the-middle attack is a malicious program that inserts itself between you and the website you're communicating with. Its purpose is to conceal itself by translating original messages in both directions and retransmitting the modified messages.
The original participants in the communication may not be aware that their messages are being listened to.
HTTPS solves the problem of MITM attacks by encrypting communications. Now, this doesn't mean your traffic can't be eavesdropped on. It does mean that anyone who listens in on your messages and intercepts them won't be able to see their content. They need a key to decrypt the message. We'll explain exactly how this works in a moment.
Let's continue.
HTTPS as a ranking signal
Recently, Google made HTTPS a ranking signal.
What does this mean?
This means that if you're a webmaster and care about your Google rankings, you should definitely implement HTTPS on your website. While it's not as powerful as some other signals like quality content and backlinks, it's certainly important.
By doing this, Google provides incentives to webmasters to switch to HTTPS as soon as possible and increase the overall security of the internet.
It is completely free
To enable HTTPS (SSL/TLS) for a website, you need a certificate issued by a Certificate Authority. Until recently, certificates were expensive and had to be renewed annually.
Let's Encrypt Thanks to the developers, we can get the certificate for free. Seriously, they are completely free.
It's a great community, with easy-to-install encryption certificates and major corporate support. Check out their main sponsors and list of supporting companies. You might recognize a few.
Let's Encrypt works with DV (Domain Validation). Each certificate has a 90-day lifespan and is automatically renewed.
Like any great technology, it has its downside. Because certificates are now readily available, they are being exploited by phishing websites.
It's All About Speed
Sites using HTTPS run much faster. httpvshttps.comTake a look at .
So what happened there? Why is HTTPS so much faster? How is that possible?
HTTPS is required to use the HTTP 2.0 protocol.
If we look at the Network tab, we'll see that in the HTTPS case, images are loaded over the h2 protocol. And the stream looks very different.
HTTP 2.0 is the successor to the currently prevalent HTTP/1.1.
It has many advantages over HTTP/1.1:
- Not textual, but binary.
- Full multiplexing, meaning it can send multiple requests in parallel over a single TCP connection
- Reduces overhead using HPACK compression
- Uses the new ALPN extension, which provides faster encrypted connections
- Reduces additional round trip times (RTT) so your website loads faster
and many more.
If you're not convinced yet, you should probably know that some browsers are waging war on unencrypted content. Google has made it clear how Chrome will treat insecure websites. a blog published.
Here's what it looks like before and after Chrome version 56.
Now it looks like this;
Still not convinced?
Switching to HTTPS is Complicated
This is also a relic of the past. While switching to HTTPS can be more difficult for long-established websites due to the sheer volume of resources loaded over HTTP, hosting providers generally try to make the process easier.
Many hosting providers offer automatic switching to HTTPS. It can be as easy as clicking a button in the options panel.
If you plan to host your website over HTTPS, first check if your hosting provider offers HTTPS relay. Or, if they have shell access, you can easily do it yourself with encryption and a little server configuration.
So, these are the reasons to switch to HTTPS. Is there any reason at all?
Hopefully, by now I've convinced you of the value of HTTPS.
Basic concepts of HTTPS
HTTPS stands for Hypertext Transfer Protocol Secure. Effectively, the client and server communicate over HTTP but over a secure SSL/TLS connection.
In the previous parts of the series, we learned how HTTP communication works, but what was the SSL/TLS part and why do we use both SSL and TLS?
Let's start with that.
SSL-TLS
The terms SSL (Secure Sockets Layer) and TLS (Transport Layer Security) used to be used interchangeably, but in fact, when someone says SSL today, they probably mean TLS. TLS is a newer technology.
SSL was originally developed by Netscape, but version 1.0 never saw the light of day. Version 2.0 was introduced in 1995, followed by version 3.0 in 1996, and although they were used for many years thereafter, the successor, TLS, was already gaining ground. This continued until 2014. The transition from TLS to SSL was supported by the servers and was the primary reason why the POODLE attack was so successful.
After that, the switch to SSL was completely disabled.
If you check yours or any other website with the Qualys SSL Labs tool, you'll probably see something like this:
As you can see, SSL 2 and 3 are not supported at all and TLS 1.3 is still not covered.
However, because SSL has been so prevalent for so long, it's become a term most people are familiar with and is now used for just about everything. So when you hear someone using SSL instead of TLS, it's simply for historical reasons, not because they're SSL.
Now that we've put that aside, I'll use TLS since it's more convenient.
So how do the client and server establish a secure connection?
TLS Handshake
Before the actual encrypted communication between the client and server begins, they perform what is called the “TLS handshake.”
It works like this (very simplified, links to additional information are below).
Once the connection is established, encrypted communication begins.
The actual mechanism is much more complex than that, but you don't need to know all the actual details of handshake implementation to implement HTTPS.
What you need to know is that there's an initial handshake between the client and server that exchanges keys and certificates. After this handshake, encrypted communication is ready to begin.
If you want to know exactly how it works, RFC 2246You can look at.
Certificates are being sent in the TLS handshake image, so let's see what a certificate represents and how it is issued.
Certificates and Certificate Authorities (CAs)
Certificates are a crucial part of secure communication over HTTPS. They are issued by one of the trusted Certificate Authorities.
A digital certificate allows website users to communicate securely while using a website.
For example, the certificate you use when browsing my blog looks like this:
For example, if you're using Chrome, go to the Security tab in Developer Tools (F12) to inspect the certificates yourself.
I want to point out two things. First, in the red box, you can see the certificate's true purpose. You can be sure you're only talking to the right website. If someone is impersonating the website you think you're talking to, for example, your browser will definitely notify you.
If you've accessed a legitimate website with a legitimate certificate, that doesn't mean your credentials won't be stolen. So, you should be careful. The green "Secure" sign in the top left corner means you're interacting with the right website. It doesn't say anything about the integrity of the website's owner.
Extended Validation certificates prove that the entity controls the website. There's an ongoing debate about whether EV (Extended Validation) certificates are useful to the typical internet user. You can recognize them by the special text on the left side of your URL bar. For example, when you browse twitter.com, you might see:
This means they use an EV (Extended Validation) certificate to prove that their company is the one behind their website.
Certificate chains
So why should your browser trust the certificate the server sends back? Any server can send a piece of digital documentation and claim it's what you want it to be.
This is where root certificates come in. Typically, certificates are chained, and the root certificate is the document your machine implicitly trusts.
For Code-maze.com it is as follows:
The lowest field is the certificate, signed by the certificate above it, and so on… until the root certificate is reached.
But who signs the root certificate?
Well, he signs it himself.
Posted: AddTrust External CA Root, Published by: AddTrust External CA Root.
Your machine and browsers maintain a list of trusted root certificates to ensure the domain you're browsing is trustworthy. If the certificate chain is broken for any reason, your site will appear untrusted on some machines.
To check the list of trusted root certificates in Windows, launch the Certificate Manager by pressing the Windows ® button + R and typing certmgr.msc. You can then find the trusted certificates in the Trusted Root Certification Authorities section. This list is used by Windows, Internet Explorer, and Chrome. Firefox, on the other hand, maintains its own list.
By exchanging certificates, the client and server can know they are talking to the right party and begin transmitting encrypted messages.
Weaknesses of HTTPS
HTTPS can provide a false sense of security if it's not properly implemented behind the scenes. There are many different ways to extract customer information, and many sites may still leak data even when using HTTPS. There are many other mechanisms besides MITM to extract sensitive information from a website.
Another potential issue is that websites can have HTTP connections even though they're running over HTTPS. This could present an opportunity for a MITM attack. This might go unnoticed when migrating websites to HTTPS.
And here's a bonus: Login forms accessed from an insecure page can potentially be compromised, even if they're loaded on a secure page. So, to prevent one website, it's best to secure the entire website.
References;
- The HTTP series: https://www.code-maze.com/http-series/
- Check if your browser supports HTTP 2.0: http://caniuse.com/#search=http2
- More about HTTP 2.0: https://bagder.gitbooks.io/http2-explained/content/en/
- Migrating your website to HTTPS: https://www.keycdn.com/blog/http-to-https/
- The TLS protocol: https://www.ietf.org/rfc/rfc2246.txt
- POODLE attack: https://en.wikipedia.org/wiki/POODLE
