Tag Archives: TLS

Does Your Incident Response Plan Address TLS Certificate Revocation?

Warning: Sorry, this post is way more technical than most of my posts.  If you are an executive reading this, you may want to show this to your security or IT folks and ask “how are we handling this?”.  They should be able to explain that to you in English.

Incident response is all about having already considered the scenarios and having a plan for dealing with it.

Consider this scenario:

You have a web site, mail server or other system which is encrypts traffic using a TLS (or more generally X.509) certificate.  That protection works with a secret encryption key and a public key.  Those keys expire after a time period such as one, two or three years (I have seen ones as long as 10 years).

This all works as long as the secret key remains secret.

But what happens if you have an incident where the secret key, which may live on a server or an admin’s workstation (IT SHOULD NOT!) gets compromised?  How do you deal with that.

The problem is that if the private (secret) key is no longer secret, then a hacker can masquerade as you and even encrypt the data with their victim.  There is nothing that a victim can see that would make them suspicious.

If the secret key gets compromised, you can get a new one, but the challenge is how to revoke the old one.  This is something the industry has been wrestling with for years.

FIRST ATTEMPT: Certificate revocation lists:  The certificate authorities that you get your TLS certificates from maintain a list of revoked certificates.  It turns out that this process was so unwieldy that many browsers don’t even look at these lists any more, so that measure is useless.

SECOND ATTEMPT: OCSP or Online Certificate Status Protocol is an attempt at fixing the first attempt.  Instead of browsers having to maintain and update lists in each user’s computer when you try to connect to a secure web site, the browser can make another connection to the certificate authority’s OCSP server to see if the certificate is good.  Only problem is that what do you do if the OCSP server doesn’t respond?  Do you deny access or do you cross your fingers and hope that the same hacker who stole your certificate is not blocking your access to the OCSP server?  Plus, it means that every time you establish a connection to a  secure web site (almost all of them now), it will take twice as long because you have to make a second connection.

THIRD ATTEMPT:  OCSP Stapling.  With OCSP Stapling, the SERVER sends a copy of the OCSP certificate at the same time that you are negotiating the connection.  The server updates the OCSP proof frequently (say every 10 minutes) so there is much less overhead from the browser’s standpoint.    It turns out that some stapling implementations don’t work right and a hacker might tell the victim’s browser not to use OCSP or stapling and the victim would not know any better.

FOURTH ATTEMPT: As I am guessing that you can tell by now, this problem does not have any easy answers.  The next attempt was ACME or Automated Certificate Management Environment.  ACME creates certificates that have a relatively short life expectancy.  For example, Let’s Encrypt creates certificates that only last 90 days and automatically renews them.  But 90 days is a long time for a hacker to be able to run amuck with your credentials.  What you want to do is make it last only a day or a few hours.  This means if the vendor that is issuing the ACME based certificates is down, you won’t be able to get a new certificate and you will be down.  Still, this is way better than the first three attempts.

FIFTH ATTEMPT: (is this getting a bit out of hand?)  There is a new standard in the pipeline with the Internet Engineering body (IETF).  It is designed for big firms right now, but it will evolve.  It does require a change in the browser to make it work, but Firefox already has it and it is likely that Chromium (the basis for Chrome, Brave, Opera, Edge and others) will likely have it soon.  But remember, this is, right now, only for the big folks.  This is called Credential Delegation.  With Credential Delegation, the certificate authority issues the web site owner a normal signed credential but the web site owner has the ability to create delegated credentials that might only last a day or an hour.  They can only do this to the same domain that the certificate authority originally issued their certificate for.  The win here is that if a Delegated Credential is compromised, it will only be usable for a couple of hours to a couple of days.  For example, Facebook is one of the early adopters and is testing it.  If someone were to steal a Facebook credential but that credential was only good for say, 6 hours – or 30 minutes – the amount of damage they could do is greatly limited.

Here are a couple of takeaways:

1. If you are using traditional TLS certificates, do not create certificates that are valid for more than one year.  At least you are beginning to reduce the risk window.

