[possible BUG] Testing usgodae.org:443 only succeeded using testssl.sh-3.2.2/bin/openssl.Linux.x86_64 / bash sockets needed

[gregoryR]

Before you open an issue please check which version you are running and whether it is the latest in stable / dev branch

I am running version testssl.sh version 3.2.2 from https://testssl.sh/

Before you open an issue please whether this is a known problem by searching the issues

couldn't find anything

Command line / docker command to reproduce

testssl.sh -S usgodae.org:443

Expected behavior

No warning shown

Your system (please complete the following information):

• OS: Debian GNU/Linux 10 (buster)
• Platform: Linux 4.19.0-27-amd64 x86_64
• OpenSSL + bash: Using OpenSSL 1.0.2-bad (Mar 28 2025) [~179 ciphers] / Using bash 5.0.3

Additional context

A warning asking for report is shown on usgodae.org:443

This shouldn't happen (pls report): Testing usgodae.org:443 only succeeded using /usr/local/src/testssl.sh-3.2.2/bin/openssl.Linux.x86_64.
But testssl.sh also needs bash sockets to perform its checks correctly.

I can see a pre-test bug

128 cipher limit bug

Can you reproduce ?

The complete test

$ testssl.sh -S usgodae.org:443

#####################################################################
  testssl.sh version 3.2.2 from https://testssl.sh/

  This program is free software. Distribution and modification under
  GPLv2 permitted. USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

  Please file bugs @ https://testssl.sh/bugs/
#####################################################################

  Using OpenSSL 1.0.2-bad (Mar 28 2025)  [~179 ciphers]
  on lucie:/usr/local/src/testssl.sh-3.2.2/bin/openssl.Linux.x86_64

 Start 2025-12-05 06:48:51        -->> 199.9.2.160:443 (usgodae.org) <<--

 rDNS (199.9.2.160):     nrlgodae1.nrlmry.navy.mil.
This shouldn't happen (pls report): Testing usgodae.org:443 only succeeded using /usr/local/src/testssl.sh-3.2.2/bin/openssl.Linux.x86_64.
But testssl.sh also needs bash sockets to perform its checks correctly.

You can try to continue using the --ssl-native option but the results are likely not complete.
Or you can restart using --ssl-native with another openssl version (--openssl <PATH>).
 Type "yes" to proceed and accept false negatives or positives --> yes
 Service detected:       HTTP
 Pre-test: 128 cipher limit bug

 Testing server defaults (Server Hello) 

 TLS extensions (standard)    "server name/#0" "EC point formats/#11" "extended master secret/#23" "renegotiation info/#65281"
 Session Ticket RFC 5077 hint no -- no lifetime advertised
 SSL Session ID support       yes
 Session Resumption           Tickets no, ID: yes
 TLS clock skew               Random values, no fingerprinting possible 
 Client Authentication        none
 Signature Algorithm          SHA384 with RSA
 Server key size              RSA 2048 bits (exponent is 65537)
 Server key usage             Digital Signature, Key Encipherment
 Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
 Serial                       37FAE004371A1EA0B04672928980F6D5 (OK: length 16)
 Fingerprints                 SHA1 EC256F5B690BF7C9DF869D81DE0CEBEF05531491
                              SHA256 4409F94A15C8D8B27477057F0B50F4B360AF744411B5117357DBF4E59DE66873
 Common Name (CN)             usgodae.org 
 subjectAltName (SAN)         usgodae.org www.usgodae.org 
 Trust (hostname)             Ok via SAN and CN (same w/o SNI)
 Chain of trust               NOT ok (chain incomplete)
 EV cert (experimental)       no 
 Certificate Validity (UTC)   110 >= 60 days (2025-03-25 00:00 --> 2026-03-25 23:59)
 ETS/"eTLS", visibility info  not present
 Certificate Revocation List  http://crl.sectigo.com/EntrustOVTLSIssuingRSACA2.crl
 OCSP URI                     http://ocsp.sectigo.com
 OCSP stapling                not offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    not offered
 Certificate Transparency     yes (certificate extension)
 Certificates provided        1
 Issuer                       Entrust OV TLS Issuing RSA CA 2 (Entrust Limited from CA)
 Intermediate Bad OCSP (exp.) Ok



 Done 2025-12-05 06:51:30 [ 166s] -->> 199.9.2.160:443 (usgodae.org) <<--

[drwetter]

Can reproduce it, thanks!

[dcooper16]

I did some testing, and it seems this server fails if the ClientHello contains more than 125 ciphers. Removing 3 ciphers from TLS12_CIPHER seemed to fix the problem for this server.

As far as I can tell, changing the size of TLS12_CIPHER is all that is needed for testssl.sh to work with this server. Since it supports several ciphers from TLS12_CIPHER, TLS12_CIPHER_2ND_TRY isn't needed. There are several functions that break up the set of cipher suites into lists of at most 128. However, since these functions try to break the lists into evenly sized bundles, and etc/cipher-mapping.txt has 359 non-SSLv2 ciphers, the bundle sizes tend to be 120 or less.

We could easily modify testssl.sh to work with servers like this. Move a few ciphers from TLS12_CIPHER and TLS12_CIPHER_2ND_TRY to TLS12_CIPHER, TLS12_CIPHER_3RD_TRY, and change a few functions that break cipher lists into bundles of at most 128 to break them into bundles of at most 124. Of course, there is always the chance that in the future some server will be encountered that has an even smaller cipher size limit.

[drwetter]

Regarding the effort / code change we'd put into this: As I lack statistics I don't know much of an edge case this is?

If we can move ciphers and reduce the bundles to a value <=124 that would help here though.

Of course, there is always the chance that in the future some server will be encountered that has an even smaller cipher size limit

I guess an elegant way of making the bundle sizes flexible, like with an environment variable, is not as easy possible.

[dcooper16]

PR #2963 should fix the issue for this server. The main change it makes is that the TLSv1.2 ciphers are now evenly split between TLS12_CIPHER, TLS12_CIPHER_2ND_TRY, and TLS12_CIPHER_3RD_TRY (117 each) rather than the first two having 127 each and TLS12_CIPHER_3RD_TRY having a smaller number.

I did not change the maximum bundle size in multiple functions from 128 to 125, since these functions create bundles of equal size, and so already create bundle sizes of less than 125 in practice.

PR #2963 also changes a few other places where tls_sockets() was being called with more than 124 ciphers. (The change to run_cipherlists() results in testssl.sh correctly detecting that usgodae.org uses obsoleted CBC ciphers.)

While usgodae.org does not support TLSv1.1 or earlier, I modified run_beast() so that any places that references $SERVER_SIZE_LIMIT_BUG does not send a ClientHello with more than 124 ciphers. I am unclear, however, about the logic for limiting the number of ciphers in the BEAST test.

It's not clear to me from #189 whether the 128 cipher limit bug affects all TLS versions or only TLSv1.2. When $SERVER_SIZE_LIMIT_BUG is true, cipher_pref_test() limits the number of ciphers in TLSv1.2 ClientHello messages, but will send TLSv1.1 and earlier ClientHello messages with more than 128 ciphers. However, run_beast() limits the number of ciphers in the ClientHello when $SERVER_SIZE_LIMIT_BUG is true even though it only sends SSLv3 and TLSv1.0 ClientHello messages.