Companies Using Secure Protocols in an Insecure Manner

Friday, September 16, 2011

Cor Rosielle


How Large Companies Use Secure Protocols in an Insecure Manner

We have all heard about the dangers facing us on the interwebs. Luckily, when confidentiality is important, we can protect ourselves by using encryption protocols. Https and SSL certificates make visiting a website a bit more secure.

When you connect to a website using https, your browser verifies the identity of the webserver so you can be sure you connect to the real server and not a fraud. After you have connected, the browser and server encrypt the data they exchange.

When this process is done right, it’s virtually impossible for a third party to eavesdrop on the connection or manipulate the content of your exchange. Alas, my experience shows that this technology is often incorrectly used. In these cases, the confidentiality (and integrity) of the communication is endangered. 

In this article I will give my opinion about the findings, but that’s not the main reason why I’ve written this article. I’m hoping that based on the numbers you will be able to form your own substantiated opinion. If you don't believe the numbers I provide, it shouldn't be to hard to research SSL Certificates yourself, as all of this information is by its very nature in the public domain.   

I decided to collect the numbers for some bigger companies, as I assume they have a decent staff to handle IT security in a reasonable way. So I chose to investigate the use of https and SSL certificates on primary websites of Fortune 500 companies. You would hope the Fortune 500 to use protocols and certificates the proper way.

How the research is done

First step, I found companies listed in this year’s Fortune 500. This was pretty straightforward; I entered something like “Fortune 500” in Google and found they are listed on:

Then I had to find these companies primary website, and that wasn’t too hard either. At the url mentioned above, you just click a company's name in the index and the company's website is mentioned on the next page. This way I discovered the 500 websites for all companies listed in this years Fortune 500. 

