Ok, so most of you should have read by now the headlines about the Heartbleed bug and it's consequences. For those of you who haven't, there is an abundance of resources out there that explain the issue (just google it). The gist of it is that an attacker could leverage the bug and access memory on the server that could contain the SSL certificates private key. Using this, they could create fraudulent certificates, mount a man-in-the-middle attack to get your credentials or, if they have been monitoring traffic between the clients and the server, decrypt the (under TLS) encrypted traffic. Additionally, the issue only exists in OpenSSL implementations that implement the SSL heartbeat feature (which is more or less 17 percent of the worlds web servers).
Ok, so, I've been getting a lot of emails from services informing me they have patched the issue and that I should change my credentials. Is this something you should do for all your online accounts?
Unfortunately, the answer isn't quite simple.
First of all, if you get an email from a company advising you to do so, you should look for two things in the email:
If they have done both, then yes, you should change your password. As soon as possible (no hard in being proactive).
Now, if they haven't had a new SSL certificate issued, there is no point in doing so. If an attacker managed to get their SSL certificate private key, they don't have to rely on the bug any more. They could still mount a man-in-the-middle attack or sniff encrypted traffic between the clients and the server (in which case they will simply just get your new credentials - even if they didn't have them in the first place, in case they weren't monitoring past traffic or you did not login in the past few days since this went public).
Also, the issue is further more complicated by the fact that by default, browsers do not check Certificate Revocation Lists (CRLs). This means that even if the service gets a new certificate issued (in which case the old one is revoked), an attacker could still use a fraudulent certificate with the old private key and be successful in the attack (your browser does not know that it is revoked since it doesn't check). The only real solution to this is to change your browser settings to check CRLs (just google CRL and your broswer in use and you should get a tutorial on how to do this).
But what about mobile clients (or even worse, mobile applications)? Mobile browsers do not check for CRLs, and they have no option to turn checking on! At least I couldn't find one on my Nexus 4. And in applications, its up to the developer to implement the check.
So in short, if you are confident that your service provider has indeed change their certificate and implemented a patch, you could (and should) change your password. But, the fact is that this is one of those really, really worst-case-scenario issues and it will take a long time before everyone is up-to-date on patches and has renewed their certificates. As for the mobile device issue, your guess is as good as mine.
Ok, so, I've been getting a lot of emails from services informing me they have patched the issue and that I should change my credentials. Is this something you should do for all your online accounts?
Unfortunately, the answer isn't quite simple.
First of all, if you get an email from a company advising you to do so, you should look for two things in the email:
- They have patched their OpenSSL implementation (and are now not vulnerable).
- They have had a new SSL certificate issued.
If they have done both, then yes, you should change your password. As soon as possible (no hard in being proactive).
Now, if they haven't had a new SSL certificate issued, there is no point in doing so. If an attacker managed to get their SSL certificate private key, they don't have to rely on the bug any more. They could still mount a man-in-the-middle attack or sniff encrypted traffic between the clients and the server (in which case they will simply just get your new credentials - even if they didn't have them in the first place, in case they weren't monitoring past traffic or you did not login in the past few days since this went public).
Also, the issue is further more complicated by the fact that by default, browsers do not check Certificate Revocation Lists (CRLs). This means that even if the service gets a new certificate issued (in which case the old one is revoked), an attacker could still use a fraudulent certificate with the old private key and be successful in the attack (your browser does not know that it is revoked since it doesn't check). The only real solution to this is to change your browser settings to check CRLs (just google CRL and your broswer in use and you should get a tutorial on how to do this).
But what about mobile clients (or even worse, mobile applications)? Mobile browsers do not check for CRLs, and they have no option to turn checking on! At least I couldn't find one on my Nexus 4. And in applications, its up to the developer to implement the check.
So in short, if you are confident that your service provider has indeed change their certificate and implemented a patch, you could (and should) change your password. But, the fact is that this is one of those really, really worst-case-scenario issues and it will take a long time before everyone is up-to-date on patches and has renewed their certificates. As for the mobile device issue, your guess is as good as mine.
No comments:
Post a Comment