when is it safe to click through an SSL warning message?

Question

How does a user know if it's safe to click through scary browser warnings about SSL certificates?

Ideally, a user should never need to click through these warning messages, but sometimes honest websites run by honest, but not clueful, people will have a broken certificate.

Answer 1

SSL serves three purposes (I'll use a snail-mail analogy to illustrate):

1. Keep the communication secret: prevent the mailman from reading your letters.
2. Verify that the communication is unaltered: prevent the mailman from altering your letters.
3. Verify the identity of the sender: prevent someone else from sending you letters under a false name.

Note that points 1 and 2 are worthless unless 3 is intact: if someone else can impersonate the originator of a message, then encrypting it does nothing but prevent yet another attacker from hacking your already-compromised communication. If you click through an unverified or untrusted certificate, this is what you are risking - the communication will still be encrypted, but the server you're talking to may not be legit.

That said, there are a few situations where it is relatively safe to click through the warning:

• When you're not sending or receiving any confidential data, such as passwords or credit card details; note that cookies containing session IDs etc. are also confidential, so you shouldn't do this when you plan to use anything that requires logging in. Also, consider that a bad certificate can be a sign of malicious activity, so you should be extra careful when this happens.
• When you can verify the identity of the server through other means:
  • when the server is on the same local area network (behind the same router / firewall), and the server IP has been obtained through a trusted DNS or a local hosts file;
  • when you can check the certificate's (SHA-1 or other) fingerprint through a different channel (e.g. logging into the server and checking it there): as seen from the client, it must match the known certificate as installed on the server. The connection could still be hijacked, but doing this from outside the network is only possible if the firewall / router is compromised (and when that happens, you have other things to worry about).

TL;DR: Unless you know exactly what is going on, my advice is to not click through but rather properly resolve the issue.

Answer 2

On a theoretical point of view, an HTTPS site with a warning on the certificate is no better, but no worse either, than a plain HTTP site. As long as you only browse, reading data but not sending anything, and not especially trusting what you read, then you can ignore the warning. However, it is quite rare that a reading-only site goes to the trouble of setting up SSL and a certificate.

On a practical point of view, an HTTPS site with a warning on the certificate is worse than a plain HTTP site. Most plain HTTP connections go through without any attack because there are just too many of them, and so many are worthless for an attacker. On the other hand, if some attacker went to the trouble of impersonating an HTTPS server with a fake certificate, then this is a sign that your connection is being actively threatened.

Therefore a browser warning on an HTTPS certificate means one of the two following things:

1. the server administrator did not do his job properly;
2. you are being actively attacked right now.

So you have to be quite sure that proposition 1 is the right one, if you still want to bypass the warning.

A relatively safe situation is when the only thing which gives the willies to your browser is that the server certificate expired not long ago (a few hours, maybe a few days): this just means that some sysadmin was overworked or on holiday, and missed the renewal date for his certificate. Most other cases are not safe: indeed, one can assume that even the most moronic sysadmin tried at least once browsing his own site, so if there is a "permanent" invalidity reason (e.g. the name in the certificate does not match the host name) then the sysadmin must have seen it.

Hence the general advice: if there is a warning, then don't go there.

Just for fun, a marvelous quote from some guy named "Mark Bondurant", in the alt.computer.security Usenet group (quote reported by Peter Gutmann in his X.509 style guide -- a somewhat old but still must-read document, if only for stylistic literary reasons):

I knew a guy who set up his own digital ID hierarchy, could issue his own certificates, sign his own controls, ran SSL on his servers, etc. I don't need to pay Verisign a million bucks a year for keys that expire and expire. I just need to turn off the friggen browser warning messages.

Answer 3

I like the point that SSL provides:

1. Point to point confidentiality - the ssl provider on the server side and your browser are sharing an encrypted session that is not easily breakable by a man in the middle - this gives you both privacy, and integrity between the points.
2. Assurance of the server's identity - when the server side certificate provides proper authentication.

There are a TON of reasons that a user will get "scary browser warnings about SSL certificates" and they vary with both the type of browser, it's version, and the settings within the browser. I used to be able to list them all for the major browsers, but at this point, I believe it's hubris to think its possible, there's so much variation.

Sadly, there is no easy answer I could give a completely novice user on whether to accept risk or not when dealing with a scary browser warning. Here's a few cases, and things to consider:

• Know the risk of what you're transmitting. This is a personal decision. Chances are everybody should be wary of credit card info, social security numbers, or other private data to an untrusted party. But whether you care to send the password for the social network -- well it depends on the risk inherent in having your account hacked -- for some that's huge - their network is the public face of their business. For others - no big deal, it just means they need a new way to find out about family reunions.

• Know the state of the server/service provider and react accordingly. For example, if google, yahoo, or amazon.com offer me a failed certificate, I think twice -- these are HUGE companies, with good reputations, who ought to have enough system admins and foresight to manage their certificates appropriately. The reservation system in the backwater restaraunt that has an expired certificate? Eh, I'll take the risk, they don't need my credit card, and what's the chance that the Mom and Pop restaraunt realized they needed to have the certificate renewed every year. Not an average user thing - but I click through these warnings CONSTANTLY in a test environment where I'm sure that I'm talking to the right server on the internal LAN.

• Here's a few particular genres of error and what they mean:

  • Certificate validity failure/expiration- means that the certificate is not currently valid, but it was at one time. Generally means it's not hacked, it's just too old. It can mean your computer has the wrong time setting, but more likely, if it's a small site, it means they haven't updated their servers properly. Use at your peril, but if it's a small site, it's probably on an attack

  • Certificate not signed by a trusted authority - your browser has a cache of trusted CA certificates, they are used to sign off that the server provider is who they say they are. Most of the Trusted CAs in major browsers have a decent process of vetting the identity of who they sign for. So if this is the failure, it means that either the requestor when to a lower end CA provider (with worse authentication procedures) or they self-signed the certificate. This may be because you're working on a test site, it may come from a server crash (where the server reset to a default) or it may be someone impersonating the site you want. If I'm buying something, this error will usually make me take a pass. For other purposes, I may take the risk.

    • Certificate name does not match URL - This can be because of a bad certificate, but it can also mean that configuration changes have changed the nature of the URL. I may actually write to the site's tech support on this, since a good site should be able to fix the break. But once and a while, I've been able to know an insider scoop that lets me trust the site, even with the mis-match.

From here, IT departments can vary the mileage hugely - you can get all sorts of errors about certificate status checking, which can be a site problem, but it also be an access problem on the part of your network or browser.

Answer 4

It is safe if you are aware that any content you see or provide

• may be seen by other people
• may be manipulated on the way

It does not matter if the site is run by a trustworthy party or not. SSL is used to protect the transmission of data packets on their way through untrusted networks.

Certificates are used to verify the identity of the server. This is required to prevent man in the middle attacks. Otherwise an attacker could claim that he is the real server and your browser would happily send messages encrypted for the private key of the attacker.

PS: SSL does have the issue that some certification authorities such as VeriSign, Commodo and DigiNotar have issued certificates to wrong people in the past. Only the last one was distrusted by the common browsers. But this is another topic.

Answer 5

What makes up HTTPS

SSL/TLS (the S in HTTPS provide three security features, one well, one badly, one rarely.

1. 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.
2. 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 acme.com.
3. 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 yoyodyne.com.
• 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.}

Answer 6

It's never safe to click through an SSL warning message. Evaluate your risk on the conditions in front of you, and either accept the bad cert or not.

At least it's offering you a choice, the Diginotar hack removed that choice from you and there are four other CAs out there removing your choice too.

Mike

*EDIT - If you are using self signed certs, you'd want to add yourself to the cert store as a CA. This way, you don't have to click through if you recognize, it will be validated by the system automatically. There's no issue with using self certs, just do it right.

*EDIT - If you can verify the fingerprint on your own, by inspection, then you are verifying that the cert is actually GOOD, so click through would be ok.