Next thing was to find which of those sites could be visited using the https-protocol. Again, no rocket science here. 259 hosts were listening on port 443 /tcp, the default port for https. It turned out that 3 of them did not talk https on that port, or at least not to me... Another 20 servers did not provide me their (public) SSL certificate details (most of them would probably have provided the details if I had been more persistent, but I wasn't).

From the remaining 236 systems, these are the (anonymized) facts:

  • 109 systems were willing to exchange data using SSL version 2
  • 149 systems were willing to use encryption keys of 56 bits or less
  • 160 systems were willing to use either SSLv2 or short encryption keys
  • 7 systems were willing to use 0 bit encryption keys (meaning no encryption)
  • 129 certificates had public keys of 1024 bits or less (one as short as 512 bits)
  • 12 certificates were expired (one as old as May 2008)
  • 9 certificates will expire after more than 3 years (one as late as in August 2023)

Some known imperfections

The SSL protocol version 2.0 was released in February 1995 but "contained a number of security flaws which ultimately led to the design of SSL version 3.0". SSL version 3.0 was released in 1996 (

My opinion: I can imagine that a company wants to support older versions of software for some time for backward compatibility, but not for this long, especially knowing the old version contains security weaknesses.  

Authorities on Cryptographic matters think nowadays a symmetric key should be at least 76 bits ( None of them think 56 bits symmetric keys give sufficient protection after 1982, 0 bits never gave any protection at all.

These cryptographic gurus also think nowadays an asymmetric key should be at least 1138 bits ( None of them think 1024 bits asymmetric keys give sufficient protection after 2010. 512 bits keys are not safe after 1986.

My opinion: the gurus are probably right and keys should have a sufficient length. If the data needs to be protected for 5 years, then find out what the required length is after 5 years and use those key lengths as a minimum.  

A certificate has an expiration date for a reason. If a certificate is corrupted during its lifetime, the Certificate Authority (CA) puts it on a Certificate Revocation List or returns an invalid status when this certificate is checked by your browser using the Online Certificate Status Protocol.

To prevent a revocation list from growing out of control, the certificates are removed from the lists after the expiration date. As a result you cannot check expired certificates, so all expired ones are considered invalid. 

This is also the reason why certificates with an expiration date in the far future are undesirable: if the certificate is corrupted, it has to stay on the revocation lists for a long time. And even then the corrupted certificate is only detected if the browser checks the list.  

Closing remark

You don't have to take my word on all of this. You can check the configuration of (https) web servers yourself. Have a look and form your own opinion.

Remember, I only looked at the Fortune 500. Companies with (hopefully) knowledgeable IT and security staff. Companies with a board and directors who should care about security and have sufficient budget to get these basic things right.

Let's hope the respective companies are just as disappointed about these results as I was and start to worry more about getting secure instead of becoming compliant. But lets not get into that right now... 

So what?

You might wonder: "Why should I care?". Well, for those of you not experts in web security, let me explain.

Companies who do business on the web need to follow certain laws and regulations. In security speak, it's called "Compliance". It keeps the consumers safer because not everybody will be an expert in knowing if a website has taken the necessary precautions to keep them safe from third-party theft and fraud. So there's multiple types and layers of oversight, depending on the country and the services offered.

Fortune 500 companies find themselves requiring regular security compliance audits. The idea is that they must pass or shut down. In reality, these regulations often don't have teeth big enough for these companies to care. But they still get the security audits, usually for their own sakes.

Now, the most obvious thing any web security auditor can find in verifying the security of a website is the security certificate. Missing that is like failing to notice a car is missing tires during a car inspection.

To be fair, it's quite possible the inspector caught these things and the company chose to ignore it. But we're not talking about something management would pass on because it's expensive. Neither because fixing it is technical or likely to take operations offline like rebuilding an infrastructure here. We're talking about the decision to fix it- something any CIO, or secretary, could do.

So it's more likely the auditors missed it rather than management failing to renew it. So somebody dropped the ball. So much for oversight. And more than being shameful for the company, it's criminal for the auditors.

So so what? So where's the oversight that supposedly we all have to comply to? Where else is the oversight getting ignored, shirked, or corrupted?

So what?

It's embarrassing, that's what.

Special thanks

... to Jay Abbott, Bouke van Laethem and Pete Herzog for their constructive comments on the first draft of this article.

Possibly Related Articles:
Encryption SSL Digital Certificates report HTTPS Protocols Fortune 500 Enterprise
Post Rating I Like this!
Matthijs R. Koot It's a pity that you don't address the fundamental flaws in CA trust model that the DigiNotar debacle so nicely stuffed in our faces. The statement "When this process is done right, it’s virtually impossible for a third party to eavesdrop on the connection or manipulate the content of your exchange" painfully misses that (IMHO).

This part was most interesting to me:

109 systems were willing to exchange data using SSL version 2
149 systems were willing to use encryption keys of 56 bits or less
160 systems were willing to use either SSLv2 or short encryption keys
7 systems were willing to use 0 bit encryption keys (meaning no encryption)
129 certificates had public keys of 1024 bits or less (one as short as 512 bits)
12 certificates were expired (one as old as May 2008)
9 certificates will expire after more than 3 years (one as late as in August 2023)

Keep exploring, thanks for sharing your findings!
Cor Rosielle @Matthijs: the hassle with DigiNotar was the reason I submitted this article. In this article I didn't address how DigiNotar failed or how the trust model in general flaws, because a lot of others did that over the past few weeks. The purpose of this article was to demonstrate that not only the vendor of certificates van mess up, but also user of certificates mess up and reduce the effectiveness of certificates.

Even with perfect, accurate and trustworthy Certificate Authorities, the companies using the certificates fail by making mistakes. Result is that the level of protection drops, sometimes dramatically. It is not the CA's fault if a company allows SSLv2 or weak cipher suites. This is not to blame on the certificate, but on the servers configuration. But it still reduces vault quality of security to door lock quality or even a simple obstacle.
And the auditors of these companies fail too because they don't notice the mistakes. That's not a surprise, because it is not in the skill set of most auditors to notice this. Most of them do understand regulations and can tell if you comply to those regulations or not. That's a complete different ball game.

If you read the article carefully, you might find some facts we can blame on the Certificate Authorities. You can expect a CA knows a little about key sizes. It is hard to believe they don't know about the minimum required key length on a certain moment in time. So I think they are partly to blame for selling certificates with 1024 bits asymmetric key pairs or certificates that are valid too long. They shouldn't do that. But companies are tempted to choose for such certificates because they're cheaper. And if a responsible CA refuses to sell these certificates, they might lose customers.
seo india
Excellent posts to read keep it up and keep going on this way. And keep sharing these types of things Thanks

seo india
seo india
seo india
Craig S Wright I would also recommend that you add checking for support of the NULL cypher. NULL is a valid cypher in SSL and TLS and I have seen this in some large ecommerce implementations as it is blindingly fast (due to a 0-bit key).
Cor Rosielle @Craig I did. You can see in the list: 7 systems were willing to use 0 bit encryption keys
Craig S Wright Sorry, I missed that in the list...
Michael Lin It’s very interesting to see the breakdown of encryption policies with these major companies all laid out like this. The last bullet is pretty glaring to me, even though it included a small list of sites. I think most people would agree with me (even with my affiliation to Symantec) on the point that SSL is imperative for any site where visitors are inputting personal information, which is probably the case with most websites people visit each day. But beyond just SSL, there are standards of implementation and upkeep that businesses need to adhere to if they are really going to reap the benefits of SSL. With how many breaches we have seen lately, it is time for those implementing SSL to make sure they have the sound implementation practices in place to match the technology.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.