Friday, September 23, 2011
Companies Using Secure Protocols in an Insecure Manner
Friday, September 16, 2011
Contributed By:
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: http://money.cnn.com/magazines/fortune/global500/2011/full_list/index.html.
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 (http://en.wikipedia.org/wiki/Transport_Layer_Security).
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 (http://www.keylength.com/). 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 (http://www.keylength.com/). 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
Contributed By:
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: http://money.cnn.com/magazines/fortune/global500/2011/full_list/index.html.
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 (http://en.wikipedia.org/wiki/Transport_Layer_Security).
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 (http://www.keylength.com/). 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 (http://www.keylength.com/). 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
# posted by raveneye @ 9:12 AM 
