0

While I was searching related questions, I saw this: https://superuser.com/questions/109213/how-do-i-list-the-ssl-tls-cipher-suites-a-particular-website-offers

I tried working on the solutions provided but I haven't found my solution.

I have 2 server, the test and the production server.

Both of them host an application, test and prod. This application requires a reverse proxy so I set up Apache for this.

I was asked to improve the cipher suite used for the HTTPS.

The PROD server uses, in apache, this:

SSLProtocol All -SSLv2 -SSLv3
SSLCipherSuite DES-CBC-SHA:HIGH:!aNULL:!MD5:!EXP
SSLHonorCipherOrder on

The TEST server, which I'm currently working on, was updated for using this:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression      off
SSLSessionTickets   off

It is time to test if the new configuration works (well, it already should, but you know...).

From a 3rd TEST machine I ran:

curl https://test.servertest.com/test1
against the TEST server
and
curl https://prodserver.com/accept
to the PROD one.

Reading the APACHE error log from both the TEST and PROD servers, I do not see differences.

TEST:
[Tue Oct 23 13:57:10.846249 2018] [ssl:trace3] [pid 13130] ssl_engine_kernel.c(1795): [remote 1.1.1.1:5555] OpenSSL: Handshake: done
[Tue Oct 23 13:57:10.846257 2018] [ssl:debug] [pid 13130] ssl_engine_kernel.c(1844): [remote 1.1.1.1:5555] AH02041: Protocol: TLSv1, Cipher: ECDHE-RSA-AES256-SHA (256/256 bits)

PROD:
[Tue Oct 23 13:58:04.192403 2018] [ssl:trace3] [pid 6856] ssl_engine_kernel.c(1795): [remote 2.2.2.2:6666] OpenSSL: Handshake: done
[Tue Oct 23 13:58:04.192409 2018] [ssl:debug] [pid 6856] ssl_engine_kernel.c(1844): [remote 2.2.2.2:6666] AH02041: Protocol: TLSv1, Cipher: ECDHE-RSA-AES256-SHA (256/256 bits)

Probably CURL might not be the best way for testing the cipher suite (?) but my question is: How can I be sure that the changes I applied are correct (beside finding the ciphers suite themselves in the Apache manual) ?

3

curl -vv -k https://test.example.com will output some of useful TLS info, but will only negotiate a single protocol and cipher, rather than testing every possible and supported SSL/TLS version and cipher.

curl -vv https://test.example.com
* Rebuilt URL to: https://test.example.com/
*   Trying 10.9.8.7...
* TCP_NODELAY set
* Connected to test.example.com (10.9.8.7) port 443 (#0)
...
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384

A useful online testing tool is Qualis SSL labs https://www.ssllabs.com/ssltest/ or run your own tests using the nice wrapper script from https://testssl.sh/ around the commandline openssl tool/library.

A few simple openssl commands to test for the correct SSLProtocol level are:

 openssl s_client -connect test.example.com.com:443 -ssl3

Which is supposed to return a failure when SSLv3 is disabled with SSLProtocol -SSLv3

140304709433232:error:14094410:SSL routines:ssl3_read_bytes:
     sslv3 alert handshake failure:s3_pkt.c:1493:SSL alert number 40
140304709433232:error:1409E0E5:SSL routines:ssl3_write_bytes:
     ssl handshake failure:s3_pkt.c:659:

and similar for testing TLS protocol 1.0

 openssl s_client -connect test.example.com:443 -tls1

we should again see a handshake failure:

 routines:ssl3_read_bytes:tlsv1 alert protocol version:s3_pkt.c:1493:SSL alert number 70
 ssl handshake failure:s3_pkt.c:659:
 openssl s_client -connect test.example.com:443 -tls1_1
139920359683984:error:1409442E:SSL routines:ssl3_read_bytes:
tlsv1 alert protocol version:s3_pkt.c:1493:SSL alert number 70
ssl handshake failure:s3_pkt.c:659:

When testing the allowed TLS protocol level 1.2

  openssl s_client -connect test.example.com:443 -tls1_2

one should see a successful connection and a the details of a TLS certificate:

depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
 verify return:1
 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
 verify return:1
 depth=0 CN = test.example.com
 verify return:1
 ---
 Certificate chain
 0 s:/CN=test.example.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGFTCCBP2gAwIBAgISBEs83Gyi/cFWkX3BtmTHk3R5MA0GCSqGSIb3DQEBCwUA
...

A useful cheat sheet for good TLS settings for a number of of different servers is: https://cipherli.st/

3
  • All good info, thanks! I was trying already the curl command. From the CURL of your example and the log on my server, the cipher suite match. Means that my tests were right. What I don't understand is why both of my servers accept these HIGH ciphers, which is correct, while I was told to upgrade them on the PROD server because are weak, saying that those that I use are TLS_RSA_WITH_AES_128_CBC_SHA256. I can not see anywhere these last cipher suite used in my server(s). I just see the HIGH one. – aPugLife Oct 23 '18 at 14:45
  • Yes, checked (and done) everything that you said. It totally match with my settings. I am not sure now why I was told that my server uses those weak cipher suite while indeed it is not. I am confused. At least I know that all the tests that I have run are correct – aPugLife Oct 23 '18 at 14:47
  • I think I will accept your answer because I like how you wrote it. It's helpful. I am still confused because I do not know where this client of mine got that cipher suite list though. – aPugLife Oct 23 '18 at 14:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.