[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-preferencevs--cipher-per-protoappear to share a similar key (supportedciphers_TLSv1_2) where the latter option lacks thevchar (hasinstead). Both should normalize tov, spaces in field keys is not ideal. - For
--server-preference, thecipher_orderentry (and related protocol variants) should probably indicateclientinstead ofNOT a cipher order configuredfor client preference, as server preference is indicated via the value ofserver. 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:993NOTE: 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-protovs--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 byTLSv1_2vsTLS 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
.findingfield withNOT a cipher order configured(probably should beclient?). - When server preference is determined it assigns the
.findingfield withserver.
- Terminal output however clearly communicates this concern via reporting
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.