mozilla/cipherscan

It's not obvious which openssl was used for the scan

jensguballa opened this issue · 4 comments

It seems that for ECDH cipher suites the reported list of curves is not complete as x25519 is missing, even it this curve is supported by the server.

This can be checked e.g. against google.com (ssllabs indicates that x25519 is the preferred curve (besides secp256r1), cipherscan only reports prime256v1 in the list of curves.

My setup:
openssl version: 1.1.1c

google handling of tls versions and ciphers is very complex and it may mask some settings as unsupported

what's the exact command line you're using to test them?

Here is the command I am using:
./cipherscan -j google.com | python -m json.tool

And the output is:

{
    "ciphersuite": [
        {
            "cipher": "ECDHE-RSA-AES128-GCM-SHA256",
            "curves": [
                "prime256v1"
            ],
            "curves_ordering": "server",
            ...

Using normal output does not change anything:

./cipherscan google.com
...............
Target: google.com:443

prio  ciphersuite                  protocols              pfs                 curves
1     ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2                ECDH,P-256,256bits  prime256v1
2     ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2                ECDH,P-256,256bits  prime256v1
3     ECDHE-RSA-AES128-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits  prime256v1
4     ECDHE-RSA-AES256-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits  prime256v1
5     AES128-GCM-SHA256            TLSv1.2                None                None
6     AES256-GCM-SHA384            TLSv1.2                None                None
7     AES128-SHA                   TLSv1,TLSv1.1,TLSv1.2  None                None
8     AES256-SHA                   TLSv1,TLSv1.1,TLSv1.2  None                None
9     DES-CBC3-SHA                 TLSv1,TLSv1.1,TLSv1.2  None                None

Certificate: trusted, 2048 bits, sha256WithRSAEncryption signature
TLS ticket lifetime hint: 100800
NPN protocols: None
OCSP stapling: not supported
Cipher ordering: server
Curves ordering: server - fallback: no
Server supports secure renegotiation
Server supported compression methods: NONE
TLS Tolerance: yes

Intolerance to:
 SSL 3.254           : absent
 TLS 1.0             : absent
 TLS 1.1             : absent
 TLS 1.2             : absent
 TLS 1.3             : absent
 TLS 1.4             : absent

I compared the scan result with other tools as well, e.g. testssl.sh:

./testssl.sh  google.com
...
 Elliptic curves offered:     prime256v1 X25519 
...
    TLSv1.2:   ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256
               ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-SHA
               ECDHE-ECDSA-AES256-SHA ECDHE-RSA-CHACHA20-POLY1305
               ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384
               ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA AES128-GCM-SHA256
               AES256-GCM-SHA384 AES128-SHA AES256-SHA DES-CBC3-SHA 
...

I am also wondering why the cipher suites ECDHE-ECDSA-... are not reported by cipherscan as well. A wireshark trace confirms that google.com indeed is negotiating TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 using curve X25519 (for TLS1.2).

Ok, I was not aware that cipherscan by default is using the openssl version which is bundled with cipherscan (OpenSSL 1.0.2-chacha (1.0.2i-dev)).

I tried all commands above now with -o /usr/bin/openssl (OpenSSL 1.1.1c 28 May 2019), and now the scan result looks correct, i.e. X25519 curve and the ECDHE_ECDSA_-cipher suites are reported.

Falling into this trap I would really appreciate if the scan result would contain the openssl versions as well.

Falling into this trap I would really appreciate if the scan result would contain the openssl versions as well.

yes, logging the version of script and used openssl in the output (including json) would be a nice addition