0

For over a year I have been running a photo based website that allows customers to order prints, which are subsequently fulfilled by a printing company. Orders are posted in XML format to a designated URL. Recently orders are not being posted and I have encountered the following error when examining the server logs:

 [Mon Dec 01 21:17:38 2014] [error] [client XXX] cURL error: [35] Cannot communicate securely with peer: no common encryption algorithm(s).

The tech team for the printing company was able to provide me with some direction, but I remain confused. Initially they informed me that the server currently supports SSLv2, SSLv3 and TLS1.0 only, and that it was likely that we only have TLS1.2 enabled on our end. They claimed that nothing was changed on their end, and I personally know that nothing has been modified on ours for months. When I originally encountered the problem I attempted to update the server packages, but this failed to resolve the problem. Later I thought that perhaps the issue revolved around the security groups for the Amazon EC2 instance, but I am not entirely sure. How would I go about enabling TLS1.0, assuming it is not already enabled? How would I check what transport layer securities and secure socket layers are currently enabled? Any other suggestions?

masegaloeh
  • 18,236
  • 10
  • 57
  • 106
panoramic
  • 21
  • 1
  • 7
  • What Linux distribution are you using? Is it up to date? – Michael Hampton Dec 10 '14 at 23:03
  • 1
    AWS security groups work at a network-level, so they are unlikely to be your problem. You can use `openssl s_client` from a shell and play with the `-tls1_2`, `-tls1_1`, etc. options to see what they actually support. – Andy Smith Dec 10 '14 at 23:05
  • @MichaelHampton NAME="Amazon Linux AMI" VERSION="2014.09" ID="amzn" ID_LIKE="rhel fedora" VERSION_ID="2014.09" PRETTY_NAME="Amazon Linux AMI 2014.09" ANSI_COLOR="0;33" CPE_NAME="cpe:/o:amazon:linux:2014.09:ga" HOME_URL="http://aws.amazon.com/amazon-linux-ami/" Amazon Linux AMI release 2014.09 – panoramic Dec 10 '14 at 23:16
  • When I initially encountered the problem I ran yum update, which should have updated all my packages correct? – panoramic Dec 10 '14 at 23:18
  • @AndySmith Once i determine what options they support how would i go about enabling those options (e.g., tls 1) on my end? – panoramic Dec 13 '14 at 23:11
  • After fiddling around I figured out how to use CURLOPT_SSLVERSION, I experimented and set it to TLSv1, SSLv2, SSLv3, TLSv1_0, but unfortunately this did not solve the problem and the same error is being produced ( cURL error: [35] Cannot communicate securely with peer: no common encryption algorithm(s).) Any other ideas? – panoramic Dec 14 '14 at 06:06

1 Answers1

1

Some versions of OpenSSL were broken in Ubuntu due to problems in OpenSSL, not Ubuntu itself and may have been broken in other distros as well, such as Amazon Linux, when connecting to an ancient server that can do no better than TLS 1.0 unless you explicitly force it, as @AndySmith was suggesting above (the openssl s_client -connect option to try to see it work from the command line, in this case, would be -tls1).

I don't see it in your question, but I assume you are using PHP. I'm no PHP expert, but it looks like your workaround might be to use CURLOPT_SSLVERSION to force CURL_SSLVERSION_TLSv1_0.

If your vendor can do no better than TLS 1.0, and (worse) still supports SSLv2 and SSLv3 they should really be embarrassed. Even the PHP docs advise against the old versions:

Your best bet is to not set this and let it use the default. Setting it to 2 or 3 is very dangerous given the known vulnerabilities in SSLv2 and SSLv3

However, I have a system that connects to an ancient load balancing hardware, and forcing TLS 1.0 is exactly what I have to do in order to make it work, even though it "should" work anyway... and it did work fine, from older versions of OpenSSL. A security update on your system might have introduced the changed behavior by updating you to a version of OpenSSL with this issue.

Michael - sqlbot
  • 22,658
  • 2
  • 63
  • 86
  • Thanks for the response Michael and @MichaelHampton . I am struggling with testing the connections from the command line and was hoping you could point out what it i i am doing wrong. After doing a little research I've found what i believe is the general format for the command, but I am receiving an error (socket: Bad file descriptor connect: errno=9). openssl s_client -connect XXX:PORT -tls1 – Initially tried the ip address and later example.com, both with port 20 and port 25. Any ideas? – panoramic Dec 12 '14 at 22:53