I noticed there's a lot of misconceptions about how HTTPS works, especially when it comes to how it affects the user and what steps are required to enable it in an app. I hope to clarify things a little bit here.
As you probably know, the internet is a dangerous place.
Not to mention the many kinds of people you can meet there, there are a few technical weaknesses in how it's built as well.
In its early days when the overall architecture behind it was designed, security wasn't the primary concern.
This leaves us with two major issues that we need to protect our users from if they access our servers via web or mobile client.
The first one is intercepting communication.
All the data that goes between the user and our servers goes through a lot of intermediate points, for example WiFis or ISPs routers. These points offer various levels of security, so they cannot really be trusted.
Any person who’s able to take over any of them will also be able to capture all the messages exchanged between the user and the server.
Unless the connection is properly encrypted, they may be able to obtain a lot of sensitive information - starting with seeing how the user interacts with our app (i.e. what pages he visits), through any sort of private information they enter into the app, ending with passwords and credit card numbers.
The other one is pretending to be someone else.
Techniques like DNS Spoofing allow attackers to redirect traffic into different servers than the users expects to access, without them even noticing.
The user will simply access a malicious website through a domain they know and expect to offer legit services. That lets the attacker to trick them into for example, revealing confidential information.
This means we need a way of verifying that the server on the other side is the one we expect to connect to.
Fortunately, both of these problems can be solved by using HTTPS protocol.
Making use of the HTTPS
There’s a commonly adopted protocol called HTTPS that provides secure communication over the Internet.
Basically it’s a standard HTTP protocol wrapped in a TLS secured connection. The use of TLS allows clients to verify server’s identity and establish an encrypted connection.
Chrome blocking access to a website due to invalid certificate
The most important thing takes place when the connection is established.
The server needs to be able to present a digital certificate signed by a third party that the client trusts (called CA).
The use of asymmetric cryptography protects from forging such certificates.
The certificate itself can be obtained for a small fee from most domain registrars. It’s also possible to get the most basic certificate from the Let’s Encrypt project by The Linux Foundation.
Picking the right type of certificate
Before requesting a certificate, we need to decide what exact type of certificate is needed.
We can distinguish certificates by two criteria:
What domains we can use the certificate with
A single certificate can be used only for certain domains. Their ownership is always verified by the CA before issuing the certificate.
Depending on the number of domains we want to secure with HTTPS, we can pick from three kinds of certificates:
single domain - This is usually the cheapest one, but will let us set it up for a single domain or subdomains. This means if we buy a certificate for acme.com, we won't be able to use it with blog.acme.com (and the other way around).
wildcard domain - This kind of certificate will work for a domain and all of its subdomains. *.acme.com will work for both acme.com, blog.acme.com or archive.blog.acme.com
multi domain - A single certificate that can work with multiple domains eg. acme.com and acmemail.com at the same time.
The multi-domain certificate is not a commonly used thing outside big corporations. A single domain or wildcard domain certificate will be just enough most of the time.
What information it gives to the users
HTTPS ensures the user that the server he’s trying to access is really the one he wants.
Additionally, the certificate can carry information about other checks done by CA when issuing the certificate. This information is usually accessible by clicking the lock icon near the address bar.
There are three levels of verification:
domain verification (DV) - that's the quickest and easiest one to verify. This level of verification requires checking if the person asking for it is also an owner of the domain. This can be done by sending verification code to an email like [email protected].
business identity verification (OV) - this kind of certificate will not only inform users that they accessed the website they wanted to, but also that the company that owns it is real. These checks are done in multiple ways e.g. by checking if the company really exists under the address they provide when requesting the certificate. The company's data will later be presented to users along with the certificate.
extended identity verification (EV) - that’s a more rigorous version of OV certificate. It comes with deeper background checks but rewards the owner with green status bar in browsers, that is supposed to make customers trust it more.
Address bar showing company name with EV certificate
Getting a certificate
Once we pick the CA and type of certificate we need, things get a bit more technical. Besides having to dig into terminal, the process is pretty straightforward.
The first step is to generate a Certificate Signing Request (CSR) file.
This file contains information the Certificate Authority needs to verify your identity and issue a certificate:
- The domain for which the certificate will be used
- Name and address of your organization
- Your contact information
- The public part of the key that will be used with this certificate
When generating a CSR, you’ll also generate a private key for use with this certificate.
Generating certificate request with OpenSSL
Then, you need to submit the CSR to the CA you’ve picked.
Notice that you’re sending only the public key along with the CSR.
Even if the signed certificate goes into the wrong hands it’s useless without the private part of the key (that you should always keep in a safe place).
Once the CA verifies your identity, you’ll receive a signed certificate file. At this point, all you have to do is to set it up (together with the private key) in your webserver.
From now on, the website will be secured.
Getting a free certificate
If all you need is the simplest certificate, with domain verification only, it’s worth it to look at the Let’s Encrypt provided by The Linux Foundation.
It’s a Certificate Authority that provides free DV certificates.
For security reasons, they are valid for only 90 days, but their tooling helps with automating renewal of these certificates.
Adoption of HTTPS
As of mid-2016, slightly less than 50% of the most popular websites use HTTPS as default.
With the growing maturity of the web this number keeps increasing.
Recently Google started to prefer sites with encrypted connection in their search results. With iOS 9, Apple started to push developers to use secured APIs for their mobile apps by disabling HTTP connections by default.
Not to mention laws requiring companies to use secure connections if they’re processing credit card data or personal information.
Even though the process of issuing certificates required for TLS to work may seem a bit complicated at first, once you know what kind of certificate you need it’s quite straightforward and thanks to services like Let’s Encrypt in most cases you can do it for free.
Adopting HTTPS protocol, even when not required by law, can be of a great value for your users, especially those who value privacy.
Did you like this?
We write about building software products, no fluff included.
Leave your email and we'll let you know when we publish a new post.