SSL certificates help form the backbone of security and trust on the modern web.

SSL stands for Secure Sockets Layer, a technology that has since been replaced by TLS (Transport Layer Security), however the terms are widely used interchangeably. These digital certificates are what underpin HTTPS, or the secure version of the original HyperText Transfer Protocol, which defines how browsers and web servers communicate with one another.

They're used by banks, ecommerce merchants, social networking sites and more to strive towards a more secure online experience, but how exactly do they work? That's what we're going to cover in this blog post.

What's the benefit?

On a high level, SSL/TLS does the following things:

• It ensures that the server you're connecting to is who they say they are and that your connection hasn't been hijacked and redirected to somewhere else.
• It ensures the connection is private. The certificates themselves are used as part of the process of encrypting and decrypting all of the data sent between your browser and the server, preventing eavesdroppers from stealing passwords, credit card numbers and other information you'd rather keep private.
• It helps ensure the connection is reliable, as there's a built-in integrity check to prevent undetected data loss or corruption during transmission.

If it looks like a Duck(Duck Go), Quacks like...

On the surface, this might seem a little silly. You may be thinking "Well, if I type in duckduckgo.com in my address bar, and the page looks like Duck Duck Go, it must be Duck Duck Go"

We see your point, but it's not quite true. The increased sophistication that modern bad-actors are resorting to is becoming more impressive by the day. In fact, one of our experts was sent a link to what purported to be the customer account panel of a well-known UK based mobile network and the only word we could use to describe it was "flawless" - the only giveaway was its URL.

That's the level we're working at. Without HTTPS, all it'd take is for someone to pull quite a trivial man in the middle attack whilst you're sitting browsing the web in your favourite coffee shop, and it's game over.

So how does a digital certificate help solve this problem?

When your browser tries to connect to a server over HTTPS, they perform what's called a TLS handshake. If any data is modified in transit, or the certificate fails validation, the browser will show an error page.

If the handshake is successful, the browser will have validated that the server is who they say they are, and they will be able to communicate securely (more on that later).

If you're browsing the web at work, on public Wi-Fi or somewhere where you may think that someone's collecting all of your internet data, browsing sites secured in this way encrypts everything except the top-level domain name. The rest of the URL, the cookies, form submissions and all other page data is encrypted using a key shared only between the destination server and your browser; Any other data collected by a third party will be completely unreadable*.

Public Key Cryptography

Also referred to as Asymmetric Cryptography, Public Key Cryptography allows for authentication checks, encrypted communication and digital signatures.

Certificates have both a Public and Private key. These are two very long numbers that are mathematically related to one another:

• The public key is the value that anyone can access if they want to. In fact, if you click the padlock icon in the address bar of your browser, you can look at the public key of the certificate that is used to secure this site.

• The private key is the value that must be kept private, otherwise the entire system of trust fails.

Private keys are stored away from users (and even most administrators), so they don't accidentally end up in the wrong hands, and they're always completely inaccessible directly over the web.

In short, it means that a message encrypted with one of the keys can only be decrypted with the other. This technology is widely used by investigative journalists for sending and receiving encrypted email, within SSH for secure, password-less user authentication, digital signatures and non-repudiation systems.

Asymmetric encryption isn't how we encrypt HTTP traffic, however. If it were, whilst any data sent to the server would be secure (as no one else has the private key), any data returned could be trivially decrypted by someone listening in, as the public key is available to everyone.

Another downside of asymmetric encryption is that it isn't very fast, primarily because the keys are far longer than are used in symmetric encryption (which uses the same key for both encryption and decryption).

To solve this problem, we use symmetric encryption with a key that is negotiated between the browser and server using a Diffie-Hellman Key Exchange. Whilst we're not going to go into a deep-dive of Diffie-Hellman in this article, in short it allows for two people to securely negotiate an encryption key whilst communicating in public.

To prevent the Diffie-Hellman key exchange from being hijacked by a man in the middle attack, we make use of asymmetric encryption as part of the key negotiation, forming a hybrid cryptosystem. The browser can encrypt any data it sends to the server using the server's public key, and the server can include a digital signature along with the key exchange data it sends to the browser. This digital signature is made up from summary of the payload data, encrypted with the server's private key. The digital signature is decrypted using the server's public key and compared with the summary of the plain-text data received. If the decryption succeeds (matches the data the browser is expecting), the response must've been sent by the server as (theoretically) only they have the private key which corresponds to the public key the browser is using.

How does my browser know which certificates to trust?

