Many of us put a lot of trust in websites. We do our banking online, buy things in online shops, sign in to web sites and give out personal information. But why do we trust these websites? Probably because we trust the company behind it. Using Amazon is very convenient but to use that service we need to enter a payment method, our credit card for example and an address for shipping. We trust that Amazon will treat that sensitive data consciously. And that’s fair enough, Amazon has a good reason to keep your data safe. But how can we be sure that our data arrives safely? When we send that data to Amazon, we probably don’t want anybody else to read that information on the fly. Well, that’s where the browsers green padlock comes into play. That padlock indicates an HTTPS connection, a secure connection. But how does HTTPS work? Let’s take a closer look

Chrome without green padlock for http

HTTP connection without a green padlock

Chrome with green padlock for https

HTTPS connection with a green padlock, saying ‘secure’ in German

The three promises of HTTPS

So what does this green padlock actually stand for? There are three aspects here, first it ensures data confidentiality. If we went back to the Amazon example, that would mean, you credit card info is treated confidential – meaning it is transferred encrypted. The second promise is, data authenticity. The data you are seeing, the Amazon website, comes from It is not a phishing site that just looks like Amazon, the data comes from itself. Last, but not least, it promises data integrity. No parts of the website have been maliciously modified by an attacker.

Let me show you an example of a famous sport news website, ESPN. ESPN serves its website over standard HTTP, an insecure connection that everyone can listen in on. If you are about to sign in, you will get a warning from your browser, like this one

Chrome warns for HTTP pages with Forms

Chrome saying ‘not secure’ in German

Even though you would send the sign in request over an HTTPS connection – and therefore encrypt it – you cannot be sure that the sign in page itself isn’t compromised. Since your browser cannot guarantee data integrity, it will warn you that using this sign in form is not secure.

So how does HTTPS work and keep the promises?

Here is the interesting part. Before a client, like your browser, and a web server exchange actual website content, they will perform a TLS handshake. Within that handshake the web server will prove its identity to the client. It will prove that it is the owner of and then the two parties negotiate an encryption algorithm for the future data transfer. The next question is, how does the web server prove its identity? If a client asked any web server if it was, and the web server could always respond positively, then this process wouldn’t make much sense. That is the part where we need to take a look at Certificate Authorities (CA).

Certificate Authorities

A Certificate Authority is a trustworthy third-party entity that is allowed to issue certificates. Operating systems and browsers have a list of CAs included that they will trust, like GoDaddy, Let’s Encrypt, COMODO and others. So a website owner can reach out to one of the trusted CAs and request a certificate for their domain. The CA will issue a certificate specifically to that website and that certificate will only be accepted as valid by a client, if the serving URL and the URL it has been issued to match. But that’s not all, a certificate is an encrypted document. Holder of the public keys can decrypt the certificate and check its content, that’s what browsers do. So if a website claims to have a certificate from COMODO, then the client will try to decrypt it with COMODOs public key. If that works, the browser knows, it is a valid certificate from COMODO, no one else would have been able to encrypt it correctly. Now the client can trust the certificate and the certificate owner. The green padlock appears

Different browsers could trust different Certificate Authorities, so if Google decides to trust a new CA, but Mozilla doesn’t, then in theory Chrome could display a secure connection, while Firefox displays an insecure one. Every browser vendor can manage its own list of trusted CAs.

Different types of padlocks

Knowing everything that we do now, there is still one thing itchy. I can get a valid certificate if I am actually the owner of a domain. Since I am the owner of “” I can serve it with a certificate that is issued to “”. I couldn’t serve it with a certificate for “”. However, there is no validation of who I am. I could still run a malicious website. Let me illustrate that, can you spot the difference between and The latter one is written with an uppercase i – PayPal vs. PayPaI. If I was able to register that domain and serve it via HTTPS with a green padlock, how many people do you think I could trick into entering their credentials? I think, “a few” is an understatement. So what can PayPal do, then? Register all domains that look similar to theirs? Well, that too, but take a look at this address bar.

PayPal has more than a green padlock

PayPal has more than a green padlock

It does not only say ‘secure’ it actually gives you the company behind that website – PayPal, Inc. – and the country it is registered in – US. My certificate is a Domain Validation Certificate while PayPal uses an Extended Validation Certificate. PayPal didn’t only provide evidence that they own the URL, someone also proved that the owner of the URL is a representative of the company PayPal, Inc. That adds an extra layer of trust. Even if I ran the aforementioned website with an uppercase i,, I would certainly not be able to provide the same evidence. I would never get such a certificate. PayPal really makes sure that you know who you’re interacting with. So do many banks, at least here in Germany, most major banks use this extended validation and that is good. But take a look at, and They all don’t.

How secure is HTTPS

HTTPS is not unbreakable, but it is very robust. It doesn’t prevent bad websites itself, websites can still have other risks. SQL Injection, Cross-site-scripting and countless other vulnerabilities but that is not what HTTPS is there for. It doesn’t magically fix web development flaws, but it does add a layer of security to websites. HTTPS ensures that nobody can read your traffic. It ensures that nobody modified the content on the fly and it ensures that you haven’t been unknowingly redirected to a malicious website. Those are very important aspects to know, especially if you perform sensitive transactions. As a user we should all start to pay a bit more attention to the hints our browsers give us. And as developers, we should start using HTTPS right now. The rumors about HTTPS slowing down your websites speed and the associated costs are’t true anymore. It doesn’t cost anything if you use Let’s Encrypt or services like Cloudflare. Google will give your site a better rating and it can even speed up your website with HTTP/2. There is no reason not to use it.

Let others know if you liked it