SSL Labs: Check your security

When we connect to banks, credit unions, online stores, our medical records, or our doctor's web interface, we expect them to maintain competent security. Often we are disappointed. Now we have a very good test, which will look at the security of our connection to our private information holders and tell us how well they are doing. I recommend you run this test on banks, hospitals or doctors who hold your medical records, investment firms, and any online company who has an account you log in to which holds private information like your credit card number.

Sample Results:

Don't worry about the whole report. Just look at the summary. The above was from a major (perhaps the major) national health care provider. They are not providing a secure connection when you log into your account. If they can't do this simple thing, it is unlikely they can protect your data from hackers. Let's examine the report.

Interpreting the Results

What we are examining is the secure connection to their site provided when you log in to your account. This is the SSL (or TLS) connection. I wrote an article explaining how SSL works here. A supposedly secure connection is made when you see HTTPS and a padlock in the address bar. Essentially, a good secure connection will allow you and the website to communicate securely and privately even if someone is intercepting and watching all the communications. SSL Labs tests five aspects of that connection.

The most common problem is that someone inserts themselves between you and the host server, then they take your commands and resend them to the host. A good secure connection will work even if the person in-between can see everything. Even if all your communications are intercepted, examined and then passed on, they will still be secure because the person in-between will not be able to see the information.

Proper Secure connections will do 4 things:

Verify that you are connected to the company your are trying to connect with, not a fake site
Setup a secure protocol for the information exchange
Negotiate an encryption key with you that the person in-between cannot see
Agree on an encryption method.

As time has passed, weaknesses were found. Then improvements were made. Further weaknesses were found and more improvements made. So, there are many protocols, methods to negotiate a key, and encryption methods. The person who wants to break your connection, will intercept the communications and claim it doesn't know how to do the more secure protocols, trying to force the server to use some weak protocols, keys, and encryption. If they are successful, you have lost your security.

SSL Labs tests 5 things:

Certificate: The certificate is needed to show that the site really is who they say they are. Your connection cannot be hijacked and sent to a fake site pretending to be your target website. You can see that the sample site does this well.
Protocol Support: Protocol is the exact method they use to send information back and forth. The first accepted protocol was created in 1995, and since then they have improved security four times. The last update was in 2008. So, there are 5 possible protocols, from the very weak 1995 protocol (called SSL 2.0) to the very strong 2008 protocol called TLS 1.2. A website starts with the best one it knows, and drops back until it can agree with a client machine (your machine) on the best protocol they both know. SSL Labs subtracts points if the server does not offer to use the best protocols, or does offer the very worst. Here again, the sample server did fine. Hackers who get in between, will play dumb, and try to force the protocol to be as weak as possible.
Key Exchange: The Key Exchange is when you and the server agree on a key for encrypting your communication. Once again, someone intercepting your communications and resending them will pretend stupidity and try to get the server to agree on a weak password. The server offers a good long key, and the "man in the middle" says, "oh gee, that's so long. Let's do a short simple key." If the server agrees, then they will use a short key to encrypt the communications. That means your security is compromised. This is where the sample site blew it completely. They would agree to keys which are insecure.
Cipher Strength: SSL Labs checks the strength of the cipher used. Now that you and the server have agreed on a key to use to encrypt your transmissions, you must agree on an encryption method. The cipher is the method used to encrypt the data. There are lots of ways to encrypt the information, some better than others. As with the protocol, the server begins by trying the most secure cipher it knows, and works its way down until it finds one you can agree on. Again, as with the protocol, and a key, a hacker who inserted themselves between you and the server, will play dumb and say you don't know any of the good ciphers, so it is important that the server not agree to weak ones. SSL labs removes points if the server does not offer the best ciphers, or does offer the worst broken ones. Again, this medical center failed to protect you. Also, all of my doctors' offices failed this as well.
Other: Finally, SSL Labs checks for known attacks and whether your site has fixed the holes in their connections to protect against known vulnerabilities. Here you will see that this massive health care provider, is open to the well known and documented BEAST attack.

So, if there were a "man in the middle" between you and the Medical Center's server, as shown in the sample above, they could get the server to agree on a sub-optimal protocol, a short key, and a weak method of encryption. I wouldn't want to trust my data to them.

How to run the test

Be sure you go to a login page. Some companies have an insecure front page, and then move to another server for their secure login. Just go to login and copy the address.

Then paste it into the Domain Name entry field at SSL Labs test page.

What to do with the results

I would like you to call or email any vendor you have who fails to get an A on these tests. If you score over 80, you get an A. Less than 80 is too insecure for me.

Why are so many healthcare sites using weak encryption and weak keys?

After World War II, England and America felt they were ahead in cryptography. They classified encryption as a munition and restricted export. They refused to allow export of any software using keys over 40 bits. 40 bits was short enough that even in the 1970s and 1980s it could be cracked easily. In 1996 President Clinton removed software from the munitions category and placed it under the commerce department, effectively removing these restrictions. However, servers still come with these cipher suites enabled.

So why are so many healthcare records sites still allowing such insecure encryption technology to be used, when banks and e-commerce businesses refuse to and 12 years ago the NIST set a better standard? Apparently, they just don't know they need to remove these options from the servers they bought.

Supplemental Material

I have another document with supplemental material to help you. I've included my results from many tests plus an SSL timeline and two sample emails to failing vendors.

Date: August 2013

This article is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.

Keeping clients' computers safe and profitable for over 30 years

