As we’ve upgraded a lot of our servers to openssl 1.0.1e we’ve seen a handful of problems with APIs or payment gateways. The companies whose API is being used say they don’t support openssl 1.0.1e and/or TLSv1.2 is not support and the server will have to use TLSv1.0. There seems to be a lot of confusion about openssl versions, TLS versions, and how they work. This blog post will clear up the confusion and help explain how to deal with APIs that are having problems.
What is TLS?
Transport Layer Security (TLS) is a protocol to allow two computers to communicate securely over the internet using encryption. It is frequently called Secure Sockets Layer (SSL) and the two terms are used interchangeably by lots of people.
What is openssl?
openssl is an implementation of the TLS protocol which is very popular with Linux distros. There are other implementations of the TLS protocol: NSS is used by Firefox and Thunderbird, Secure channel (SChannel) is used by Microsoft.
Why does using TLSv1.2 or openssl 1.0.1e break stuff?
Before a client and server can communicate securely, they negotiate some stuff like what version of the TLS protocol to use, what cipher to use for encryption, etc. When a client connects to a server, the first thing it tells it is the highest version of the TLS protocol it can support. The server then responds with the highest version of the TLS protocol it can support. They then communicate with one another using the highest version of the TLS protocol they both support. So if the client supports TLSv1.2, but the server only supports TLSv1.0 they will communicate using TLSv1.0. The problem we see is when we connect to a server and tell it we support TLSv1.2, the other server will simply close the connection with no response to us what version of TLS they support. We’ve generally found this happens due to an out of date hardware load balancer or firewall device in front of the other server that is easily fixed by applying the latest updates from the manufacturer.
The other problem we’ve seen is when we make an initial connection to the other server and send a longer list of encryption ciphers than they’re used to seeing. This is caused by an out of date F5 BigIP hardware load balancer in front of the other server. The following links have more info on the problem and how to fix it: https://www.imperialviolet.org/2013/10/07/f5update.html and http://support.f5.com/kb/en-us/solutions/public/14000/700/sol14758.html
What should I do if I am having problems or suspect problems might be related to TLSv1.2 or openssl 1.0.1e
Put the API’s URL in https://www.ssllabs.com/ssltest/ . Make sure you use the API’s URL, not the company’s main website. The website might be example.com but of their API is at api.example.com, then you need to run the test on api.example.com . You’ll want to look for “Long handshake intolerance” and “TLS version intolerance” in “Protocol Details”. If you see the API is intolerant to long handshakes or TLSv1.2, you should contact the company whose API you are using and send them the ssllabs link and a link to this blog posting. If you are a Nexcess customer, feel free to contact support and we can help diagnose the issue for you.
While the company is looking in to the problem on their end, they will probably tell you to use TLSv1.0 for the short term. You will have to modify the source code of whatever is communicate with their API to force it to use TLSv1.0. There are various guides online: https://stackoverflow.com/questions/18191672/php-curl-ssl-routinesssl23-get-server-helloreason1112 https://stackoverflow.com/questions/4721788/making-soap-call-in-php-and-setting-ssl-version
Is a website or API insecure if it doesn’t support TLSv1.2?
No. TLSv1.0 is still a secure protocol, websites which only support TLSv1.0 are still secure and PCI compliant.