Taking the certificate of this site for instance, you'll be able to see that there is our certificate, which is signed by the Let's Encrypt Authority X3 (an intermediate certificate) which is itself signed by the DST Root CA X3. This is the chain of trust, and is fundamentally the way that browsers and operating systems validate certificates they're presented with.

The certificate at the top of this chain is the root certificate, which is a self-signed certificate that's pre-installed on your device. All of the major operating system vendors include a bunch of root certificates that are to be trusted by devices they're installed on.

When the browser receives the server's certificate during the TLS handshake, it validates every certificate in the chain all the way up to the root certificate ensuring the domain name, dates and signatures are all valid and that none of the certificates have been revoked.

If any of this validation fails, your browser will display a warning, saying the site is potentially unsafe to visit.

The Future of SSL, TLS and HTTPS

It's certainly safe to say that Digital Certificates aren't going anywhere, and with projects such as Let's Encrypt, more people have access to them than ever before.

Whilst we've glossed over a massive amount of the technical detail here, the industry is ever advancing and improving privacy and security for everyone.

In fact, dependant upon your chosen browser, you're more than likely already seeing the effects of a large change in the industry. Google Chrome for instance now blocks mixed content (where the site is loaded over a secure connection, but has insecure elements on it) by default and shows a warning in the address bar if you visit a site that isn't secure.

When you also consider that search engines are now using the presence (or lack thereof) as a factor in their ranking algorithms, favouring HTTPS over HTTP is an absolute no-brainer, and we recommend automatically redirecting visitors from insecure HTTP to HTTPS by default. Pretty much every web hosting company offer HTTPS and the associated certificates as an option, though some (including Stratagem) offer free of charge certificates through Let's Encrypt.
This significantly lowers the cost of having an online presence, as in many cases having an SSL Certificate is a mandatory requirement if you're running an ecommerce store, a platform that stores personal information that visitors log in to, or simply want to help protect the privacy of your visitors.

But that YouTuber told me about -insert VPN provider here-

Ah, the videos that suggest if you're not using a VPN you might as well shout your passwords out in the middle of the coffee shop? We've seen those videos too and whilst you're probably waiting for us to call out a specific VPN provider, we're going to refrain.

What we will say is that security works in layers, and (in theory) the more you have the better protected you are. However, to suggest that someone in that coffee shop you're sat in can steal your internet banking login details if you're not using a VPN is absolute nonsense, provided of course that said site is served over a secure connection.

Intercepting HTTPS traffic

*The eagle eyed amongst you may have noticed the asterisk at the end of where we spoke about collected data being unreadable. We may do a more in-depth post about this in the future, but for now here's a quick run-down of an exception to this rule.

We spoke about root certificates earlier. As standard, these come loaded with the Operating System that your device is running, be it Windows, MacOS, Linux, iOS, Android, etc. We recommend that you do not install custom root certificates, as doing so can have major security and privacy implications.

That said, in large corporate networks, it's not uncommon for your PC's OS to be installed by a centrally managed IT department, where they'll also install all the various tools, apps and such that you'll need to do your every day tasks. Along with this, a custom root certificate can also be installed.

These certificates can be used to enable wide-scale web monitoring that would not only allow network administrators to see what domains you visited (which they'd be able to anyway), but also intercept the full URLs and any data passed back and forth between your browser and the destination server.

So how does this work?

Let's use Twitter as an example, and we'll call the person browsing the site Alice and the person intercepting the communication Eve.

Eve would start a man in the middle attack between Alice and the local internet router, intercepting all requests and data going back and forth. Alice would send a request for Twitter.com, and Eve would essentially pretend to be Twitter, substituting the certificate provided by them with one they've created and signed with the custom root certificate.

Because the certificate Eve has provided is trusted by Alice's machine (courtesy of the custom root certificate it's been signed by), Alice would be none the wiser that the session was no longer end-to-end encrypted, unless they checked the certificate details and chain of trust manually.

Let's now say that Bob comes along whose machine doesn't have this custom root certificate on it (and is therefore not compromised), and Eve tries to pull the same trick, Bob's browser would abandon the connection attempt because the certificate Eve supplied wouldn't be trusted.

If this sounds like some far-fetched conspiracy theory (and we understand that it might), the Superfish malware was a piece of software included on many laptops a few years back that used a similar technique locally to insert ads into web pages accessed over HTTPS.

Wrap Up

We hope this has given a little more insight into security on the modern web. As always, if you have any questions or if we can help you in any way, get in touch!