How Does Website Security Work?

Admit it, this question has kept you up at night. You know to look for the padlock icon and the green bar, but you wish you knew more about encryption. Your friends are all talking about AES, SHA-1 and Per-packet Keying, and you wish you could join in the conversation.

Yeah, right. Never gonna happen… But, you might just be curious enough now to keep reading.

Note: When I talk about website security, I’m specifically referring to HTTPS, and not any of the other various security mechanisms that web sites use.

What does website security do? There are three main reasons we use it:

• Verification – A website certificate shows the company you are communicating with. It proves that when you go to the ABC Bank website, you are communicating with “ABC Bank Limited” and not an imposter.
• Encryption – All data that goes between your device and the website is scrambled, so that no one else can read it, even if it is intercepted.
• Non-repudiation – This isn’t a term you’ll see very often, but what it means is that the data that is received is guaranteed to be the same data that is sent. For example, if I transfer $100 to a friend, an intermediary is not able to inject their own account number into that transfer and redirect that money to themselves. If someone tries, the bank’s website will detect that the transfer has been tampered with, and it won’t be valid.

So that’s why we use it, but how does it work? Website security (HTTPS) actually refers to a suite of supported security mechanisms, such as SSL and TLS. You don’t need to know about any of this however, so that will be the last you hear of it from me.

What I will do, is explain how a Public Key Infrastructure, or PKI works. PKI is the security approach used for HTTPS, regardless of the actual underlying technologies. Because data is hard to conceptualise, I will use the example of sending physical messages instead.

So when I connect to an organisation’s website, what they do is send me back their certificate, which contains their public key. Think of this certificate as a padlock. When I receive this certificate (padlock), I check it against the authority who issued (built) it, to make sure it is genuine. This is the verification part of website security.

Once verified, I can actually use the padlock to lock my message in a box. The important thing to remember, is that I can use a padlock to lock something, but only the matching key can open it (in encryption, this key is called a private key). The organisation who gave me the padlock is the only entity who has the key, so only they can unlock it.

So, the next step is that I make two new keys, with matching padlocks. One set I keep for myself, the other set I put into a (secure and unbreakable) box, which I lock with the original padlock I was given. I send the box back to the organisation. These sets of keys and padlocks are collectively referred to as session keys.

So now I have one set of session keys, and the organisation has the other. We can now both lock and unlock messages that we send each other. Because no one else has ever seen any of the keys that we’re using (because the organisation never sent its own key, just the padlock, and then the session keys were locked away in a box), no one else can open any of the boxes and read our message (so these locked boxes become the equivalent of encryption).

Non-repudiation is perhaps the hardest part of this to envision, but imagine someone is able to squeeze something into the box while it’s in transit. The way we make sure this new information isn’t just accepted as true is that when we send the box, we include in the box a photo of its contents at the time we send it. Then the receiving organisation can simply compare the photo with what’s currently in the box. If they don’t match, then we know something suspicious has occurred. In security, this is called a digital signature.

So that’s really all there is to it. Most of the other terms you hear really just refer to the strength of the box, or the strength of the padlock, or the complexity of the key, but the process itself is basically the same.

What do YOU need to be aware of?

As with most things IT, the biggest risk isn’t the system being broken, or hacked. It is more likely to be that the bad guys take advantage of the way the system is supposed to work.

The first thing to do is make sure you get the padlock icon and/or the green bar in your browser. This means that the verification part has worked. If verification fails, you get a warning, which you can still ignore! Don’t ignore a certificate error or warning unless you know what you are doing!

Secondly, double-check the web address (ie, https ://www.abcbank.com.au). A certificate is verified against the web address. This means if you are tricked to going to https ://fakeabcbank.com.au, and a certificate has been issued to “Fake ABC Bank Ltd”, you will see a green bar and a padlock even though you are going to the wrong place. This is because the certificate is verified against where you are actually going, not where you think you are going. Certificate issuers do fairly thorough identity checks on companies before they issue a certificate, but these checks are not foolproof.

So that’s more or less it. There are plenty of resources available that provide further information, but they tend to be acronym-heavy, and maybe even math-heavy, so enter at your own risk!