SSL : Implementation Gone Wrong

Image via Wikipedia

During the recent security conference Hack In The Box, security researchers from Qualys Labs showcased the fruits of their efforts to scan the Internet’s websites for proper implementation of security features like SSL and its successor TLS. What they found could only be described as dismal.
SSL stands for Secure Sockets Layer, and TLS for Transport Layer Security. While these two protocols share the same purpose, it’s important to note that TLS is a more secure version of SSL. You may hear them used interchangeably because the first version of TLS (the most commonly used version of encryption on the internet) is backwards compatible with SSL 3. These two protocols work off of public key infastructure or PKI, which requires a trusted third party to generate code that says that a website is who they say they are.
The end result is a secure and encrypted communications channel through which clients can talk to servers. When it’s properly implemented.

The Good:

You may already be familiar with SSL and TLS through your experiences in logging into your bank. All banking institutions utilize SSL or TLS to secure communications between client computers and the bank computers in case there are any eavesdroppers on the network the client is using. Without it, clients may find their banking passwords swiped or their personal information leaked to criminals who leverage it to do everything from empty a checking account to getting a loan.

Banks typically use SSL and TLS protocols throughout your logged-on stay on their website. In technical terms, this stay is referred to as a “Session”. The goal of the encryption provided to you in TLS or SSL is to protect this session and the things you do while you are in the session. This way an eavesdropper can’t see how much money you have left on your mortgage, or see how much you’re paying for cable this month, or something more sinister, like your account numbers or social security number.

The Bad:

Many sites, especially some large and popular ones (Facebook, Twitter, Google), utilize TLS/SSL only during the login process so that your username and password can’t be seen by anyone else but you. This works well in theory, but since the rest of the connection is still unencrypted, watchful eyes can still see what you’re doing on Facebook, who’s tweets you’re reading on Twitter, or what you’re doing today on Google. Additionally, since websites remember who you are with tokens (a string of characters given to uniquely identify you for your current session after you log in) and tokens are sent every time you interact with a site while you are logged in, a criminal watching the network can steal and hijack your token and then instantly become logged in as you until you click the “log out” button.

It is unfortunate that websites as large as Twitter or Facebook do not do more to help protect their users, but some administrators make the argument that the users of a web service should be making sure themselves that they aren’t on compromised networks, since the protection offered by implementing SSL/TLS is exclusively for clients. SSL and TLS don’t actually improve the security of a server or online service from an internal perspective. In other words, since there are no security benefits to the company or computer, it’s not a prerogative to implement fully.

The Ugly:

Most of the users on the Internet have gotten into the (bad) habit of assuming that their personal information is kept private on the Internet so long as they keep their username and password to themselves and they stick to sites with padlocks on them. This is simply not the case, especially when they click through the browser warnings about SSL and TLS. I’ve noticed personally that many users will simply click through or add exceptions to security alerts to sign on because they are used to doing so. This means that they’re vulnerable to all sorts of basic attacks against SSL and TLS.

While these attacks are bad on their own, improper implementation is far and away the most to blame. It is the reason why users click through and ignore security warnings about SSL and the same reason why users feel good from a padlock in their browser window even as their credit card number is being stolen. Just because you have a form of SSL implementation on your website doesn’t mean that you’re securing your users. In fact, the illusion of security is far more damaging. Here are the highlights of the research done that illustrate how insecure some websites with SSL/TLS can be.

• Over half of SSL-enabled websites allow users to use an insecure and outdated version of SSL (SSL 2).
• About 28% support insecure renegotiation of encrypted sessions (allows an attacker to view your data even though it is “secure” according to your browser) called “The Closest thing to a serious TLS protocol Flaw so far”.
• Over 80% of sites don’t force their users to use SSL/TLS
• 10% of tested websites had incorrect certification chaining (the chain of trust that establishes a site is who they say they are)
• Almost no websites use the newest version of TLS, opting for the SSL 3 (also known as TLS 1)
• over 60% of the tested servers allow weak key lengths to be used (less than 128 bits. The lower the key length, the easier it is to crack.)

Think BEFORE You Click

Make your users aware of the need to read prompt boxes from web browsers, especially when first visiting a website. Make sure that they know not to go on any common websites (Gmail, google, Facebook, twitter, yahoo, Myspace, ect..) if the web browser warns them that there is a problem with the certificate. These websites are the most likely targets for a criminal to watch if he/she has compromised the network, and they are unlikely to let their security credentials for SSL/TLS expire due to their large user base and the problems that would cause.

Unfortunately smaller sites don’t always conform correctly, which is where the bigger problem in SSL and TLS security comes in — proper implementation. So many sites are now improperly configured that it has taught users to ignore certificate security warnings. This needs to be fixed so that the security model can operate properly, without users distrusting or ignoring warnings because of their day-to-day occurance.

Are You Part of the Problem?

System administrators should test to make sure that their implementation of the SSL or TLS protocols is proper and up-to-date. To test that your implementation of TLS or SSL is secure, visit https://www.ssllabs.com/ssldb/analyze.html and input your domain name to see your score.
Recent statistics compiled by Qualys Labs and the EFF have shed some light onto the current state of SSL/TLS implementation, which shows that the vast majority of websites on the Internet haven’t properly secured their SSL/TLS servers for maximum security.

The slides from the Hack in The Box Security Conference can be found here: http://conference.hackinthebox.org/hitbsecconf2011ams/materials/D2T1%20-%20Ivan%20Ristic%20-%20A%20Study%20of%20What%20Really%20Breaks%20SSL.pdf

More information about SSL attacks and breaking SSL:
http://blog.ivanristic.com/2009/11/not-just-csrf-ssl-authentication-gap-used-for-credentials-theft.html
http://www.cupfighter.net/index.php/2011/05/hitb2011ams-what-breaks-ssl/

Original post