What makes up HTTPS
SSL/TLS (the S in HTTPS provide three security features, one well, one badly, one rarely.
- SSL creates a secure communication channel between the client and the server. Here, secure means that only the server and the client who cooperated to establish the channel can know the data that has been transfered¹ or modify that data. The security of the channel is ensured by cryptography which I won't go into here².
This part works pretty well in practice. Early versions of the protocol had bugs, and implementations occasionally get something wrong, but for the most part, you can consider that if an SSL session has been established then you'll be talking securely to the server you contacted. In practice, most attacks at this level aim to trick the user into believing that some data was transfered with HTTPS when it was in fact transfered over HTTP and eavesdropped, faked or tampered with.
This isn't to say attacks at this level are impossible — just days after I wrote the above paragraph, an attack on this part of SSL was disclosed.
- SSL enables server authentication, meaning that the client can verify the identity of the server. The way this works is that the server has a key pair, and it sends³ the client its public key together with a proof that it knows the private key. In order to verify that the server is who it claims to be, the client must make sure that the claimed public key does belong to the server that the client is attempting to contact. This is where things get complicated.
The SSL works is that the server sends not only its public key to the client, but also a signed certificate. A certificate says “I am Charlie, and I vouch that acme.com's public key is 0xDEADBEEF” (with cryptography², so you know Charlie really did say this). So if the client was trying to visit
https://acme.com, it knows that it has reached the right server.
Wait, you ask: why does the client trust Charlie? Normally, Charlie is a certificate authority (CA), and the client has a list of certificate authorities that it trusts. All browsers come with such a list⁴. If the server sends a certificate where Charlie vouches that the server is
acme.com, and Charlie is one of the certificate authorities that the client trusts, then the client can be confident that the server is
- Symmetrically, the protocols allows for client authentication. This is not used often.
Note that point #1 alone cannot ensure that the client is talking to the server it wants to talk to, and the parties cannot ensure confidentiality even if they do appear to be talking to each other. Unless the parties authenticate each other, it's possible for a man-in-the-middle to pretend to the client that they're the server, pretend to the server that they're the client, relay the data back and forth, eavesdropping the traffic and optionally modifying it on the fly.
Point #2 is where things can go wrong, and when things go wrong, you get an SSL warning message. Here are some common reasons (this is by no means an exhaustive list).
- The certificate is for
acme.com, but the client had contacted
- The certificate is issued by Dominique, which is not in the client's list of trusted CAs.
- The certificate is intrinsically invalid in some way, for example it has expired⁵.
Why do things go wrong so often? Whole essays have been written on this issue, but in a nutshell, it's because this is a complex protocol involving at least four participants, none of whom have much control over any of the others:
- the server (who previously obtained a certificate from the CA and is now trying to communicate with the client);
- the client (who obtained her browser from some place and is now trying to contact the server);
- the certificate authority (who issued a certificate to the server and got browser makers to include it in their trusted list);
- the browser makers (who decided on a list of trusted CAs, and provided the browser to the client).
Obtaining a valid certificate is a relatively heavy and costly process, compared with setting up a simple website. So many small sites don't go through a CA and generate their own certificates. A self-signed certificate (i.e. Charlie is the server) doesn't provide any information as to who the server is.
Obtaining a valid certificate is not a big deal compared with setting up a complex or high-traffic website, but complex websites have challenges of their own, so that's more potential for things to go wrong — for example, a subdivision of a large organisation is unable to obtain a proper certificate due to internal bureaucracy issues, or a server is renamed and the system administrator forgets to obtain a certificate for the new name.
SSL warnings in common situations
When you see an SSL warning, you need to evaluate the nature of the warning, the contents of the certificate, and your relationship with the server. It's impossible to cover every case, but here are a few common ones.
You have no prior relation with the site
If the site is some random site you hadn't heard of before, it doesn't matter much whether it has a valid certificate. An expired, self-signed or misconfigured certificate is not a cause for worry. For example, if the certificate is for
www.acme.com and you're connecting to
www1.acme.com, it's likely that the server is misconfigured. It could also be an attack on the server, or on your DNS, but that's comparatively rare, and ultimately, if this is just some random server, you don't know whether to trust it even if it has a valid certificate. Remember that a certificate authority says “I have checked that this public key belongs to Alice”. It doesn't say “Alice is trustworthy”.
One thing a valid certificate does tell you is the real identity behind a website. For example, if you're ordering something on a web merchant's site, the certificate ties the site with a legal entity that you can sue. At least, that's the theory — in practice, most CAs don't do much to verify the real identity of their customers (it's a dodgy relationship to begin with: the CA is supposed to vouch for the entity that pays it). And CA's security can go wrong.
You have visited the site before, and it used to have a valid certificate
If a site used to have a valid certificate and no longer does, it's generally a sign that something has gone seriously wrong. Either someone is attacking your connection, or someone has attacked the server, or there's a misconfiguration on the server. If the certificate is merely expired, it's most probably a misconfiguration. On the other hand, if the site is now showing a different certificate signed by an unknown entity, or bearing the name of an unknown entity, you shouldn't put any trust in the website. That doesn't mean that you shouldn't browse it at all, merely that you had better not trust that site with confidential information. This advice is especially important for sites such as banks that are often targeted.
Do keep in mind that HTTPS ensures only two things: a secure end-to-end communication, and (if used properly) authentication of the server. HTTPS does not do anything for the security of the server itself. If an HTTPS server has been cracked, it may send your credit card information to the crackers and serve you virus-laden pages — all with the same old, perfectly valid certificate.
You have prior knowledge of the site but haven't visited it before
This is mostly like the previous case — an expired certificate is little cause for worry, and an otherwise invalid certificate is. But there is an additional case to consider: the case of a self-signed certificate, or a certificate signed by a CA that's not trusted by your browser.
In that case, you need to decide whether you want to establish a trust relationship with the server. If you decide to accept the certificate, you won't know who you're talking to; but the next time you talk to that same server, you'll know that you're returning to that now known server.
At this point, you may be able to verify the certificate by another channel. For example, if you're connecting to your employer's website on your laptop, you might be able to make the first connection from within your workplace, on a trusted network, so you'll know that the certificate is right without needing a signature on it. So let your browser enter the certificate in its list of trusted certificates⁶; when you next visit the site, you'll know that you've hit the right site, regardless of the validity of the certificate's signature.
Barring side channels such as packet length or timing that can reveal , but that's not a practical concern in most uses of HTTPS. If it is a concern for you, you probably know all I've said in this answer far better than me.
Here I'll treat cryptography as a science so advanced that it's indistinguishable from magic. Magic that work, that is.
I use the word “send” in a loose sense, this takes an exchange of several messages, but that's unimportant here.
For example, in Firefox, you can see the list of trusted certificate authorities in the “Advanced” tab of the preferences dialog, by clicking on the “View Certificates” button and selecting the “Authorities” tab.
SSL certificates have expiry dates, to slightly reduce the impact if a server's private key gets stolen.
For example, in Firefox, you can see the list of trusted certificates in the “Advanced” tab of the preferences dialog, by clicking on the “View Certificates” button and selecting the “Servers” tab.