I always cringe when I hear people telling others to ‘just accept the certificate’ when their browser warns them that it is invalid, so I’m going to attempt to use a Billy Joel song and an old TV commercial asking if you’ve ‘ever hired a movie that just wasn’t quite ‘right’, to attempt to explain what browser certificate warnings actually mean and why accepting an invalid certificate could cast rather a gloom over the evening.
Setting the scene
“I was sitting by the phone, I was waiting all alone” at my desk at work one night when my phone suddenly sprang to life with a rendition of Scooby Doo greeting me with ‘hello’ and giggling, as Scooby is prone to do. This call wasn’t the result of me singing a song suggesting that someone call me, but rather the result of someone having an issue with their credit card and misunderstanding the international direct dial phone number of their financial institution.
Despite me greeting the caller with the name of the company that I was working for at the time which, I might point out was far from that of any financial institution, she started to explain that she was having a problem with her credit card. Thoughts as to what made her think that she should call a systems/network engineer at an I.T. company soon gave way and allowed my mind to attempt to fathom out how this could have happened.
Granted, there could have been someone spreading ‘for a good time fixing your credit card problems call …’ graffiti around, but when I asked her to tell me the phone number of her financial institution, I noticed that the first eight digits of the international direct dial number just happened to be a valid local number — that of a direct line to my desk extension.
Now that phone call could have had some pretty serious consequences for that caller, as instead of pointing out the mistake that she had made, I could have pretended to be someone at the financial institution and, of course, wanting to protect her account and make sure that she was whom she said that she was, asked her for personal details, and of course I’d need her credit card details in order to fix the problem with her card. While I have a conscience that would never let me do anything like that, a number of people don’t.
In this situation, it is pretty easy to see the problem — she couldn’t be completely sure that the person on the other end of the phone, being myself, was actually the person whom she thought they were, nor if they actually worked for her financial institution (although in the case of the latter, the fact that I identified the company that she had actually called as being nothing like a financial institution should have been a bit of a clue).
This is the reason that financial institutions, and a lot of other service providers, ask you numerous questions when you call them — they need to be sure that you are whom you say you are. The problem is, they don’t give you the opportunity to satisfy yourself that they are actually whom they say they are. Not only that, but they often get offended if you attempt to do so.
There is a good rule of thumb that helps in the latter case, and that is the rule that you should never give out personal details if you did not make the call. That is, don’t give out personal details to anyone who calls you.
That, however, wouldn’t have worked in this case as this caller did actually call me and, apart from my greeting, didn’t have any reason to suspect that she had called anyone other than her financial institution (as she believed that she had called the correct number).
Now, let’s get digital, digital (sorry — I’d claim that someone slipped something in to my lunch if it wasn’t for the fact that I made it myself). Let’s tie this story with Peter Steiner’s 1993 (ah, that takes me back) cartoon published in The New Yorker: ‘On the Internet, nobody knows you’re a dog‘, and ask how this matter of trust works (or doesn’t work) when instead of calling your financial institution, you connect to their web site.
First though, I’m going to beat around the bush a bit by introducing some concepts and asking some questions that I already know the answer to.
The Man, or Woman, in the Middle Attack
This is similar to the ‘Flowers By Irene’ van in one of the episodes of The Simpsons and is pretty much what its name suggests — a man/woman in the middle of a conversation. A bit like the annoying person who won’t leave you alone at parties, only unlike the annoying person at parties, this person is actually interested in your conversation.
Basically, a man-in-the-middle (as they are most often called) attack is where a third party intercepts and forwards a network connection between two, usually unsuspecting, computers/hosts/devices/applications. This is very similar to a phone tap.
MitM (as the name is often abbreviated to) attacks are a problem because they enable the man/woman in the middle to see all data between the two end points, whether this data be your social media update about what you’re having for lunch, a blog post about what you thought about lunch, or an Internet banking session to transfer money so that you can avoid paying minimum balance bank fees after having withdrawn cash to pay for lunch.
In the case of Internet banking sessions, it may (more than likely) be possible for the man/woman in the middle to extract your user name, password, account numbers, bank balances, transaction information, and any other information that traverses that network connection.
The correct web page showed up, so I must be connected to the correct server?
Not necessarily. I used a key word in my description of a man-in-the-middle attack — forwards. The attacker will simply pass everything that you send, on to the real server — usually after reading/saving/publishing it on the Internet. Likewise, the attacker will send anything that the server sends back, on to you — again, usually after doing whatever they want to do to it including, in some cases, modifying it.
Is encryption the answer?
Short answer: No.
Long answer: Encryption, when used to protect data being sent between two parties, only protects the data from being read by a third party, whether it be an attacker, eavesdropper, or someone who happened to come across your data on the leg of a pigeon whilst walking their dog.
To illustrate, imagine two kids in school, who don’t want to be named out of fear of embarrassment so I’m going to continue the pseudo-tradition used in I.T. security examples by calling them Alice and Bob.
Alice and Bob are sitting in a school English class when Alice gets bored of listening to the teacher explaining the difference between your and you’re and between their, they’re, and there, and instead decides that she’d rather arrange another date with Bob. Alice and Bob have been a bit of an item for a while now, but they never told her daddy what their love was all about, and she doesn’t want to risk him finding out as a result of a fellow classmate posting it on her social media page.
So Alice decides to encrypt her note to Bob, but she runs in to the classic problem with symmetric cryptography (which is a method of encrypting messages such that the same key, or information, is used to both encrypt and decrypt the message) — how to get the key (information necessary to decrypt the message) to Bob, along with the message, in such a way that the key can’t be used by anyone other than Bob to decrypt the message.
A common strategy is to send the message and the key via different communication channels. For instance, Alice could have sent the key to Bob via an SMS, and then sent the message via a note passed by classmates. However, if that were possible, not only could Alice have sent the entire message by SMS, unencrypted, but it would also ruin my elaborately thought out analogy.
You may have heard of asymmetric cryptography, or public/private key cryptography. This is a method devised in order to overcome this problem, and I once watched a documentary which used a really good analogy in order to explain it — an analogy which I’m about to reuse in a more dramatised and long-winded fashion, so it’s back to the adventures of Alice and Bob.
Now, while Alice and Bob may not have been paying attention during their English class, they had recently seen a documentary on cryptography which used a simple analogy to explain how public key cryptography works to get around the problem of having to exchange encryption keys/passwords. Alice sent Bob a note which, since they sit a few rows apart, needed to be passed via a couple of intermediary classmates. Alice’s note simply read:
Send a padlock
Bob sent back a padlock, again via intermediary classmates. Alice placed her plain-text (that is, unencrypted) note in to a small metal box which she then proceeded to lock using Bob’s padlock. She passed the locked box to a classmate and asked for it to be forwarded on to Bob. Bob, upon receiving the locked box, simply unlocked the padlock using the corresponding key (which he had kept), and read Alice’s note.
The beauty of this approach, and that of public key cryptography, is the fact that the recipient merely provides a means of encrypting the message such that only they can read it. The key is kept private by the recipient (hence the private key part) and the padlock (a means of protecting/encrypting the message), corresponding to the public key, is sent to anyone wishing to protect (encrypt) a message to the recipient.
It doesn’t matter who sees or has access to the padlock (the public key), because once it is locked, it can only be opened (ok, ignoring methods like lock picking, which would be the equivalent of trying to break the encryption) by using the corresponding key (private key).
Now I suspect that about this time, you’re starting to wonder what all of this has to do with man-in-the-middle attacks and web site certificates, and that you’re rapidly approaching the opinion that I’ve gone off on a raving tangent, but before you do, consider the next scenario.
Suppose that one of the classmates responsible for routing this exchange of goodies between Alice and Bob was desperate to humiliate them by exposing some dark secret of theirs on their social media site. The classmate wanted to know what message Alice was sending to Bob. Again, sticking to pseudo-tradition, I’ll call this intermediate classmate, Chloe.
Chloe, being one of the intermediary classmates, sees Alice’s message to Bob requesting a padlock. She also gets handed Bob’s padlock on it’s way from Bob to Alice. Now Chloe knows that if she passes Bob’s padlock on to Alice, then apart from using brute force and basically making it obvious that she has tampered with the box and hence possibly read the message, she won’t be able to unlock the padlock and read the message. How can Chloe make sure that she can read the message?
Suppose that Chloe, instead of sending Bob’s padlock on to Alice, holds on to Bob’s padlock and sends one of her own padlocks to Alice. Alice doesn’t have any way of knowing that she is about to lock the message up using Chloe’s padlock instead of Bob’s. Now when the locked message makes its way back to Chloe, on its way to Bob, Chloe can use her key to unlock the box containing the message, read the message, put the message back in the box, lock the box using Bob’s padlock, and forward the box on to Bob.
Bingo! Chloe has managed to read the message with neither Alice nor Bob able to detect the fact — Bob doesn’t know that his padlock was kept by Chloe and not passed on to Alice, and Alice doesn’t know that she received Chloe’s padlock instead of Bob’s.
How do we get around this dilemma? We introduce a trusted third party, say the teacher in this case. Bob could get his padlock engraved with a message that uniquely identifies his padlock, like a serial number. He could then take his padlock, together with some proof that he owns the padlock, to the teacher and ask the teacher to sign a note saying that the padlock engraved with that serial number does indeed belong to Bob.
Alice, before accepting a padlock that has been passed by an intermediary classmate, could ask to see a teacher-signed note stating that the padlock which she has been given actually belongs to Bob. If this note can’t be produced, or the serial number on the padlock doesn’t match that mentioned in the note, then Alice can suspect that the padlock that she has been given isn’t actually Bob’s padlock, and that someone has switched padlocks on her.
That could work but, I hear you muse, that is all very good for two classmates who aren’t interested in paying attention in English class, but how could you do something like that on the Internet to protect messages between web sites and web browsers?
Introducing the digital certificate
A digital certificate is pretty much a digital version of the teacher-signed note that Bob used to help other classmates determine whether or not the padlock that they had been given did in fact belong to Bob. That is, it ties a public key (the encryption equivalent of the padlock in the story) to an identity (Bob, in the story), and, here’s the important bit, it is digitally signed by a third party (the teacher in the story) that is trusted by both the sender and the recipient of the message(s) (Bob and Alice in the story).
Think about that for a moment, while I potter about for a bit and think about what I’m going to say next.
By signing a digital certificate, the third party is stating that they are vouching that the certificate belongs to the person, organisation, web site, or whomever/whatever, that it claims to belong to. As a result of this, and proper key management on the part of the certificate owner, messages encrypted with the public key stored inside the certificate can only be decrypted by the owner of the certificate.
To see why it is important that the third party signing the certificate be trusted by both the sender and the recipient of the message, imagine that Chloe wants to defeat this protection and lead Alice to believe that Chloe’s padlock is in fact Bob’s. Chloe creates a note stating that her padlock (identified by a unique serial number) belongs to Bob. Chloe needs someone to sign this note, as without a signature from a third party it is nothing more than a note saying ‘this is Bob’s padlock, and you can trust me’.
The teacher, if he/she values their reputation, isn’t going to sign a note from Chloe saying that her padlock belongs to Bob, so Chloe colludes with one of her friends by offering her friend lunch if she signs the note saying that Chloe’s padlock is actually Bob’s. Her friend, being hungry, agrees and Chloe passes this note, along with her own padlock, on to Alice.
Now the scene is set. Alice will lock the secret message in a box, lock it with Chloe’s padlock under the belief that it is Bob’s, after all, the signed note that she received said that it was, and pass the box back. Chloe will receive the box in transit to Bob, unlock it with her key, read the message, put it back in the box, lock the box with Bob’s padlock, and pass the box on to be forwarded to Bob. Smashing.
Bob has no reason to suspect that anything is wrong, as he gave out his padlock and received a message from Alice in a box locked with his padlock. Alice has no reason to suspect that anything is wrong, as long as she trusts that the padlock that she was given was in fact Bob’s padlock. This is why the third party that signs the note has to be trusted by the receiver — the note is the only thing that Alice has, that ties Bob’s padlock to Bob and she needs to be confident that someone like Chloe hasn’t forged it in order to pass off their own padlock as belonging to Bob. That’s the question though, how does Alice know whether she can trust the signed note?
Introducing the certificate authority
Back in the Internet world with the World Wide Web where there are web servers, web browsers, and every man and his dog, how do we enable Internet banking and other transactions to occur with a reasonably high level of trust that the web site that your browser has connected to really is your bank’s web site, and that the information that you and it are exchanging can only be read by the two of you? Cue the certificate authority.
A certificate authority (or CA for short) plays the role of the teacher in the above story. It don’t check everyone’s English, but rather verifies (or it should do) and certifies that a particular certificate belongs to the person/identity/server that it claims to belong to. Once it is satisfied that it does, it digitally signs the certificate with its own (or rather with the private key corresponding to the public key stored in its own) certificate.
How does that help you and your browser? Most browsers come with the certificates of a number of known certificate authorities and, as a result, they will trust any certificate that is signed with one of those CA certificates (signing requires access to the private key which only the owner of the certificate (should) have access to). This trust is generally indicated by a closed padlock somewhere (that can’t be modified by a web page/script) in your browser window.
So what does the browser certificate warning actually mean?
When a web browser warns you that a certificate is invalid, or that it can’t be trusted, it is warning you that there is something wrong with the certificate. It is usually one of three things:
- The certificate has expired
- The certificate was issued for a different server to that which is presenting it
- The certificate wasn’t signed with a trusted certificate
Expired Certificates
When certificates are issued, they are given two dates. One which states the earliest time that a certificate is valid, and the other stating a time after which the certificate is no longer valid — an expiration time.
Certificate expiration times prevent a certificate from being used after a certain time, and serve a similar purpose to the expiration time of passwords. That is, if someone manages to get hold of the private key belonging to a certificate — a key which should, as it’s name suggests, be kept private to the certificate owner — then they can sign and encrypt messages as the certificate owner.
That scenario would be the equivalent of Chloe forging a copy of the teachers signature on the note claiming that Chloe’s padlock is in fact Bob’s. Alice would see Chloe’s padlock, and the note that looked like it was signed by the teacher, and have no reason to doubt that Chloe’s padlock wasn’t Bob’s.
An expiration time on a certificate will prevent a compromised key from being used indefinitely, and would be the equivalent of the teacher’s note saying something along the lines of ‘I vouch that, up until the 26th May 2014, the padlock with serial number 1235, belongs to Bob.’. It also serves to make certificate authorities more money because after a certificate has expired, the owner needs to present a new one (preferably with new public/private keys associated with it) to a certificate authority, go through their verification process again, and if the CA is happy that the certificate belongs to the person presenting it, (usually) pay to get them to sign it.
Certificates issued for a different server
This usually happens when a certificate is issued to a server, such as ‘www.malwaremusings.com’ but the server identifies itself using its real name, like ‘dangermouse.malwaremusings.com’ (good grief) rather than its ‘www’ alias.
This scenario is the equivalent of the teacher-signed note saying that the padlock belongs to Rory yet you thought that it came from Bob (and in fact it could have, but you can’t tell for certain).
The browser is warning you because it could be that the certificate (and private key, otherwise the cryptography wouldn’t work) has been stolen and the certificate is now being used to pass a fake/man-in-the-middle site off as the real web site. It is often a mis-configuration on behalf of the server administrator, but what your web browser is telling you is that you can’t be certain that things are ok.
Certificates not signed with a trusted certificate
This is the big one. This is your web browser telling you that it doesn’t trust the certificate authority (if indeed it was a certificate authority) that signed the server’s certificate, and it is the equivalent of Alice not trusting the note because it was signed by someone whom she didn’t know or didn’t trust to tell the truth about the ownership of the padlock.
It is like a dodgy sales person trying to convince you that they are legitimate by getting their equally dodgy friend to vouch for them — yes, they’ve got someone to vouch for them, but like the sales person, you don’t know them from a bar of soap either.
The certificate details are correct, so it’s okay right?
This depends on whether or not the certificate is signed by a trusted authority, and the signature is correct. If the browser warns you about the certificate, then you can’t trust any of the details in the certificate.
This situation is just like Chloe’s note saying that the padlock belongs to Bob. Just like Chloe can write anything on the note and possibly convince someone to sign it, anyone can create a certificate claiming to be that of any server they like.
In fact there is software available which performs a man-in-the-middle attack by connecting to the server, taking the certificate which the server presents to it, copying the details from the server’s certificate, creating a certificate with the same details, and passing this copy to the browser. The only difference between the legitimate certificate from the server and the falsely created one, is the public key and the signature information.
The public key will be different because the man-in-the-middle software has to use the public key corresponding to its own private key, otherwise it won’t be able to decrypt the data. The signature information will be different because the public key is different and also because the false certificate won’t be signed by a trusted certificate authority.
This is the equivalent of Chloe putting Bob’s name and address, or other details of Bob’s, on her note in order to make it look like the note really did come from Bob.
The only suspicious thing about the note that Chloe gives to Alice is that it wouldn’t (or shouldn’t) have been signed by the teacher, or a trusted source, because Chloe is using it to falsely claim to be someone else.
Now, a number of organisations will use what is called a self-signed certificate. This is a certificate that was signed with itself and is basically the equivalent of me writing a note and signing it, then adding a message to it saying that yes I can vouch for the person who signed that note, and signing that message too.
It seems stupid doesn’t it, but a certificate has to be signed using a certificate (in fact, a certificate is merely a certificate request signed by a certificate), and the purpose for which the certificate is being used doesn’t always warrant paying the (often large) costs charged by the trusted certificate authorities.
Some examples of this include internal intranet servers which aren’t visited by members of the public — you can place some level of trust in the servers because they are on your internal network, although you should still verify that the certificate is correct (because a co-worker, intruder, or malicious software could be pretending to be your intranet server in order to steal your username/password/other details).
So what’s the moral of this rather long, but hopefully mildly amusing, blog post?
People have put a lot of thought (some more so than others) in to security on the Internet. Part of this has resulted in methods of checking that connections between web browsers and web servers are in fact secure. That is, checking that your browser is connecting to the web site that you think it is connecting to, and that there isn’t anyone/anything intercepting/eavesdropping on that connection.
When your browser gives you a certificate warning, it is doing so for a reason. It is saying that it, and hence you, can’t trust the certificate that the server presented. This means that you have no way of knowing that you are connecting directly to the web server that you think you are connecting to, and that someone isn’t listening in on your connection. No way that is unless you happen to know the fingerprint of the certificate that is sitting on the server.
A certificate’s fingerprint will change whenever any part of the certificate, including the public key or signing certificate, are changed. Hence only two identical, and identically signed, certificates will have the same fingerprint.
Do I need a CA signed certificate?
If you want people to be able to trust that they are connecting directly to your web site, then yes. Apart from providing them with the fingerprint information, obtaining a CA signed certificate is the only way that you can do that.
This is important, so I’ll say it again slightly differently — a public Internet facing web site that doesn’t have a CA signed certificate, apart from looking unprofessional, prevents web browsers from being able to determine that they are in fact connecting directly to that web site, and that the connection hasn’t been intercepted and forwarded by someone else, and that they aren’t connecting to a server that is pretending to be your server.
What if I don’t want to pay for a CA signed certificate?
Using a self-signed certificate for your internal network is ok, but if you are going to do this, then I suggest that you add the self-signed certificates to the web browsers on your internal systems, as trusted certificates. That way, all your internal web browsers will automatically trust any server presenting one of those certificates.
If you have a number of internal servers, then this method is going to get somewhat annoying. In that case, you should create your own internal certificate authority (there is some free software that will allow you to do that, and I believe Microsoft also offers some), and use that certificate authority’s certificate to sign all your server certificates. You then only need to add your internal CA’s certificate to your internal web browsers as a trusted certificate.
The key (pardon the pun) message(s)
Browser certificate warnings should be taken seriously, and not merely dismissed as a nuisance/mis-configuration. They are telling you that the browser, and hence you, can not be sure that the web site to which you are connecting is indeed the web site that you think that you are connecting to, nor that the web site is the site that it claims to be.
If this is just a web site which you are reading non-confidential information from (I’ve noticed some web sites do this), then it is ok to continue. However, under no circumstances should you submit any personal/confidential/credit card information to a web site that has generated a certificate warning, as you cannot be sure that the information isn’t being read by a third party.
If you are going to accept a bad certificate and continue, then ask your browser to permanently store the certificate (Firefox will do this, but I don’t think Internet Explorer will). Why would you want to permanently store a bad certificate? So that you can notice if it changes.
If you ask the browser to store the bad certificate, then it will remember the certificate and not issue a warning when that web site presents the same certificate next time. However, if a man-in-the-middle attack is taking place, or someone manages to get your browser to connect to a rogue copy of the real web site, then the browser will present you with another certificate warning because the certificate presented by the attacker/rogue site won’t exactly match the certificate that the browser stored.
If you work for an I.T. help desk, then please, please, please, don’t tell your users to just click ‘OK’ on certificate warnings. At least not without explaining what they mean and what the consequences may be.
Even if it is an internal server with a signed certificate and you have checked that the fingerprint is correct (and hence you know that it is the certificate that is stored on the server and not a fake one), just telling users to click on ‘OK’ and accept the (possibly fake) certificate may induce complacency and then they may accept an actual bad certificate on the basis that last time they saw that warning, an I.T. person told them that it was ok to click on ‘OK’ and continue.
The End (almost)
My apologies for the long post, but I was trying to simplify and explain what I believe to be a rather important issue when it comes to Internet safety, and something which I think a lot of people either misunderstand, or don’t care enough about. It is very similar to connecting to servers whose ssh server keys can’t be verified, but I’ll save that for a different bed time story.
A Dedication
I’d like to dedicate this post to the memory of Rory — a dog whom I could generally trust to heel and stay when told to, and to come when called… except when it came to competition day for the obedience classes. I don’t know how many times we repeated the Novice class together, but it was fun and I must admit, our perpetual failing was starting to get amusing. Unfortunately, Rory died on the 26th May 2003. Here’s to all the long walks and fun we had together — may you rest in peace.