Daniel Nashed's Blog

TLS/SSL Cipher Troubleshooting

Every Domino release adds more TLS ciphers to the weak list to ensure poper security. We can expect the next versions also to have less ciphers available.
Domino ensures for clients and servers, that the list of ciphers provided is safe. In addition the default behavior is that the server decides the order of ciphers to pick.
And only allows secure renegotiation to prevent the client to pick a less secure cipher.

Usually this doesn't cause a lot of trouble for inbound connections. Modern browsers support modern ciphers. But outgoing connections for LDAP and ICAP could be a challenge.
I had to look into an ICAP connection problem this week. To demonstrate how the TLS handshake works, I wrote a small OpenSSL demo program in C. This turned into a quite flexible troubleshooting tool over the weekend.

The tool is currently only available for Linux, because you need a compiler and to link with OpenSSL. Also the SSL version needs to match or run-time environment. On Linux everything is included and you just have to compile and link the code.

nshciphers comes with a client and a server mode. You can specify ciphers by standard name, OpenSSL name and well defined cipher number (even in combination). You can also map cipher names.

The source code could be useful to understand how applications use the cipher string (e.g. NGINX, Apache and others).
On the server side you see configured ciphers, client requested ciphers and the finally selected cipher and TLS version.

I created a new nsh-tools GitHub repository -> https://github.com/nashcom/nsh-tools/tree/main/nshcipher

The tool can also map cipher codes and names into a cipher list, which could be convenient if you want to configure an NGINX cipher list.
If you don't specify any ciphers, the client will iterate all TLS 1.0 and TLS 1.2 ciphers and test the server side for configured ciphers.

There are other tools like https://github.com/drwetter/testssl.sh or scanssl. Those those tools also provide much more detailed output.
But this might be still easier to use, with a simple approach to map and request ciphers. The server mode is probably the more interesting part.


Example: Server Side

./bin/nshciphers -s -cert /mnt/d/rsa_cert.pem -key /mnt/d/rsa_key.pem  -cipher C030:9F:C02F:9E:C028:6B:C027:67

Configured Ciphers:

------------------------------------------
C030, TLSv1.2, ECDHE-RSA-AES256-GCM-SHA384   , TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
C02F, TLSv1.2, ECDHE-RSA-AES128-GCM-SHA256   , TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
C028, TLSv1.2, ECDHE-RSA-AES256-SHA384       , TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
006B, TLSv1.2, DHE-RSA-AES256-SHA256         , TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
C027, TLSv1.2, ECDHE-RSA-AES128-SHA256       , TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
------------------------------------------
Total: 5


OpenSSL Cipher String
------------------------------------------
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES128-SHA256


Listening on [localhost:443] ...


Ciphers requested by client: 4
------------------------------------------
C030, TLSv1.2, ECDHE-RSA-AES256-GCM-SHA384   , TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
C02F, TLSv1.2, ECDHE-RSA-AES128-GCM-SHA256   , TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
C028, TLSv1.2, ECDHE-RSA-AES256-SHA384       , TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
C027, TLSv1.2, ECDHE-RSA-AES128-SHA256       , TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Connected with cipher:
------------------------------------------
0xC030, TLSv1.2, ECDHE-RSA-AES256-GCM-SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384



Example: Client Side

/bin/nshciphers -c 127.0.0.1 -cipher C030:C02F:C028:C027

Connected with cipher:
------------------------------------------
0xC030, TLSv1.2, ECDHE-RSA-AES256-GCM-SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384


Example: curl

When connecting via curl, the server side also returns the TLS version and cipher.

curl -k https://127.0.0.1
You are connected with: TLSv1.2, 0xC030, ECDHE-RSA-AES256-GCM-SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• Comments [0]