2. Make sure that your certificate provider supports OCSP.

3. Make sure that your certificate provider implements OCSP stapling and that you have enabled it on your server.

4. If your certificate provider supports it, implement OCSP MUST STAPLE.  This will cause the connection to fail if there is no attestation attached to the connection that a hacker uses to try and scam a victim.

5. Use an ACME provider if possible.  Again, we are trying to reduce the time window that a hacker can use your stolen information.  If that window is reduced from one year or two years down to 90 days or 30 days, that is a huge win.

6. Watch for progress on Credential Delegation.  If might be a year away, but when it happens and is available for everyone, you will have the ability to close that window that a hacker can use your stolen certificate down to a day or a couple of days.  Much better than a year.

I know this is a very technical post;  if you have questions, please reach out to us.

For more technical information, see here, here, and here.


Yet Another Reason Why HTTPS is a FAIL!

Merchants want you to believe that HTTPS equals secure.  I keep saying that it doesn’t.  Here is another story for my side of the argument.

First, a little background.  If a web site want to support HTTPS (also known as SSL or TLS), they need to have a certificate.  The certificate is used as part of the process of generating an encryption key for each session.  The owner of the web site buys (or gets one for free) a certificate and depending on the type of certificate, the buyer has to prove, more or less, that they own the domain that they want a certificate for.

Why do they have to prove they own the domain?  Because if they didn’t have to prove they own it, anyone who wanted to could buy a certificate and install it and launch a bogus web site that pretends to be Facebook or Amazon or whoever.

Using the standard methods that certificates use, any certificate authority – and there are hundreds of them – can issue a certificate for your web site.  As long as that certificate authority is trusted by your browser, you will have no clue that the web site that you think is owned by Amazon or Google or whoever is not legit.  You will see the padlock and everything.

To make things worse, under these circumstances, an attacker can even create a bogus Google.Com or Amazon.Com, fool your browser into going to that site (using DNS spoofing or other techniques) and you now think you are at the real Google or Amazon.

Under the way things normally work with certificates, any certificate authority anywhere in the world can issue a certificate for your domain.

On some operating systems/browsers, you can disable which of the hundreds of certificate authorities you want to trust.  That doesn’t solve the problem of a hacker imitating your web site and someone believing it, but it does solve the problem of you trusting sites certified by authorities in say China.

Curiously, it is pretty easy to disable, say, a certificate authority in China on Android but it is literally impossible for you to do this on an iPhone.  This is because Apple’s philosophy is that Apple knows best.  For details on how to do this (it is  pretty geeky) on different environments, check the link below.

SO, now what is the new problem.  The problem is that a Chinese certificate authority, WoSign, had a bug in their software that allowed people to get a certificate for a domain, say Google, if they could show that they could control a sub-domain, say mitch.google.com.  A researcher tested this by using this bug to get a certificate for the popular web site GitHub and also for a Florida University.  When they explained the problem to WoSign, they did revoke the certificate to GitHub, but did not revoke the one to the university.  This is leading some people to speculate that they do not know what certificates they issued.

But remember that your browser trusts WoSign, so even though they are issuing bogus security certificates, your browser will trust them.  If  you are not using an iPhone, at least if you are motivated, you can decide that YOU are not going to trust WoSign, but I doubt very many people will go to that trouble.

Remember I said that WoSign revoked the bogus certificate to GitHub.  Well that is nice, but it turns out, for a variety of reasons, certificate revocation doesn’t actually work.  So while that GitHub certificate is revoked in theory, it may still work in practice.

While I don’t have a better answer for HTTPS, I can say with some confidence it is seriously broken.  There are some possibilities like DNSSEC+DANE or certificate pinning, but very few web sites, in the grand scheme of things, have the ability to do this.

Which is why I keep saying that SSL is broken.  We are giving people the delusion that things are secure, when they are not really very secure.

We really ought to do something about this before some hacker comes up with a really creative way to steal a lot of money.

Information for this post came from The Hacker News.

Information on how to remove the trust for certain certificate authorities can be found at CertSimple’s blog.

