testssl/testssl.sh

[BUG / possible BUG] JSON report should have consistent keys + values

Closed this issue · 0 comments

Quick summary:

Two changes to JSON output that could be improved for better consistency:

  • The options --server-preference vs --cipher-per-proto appear to share a similar key (supportedciphers_TLSv1_2) where the latter option lacks the v char (has instead). Both should normalize to v, spaces in field keys is not ideal.
  • For --server-preference, the cipher_order entry (and related protocol variants) should probably indicate client instead of NOT a cipher order configured for client preference, as server preference is indicated via the value of server. When the preference cannot be determined the entry is omitted (perhaps document that or include an entry with that context?).

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

GHCR.io 3.3dev image (Sep 6 2025)

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

I couldn't find anything

Command line / docker command to reproduce

testssl --quiet --server-preference --cipher-per-proto --jsonfile-pretty port_993.json mail.example.test:993

NOTE: The FQDN mail.example.test represents a service that is not running on a live server, it is fully reproducible via Docker Compose with the compose.yaml as demonstrated in the previous comment: #2883 (comment)

Expected behavior

I expected consistency in the report keys used in JSON. Instead I noticed the following:

  • --cipher-per-proto vs --server-preference (when no server cipher order detected) have two very similar cipher list keys (as detailed here):
    • --server-preference: .serverPreferences[].id === "supportedciphers_TLSv1_2"
    • --cipher-per-proto: .cipherTests[].id === "supportedciphers_TLS 1_2" (differs by TLSv1_2 vs TLS 1_2)
  • A .serverPreferences[].id === "cipher_order" entry (and related protocol variants) is missing when server/client preference is uncertain (such as when failing to negotiate and agreed cipher suite, see the last section of this comment for details).
    • Terminal output however clearly communicates this concern via reporting "unable to determine".
    • When client preference is determined it assigns the .finding field with NOT a cipher order configured (probably should be client?).
    • When server preference is determined it assigns the .finding field with server.

Your system (please complete the following information):

  • N/A (using the GHCR.io image)

Additional context

testssl.sh appears to be using a different client preference than openssl with -cipher of ALL/DEFAULT/DEFAULT@SECLEVEL=0?

  • This is not communicated in the FAQ or docs from what I can see.
  • Not knowing the client preference adds some friction to troubleshooting such issues where client preference results in different cipher suite selection than standard openssl commands (as detailed here).

EDIT: This was explained why here, testssl.sh is handling it differently, not relying on openssl -cipher like I assumed.