Diginotar breach and what it means to you
This morning, I was reading some comments on the Diginotar breach. The Dutch minister of internal affairs gave a press conference at 1:15 AM, Saturday, September 3rd. He announced that the Dutch government was revoking trust in Diginotar. If you “google” it, you will find plenty of information on the topic.
There is a lot of speculation on the source of the attack, though, at this point, many are speculating it to have originated from the Iranian government. There is plenty of information around, so I will not dwell on providing further insights. My main reason for writing this entry is to discuss “user behavior.”
When you browse an HTTPS website, your browser and the server exchange a CA certificate. CA stands for Certificate Authority. There is a reason for this name – the entity who created the certificate is “authorized” to do so. It has the authority to create public certificates; it has an infrastructure in place to guarantee that such certificates are original, and to revoke them when they are not. Browsers take notice of this and when a certificate is revoked, your browser receives an update so it knows not to trust that particular certificate anymore.
These certificates usually carry the name of the website; for example, if you go to https://mydomain.com, you would expect the certificate to carry that domain’s name in it. So, if you reach the same server via its IP address, instead of its name, the browser will issue a warning saying something like: “This certificate name does not match the URL you were trying to reach.” Now, it is up to you to accept the certificate anyway – to trust it – or to move on and browse somewhere else.
The unfortunate truth, of which I myself have been guilty a few times, is that even though the browser gave us a warning, we tend to pay little attention to it. We click “get me there anyway”, and keep going.
This allows a hacker to conduct what we call a “man-in-the-middle attack.” That little and, apparently, insignificant warning your browser tried to give you might have been related to the fact that you didn’t really reach the intended site, but another, rogue, server. And ipso facto, you have been attacked and your computer might have been compromised.
The same situation can occur if you are trying to VPN to your office with a clientless, browser based, VPN. Assume you are in a public place, a coffee shop for example, or at the airport. You attempt to logon to the VPN via your unprotected wireless connection; someone with ill intentions is in the same area, sniffing the airwaves with an automated tool (there are plenty on the internet, all free), and when it intercepts your attempt, it sends you a different certificate, conducting a man-in-the-middle attack. In essence, your computer “thinks” it is talking to the VPN server when, in reality, it is talking to the attacker’s computer. Your browser will give you a warning, but you are too busy to notice, get annoyed by the warning, click OK and keep going. Now the attacker is talking to your computer pretending to be the VPN server, and it is talking to the VPN server pretending to be you. So all your communications back to your office, which you assume are encrypted and well-protected, are actually flowing through the computer of your attacker. He can record them and decrypt them (remember, you are using his certificate so he can open your conversation), and basically steal all the information that is going across your communication.
What can you take away from all of this? If your browser issues a warning about a certificate, don’t ignore it. Read it, read it carefully, and if in doubt, abort what you were doing and call for help. It may be nothing; but it may be something very serious indeed!
Incidentally, this is also the reason why, at Network Box, we have been resistant to the idea of a clientless SSL VPN. They are easy to deploy and maintain, but they are subject to these risks (among other things); and therefore they cannot guarantee 100% true security. Additionally, since security is what we do, we have been cautious about this feature. The market wants it, and therefore we may eventually give in; but with the warning that such issues may occur because of the way browsers work and because of the way we all, as humans, tend to behave. After all, hacking is 90% exploitation of human behavior. But that’s a topic for an entirely separate conversation.
A good week to everyone who reads this post.
Photo by Markus Spiske on Unsplash