Businesses Get More Time To Upgrade Buggy Encryption Software

The PCI Council, the standards body that dictates the rules for payment card (like Mastercard and Visa) merchants and service providers last year released a directive that everyone had to upgrade their software and eliminate SSL 3.0 and TLS 1.0 in favor of newer versions – TLS 1.1 and 1.2.  The reason was that there are known security holes in those versions of software that are UNFIXABLE – they cannot be patched.  They set a deadline of over a year from when they released the directive for people to fix the problem.

Large organizations apparently complained that they have implemented a bit of a rat’s nest (no big surprise) and with everything else on their plate, they were not going to be able to get to fixing the broken SSL implementations.

As a result, the PCI Council changed the deadline from June 2016 to June 2018 – three years from the original directive.

One thing that is important to understand is that just because the PCI Council changed the date by which, if you have not upgraded, that you will be in violation of your merchant agreement with your bank, you are not relieved of liability in case of a breach.

In fact, I assume that plaintiff’s counsel will be asking if a breached merchant was still running a known vulnerable version of encryption at the time the breach occurred.  One would assume that this would not work to the merchant’s advantage at trial or in settlement negotiations.

Given this announcement, I expect that the hacking enterprises (like China, Russia and Ukraine, for example) will be looking for enterprises that have not upgraded their encryption software and specifically target them.  Given that there are known attacks, that makes these businesses an easy target.

What I am suggesting here is that even though the PCI Council has granted an extension, businesses should not delay their encryption upgrade projects.

The payment card industry, as a whole, spends tens of BILLIONS of dollars a year on payment card fraud.  A 2011 Forbes article says that the industry loses $190 billion a year to credit card fraud.  Even if Forbes has the number wrong by a factor of 2 or 3 too high, that is still a huge number.  That cost is reflected in higher prices and fees that customers – consumers and businesses pay.  By delaying the fix to encryption by two more years, the PCI Council is guaranteeing that the fraud costs will rise over that period and possibly significantly.

Information for this post came from Slashdot and the PCI Council.

Another SSL Attack – But Don’t Panic

SSL and TLS, the security protocols that protect most of our banking and ecommerce transactions is a complicated beast – more so due to the the many options it offers.

ars technica in an article titled “Noose around Internet’s TLS system tightens with two new decryption attacks”, discussed a paper presented at Black Hat Asia that describes a new attack, dubbed the Bar Mitzvah attack (do researchers have contests to come up with strange names?) due the the fact that it has been around for 13 years.

As ars reports, RC4, named after cypto pioneer Ron Rivest of RSA, has been  known to be weak for years.  But weak is a relative term.  One attack, from 2013 required the attacker to see 17 billion encryptions of the same text to reveal SOME of the data in the encrypted stream.

Now researchers have improved that attack.  With only 67 million encryptions, they can recover passwords 50% of the time.

Now a new attack, presented at Black Hat Asia and dubbed the Bar Mitzvah attack, attackers need to sample around a billion encryptions to recover a credit card number.

RC4 is used by around 30 percent of internet TLS (Https) traffic.

As I said above, SSL and its newer cousin TLS have many options.  Some say too many options.  While these attacks don’t seem to present a huge problem if the first attack went from 17 billion encryptions to 67 million in a year, what will next year bring.

The simple solution – like we did for the FREAK attack earlier this year – is to disable known weak ciphers.  But this must be done on the server side for web sites to know they are secure and there is no way for the customer of a bank, for example, to easily know that the banks have disabled these older weaker protocols.  With the FREAK attack, one method of delivery would be for a user of a public WiFi router to be forced to use the weak protocols as a result of a man in the middle attack at that public WiFi access point.

This is why I recommend to NEVER do your banking over a hotel or coffee shop WiFi.  There is a new attack today against a very popular hotel WiFi system (see news here ) for which there is a patch.  However, the researchers who revealed the attack did not say, for security reasons, which hotels of which chains run that system and users have no way of knowing if the hotel has applied the patch.

All this means that IT shops need to spend more time and effort caring and feeding the security components of their server farms.