Home Forms About Current Newsletter subscribe Search All Articles Browse by Category Security Internet Mobile Business Hardware Fun		SSL Labs: Check your security When we connect to banks, credit unions, online stores, our medical records, or our doctor's web interface, we expect them to maintain competent security. Often we are disappointed. Now we have a very good test, which will look at the security of our connection to our private information holders and tell us how well they are doing. I recommend you run this test on banks, hospitals or doctors who hold your medical records, investment firms, and any online company who has an account you log in to which holds private information like your credit card number. Sample Results: Don't worry about the whole report. Just look at the summary. The above was from a major (perhaps the major) national health care provider. They are not providing a secure connection when you log into your account. If they can't do this simple thing, it is unlikely they can protect your data from hackers. Let's examine the report. Interpreting the Results What we are examining is the secure connection to their site provided when you log in to your account. This is the SSL (or TLS) connection. I wrote an article explaining how SSL works here. A supposedly secure connection is made when you see HTTPS and a padlock in the address bar. Essentially, a good secure connection will allow you and the website to communicate securely and privately even if someone is intercepting and watching all the communications. SSL Labs tests five aspects of that connection. The most common problem is that someone inserts themselves between you and the host server, then they take your commands and resend them to the host. A good secure connection will work even if the person in-between can see everything. Even if all your communications are intercepted, examined and then passed on, they will still be secure because the person in-between will not be able to see the information. Proper Secure connections will do 4 things: Verify that you are connected to the company your are trying to connect with, not a fake site Setup a secure protocol for the information exchange Negotiate an encryption key with you that the person in-between cannot see Agree on an encryption method. As time has passed, weaknesses were found. Then improvements were made. Further weaknesses were found and more improvements made. So, there are many protocols, methods to negotiate a key, and encryption methods. The person who wants to break your connection, will intercept the communications and claim it doesn't know how to do the more secure protocols, trying to force the server to use some weak protocols, keys, and encryption. If they are successful, you have lost your security. SSL Labs tests 5 things: Certificate: The certificate is needed to show that the site really is who they say they are. Your connection cannot be hijacked and sent to a fake site pretending to be your target website. You can see that the sample site does this well. Protocol Support: Protocol is the exact method they use to send information back and forth. The first accepted protocol was created in 1995, and since then they have improved security four times. The last update was in 2008. So, there are 5 possible protocols, from the very weak 1995 protocol (called SSL 2.0) to the very strong 2008 protocol called TLS 1.2. A website starts with the best one it knows, and drops back until it can agree with a client machine (your machine) on the best protocol they both know. SSL Labs subtracts points if the server does not offer to use the best protocols, or does offer the very worst. Here again, the sample server did fine. Hackers who get in between, will play dumb, and try to force the protocol to be as weak as possible. Key Exchange: The Key Exchange is when you and the server agree on a key for encrypting your communication. Once again, someone intercepting your communications and resending them will pretend stupidity and try to get the server to agree on a weak password. The server offers a good long key, and the "man in the middle" says, "oh gee, that's so long. Let's do a short simple key." If the server agrees, then they will use a short key to encrypt the communications. That means your security is compromised. This is where the sample site blew it completely. They would agree to keys which are insecure. Cipher Strength: SSL Labs checks the strength of the cipher used. Now that you and the server have agreed on a key to use to encrypt your transmissions, you must agree on an encryption method. The cipher is the method used to encrypt the data. There are lots of ways to encrypt the information, some better than others. As with the protocol, the server begins by trying the most secure cipher it knows, and works its way down until it finds one you can agree on. Again, as with the protocol, and a key, a hacker who inserted themselves between you and the server, will play dumb and say you don't know any of the good ciphers, so it is important that the server not agree to weak ones. SSL labs removes points if the server does not offer the best ciphers, or does offer the worst broken ones. Again, this medical center failed to protect you. Also, all of my doctors' offices failed this as well. Other: Finally, SSL Labs checks for known attacks and whether your site has fixed the holes in their connections to protect against known vulnerabilities. Here you will see that this massive health care provider, is open to the well known and documented BEAST attack. So, if there were a "man in the middle" between you and the Medical Center's server, as shown in the sample above, they could get the server to agree on a sub-optimal protocol, a short key, and a weak method of encryption. I wouldn't want to trust my data to them. How to run the test Be sure you go to a login page. Some companies have an insecure front page, and then move to another server for their secure login. Just go to login and copy the address. Then paste it into the Domain Name entry field at SSL Labs test page. What to do with the results I would like you to call or email any vendor you have who fails to get an A on these tests. If you score over 80, you get an A. Less than 80 is too insecure for me. Why are so many healthcare sites using weak encryption and weak keys? After World War II, England and America felt they were ahead in cryptography. They classified encryption as a munition and restricted export. They refused to allow export of any software using keys over 40 bits. 40 bits was short enough that even in the 1970s and 1980s it could be cracked easily. In 1996 President Clinton removed software from the munitions category and placed it under the commerce department, effectively removing these restrictions. However, servers still come with these cipher suites enabled. So why are so many healthcare records sites still allowing such insecure encryption technology to be used, when banks and e-commerce businesses refuse to and 12 years ago the NIST set a better standard? Apparently, they just don't know they need to remove these options from the servers they bought. Supplemental Material I have another document with supplemental material to help you. I've included my results from many tests plus an SSL timeline and two sample emails to failing vendors. Date: August 2013 This article is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.
		I attempt to provide reliable information, but make no warranty as to the accuracy or safety of these articles. I disclaim all legal responsibility for what following these instructions may do. Follow my advice at your own risk