When i run the command
nmap --script ssl-enum-ciphers hostname
I get the output of ciphers with a grade next to it. For example :
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - D
| TLS_RSA_WITH_AES_128_CBC_SHA - A
| TLS_RSA_WITH_AES_256_CBC_SHA - A
My question is What is A - D stand for ? I assume A being the highest and best. Is it right ?
Thanks
A-D stand for strength.
Using nmap (https://nmap.org) to scan SSL cipher you can see report like below:
nmap -p 443 --script ssl-enum-ciphers example.com
TLSv1.2:
ciphers:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 768) - C
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 768) - C
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 768) - B
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 768) - B
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp160k1) - A
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp160k1) - A
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp160k1) - A
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp160k1) - A
TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
compressors:
NULL
cipher preference: client
warnings:
64-bit block cipher 3DES vulnerable to SWEET32 attack
Key exchange (dh 768) of lower strength than certificate key
Key exchange (secp160k1) of lower strength than certificate key
least strength: C
See the bold text. First bold lines are ciphers with corresponding strength. And last bold line is summary strength based on minimum ciphers strength.
Related
I'm trying to get a comprehensive list of all supported ciphers suites by BoringSSL. I didn't find that in the docs.
Looking into the source I found the file ssl_cipher.cc and the constant SSL_CIPHER with the IANA names of ciphers:
TLS_RSA_WITH_NULL_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_PSK_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA
TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
Are those all the supported ciphers?
I have Java TLS server and have switched from the original SunJSSE provider to BCJSSE (BouncyCastle JSSE FIPS, v1.0.10).
Now if someone tries to query my server with nmap -sT -Pn --script ssl-cert,ssl-enum-ciphers -p , ciphers having enabled DHE key exchange algorithm were shown and the handshake was successful:
ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
Having the BCJSSE provider, which claims to support the above DHE ciphers, nmap returns:
ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
When running:
openssl s_client -tls1_2 -cipher DHE-RSA-AES128-CCM -connect <host> <port>
actually the handshake is successful with the DHE ciphers. However, running curl, compiled with the very same version of openssl:
curl -vvv -k https://<host>:<port>--tlsv1.2 --ciphers DHE-RSA-AES128-CCM -u <user>:<pass> -c /tmp/cookie
the result is:
* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
The old crypto provider used to handshake successfully for each of the supported ciphers (not the last one which is available only in BC).
The BCJSSE documentation says:
Cipher suite name: TLS_DHE_RSA_WITH_AES_128_CCM
FIPS mode: N
which I interpret as supported.
So, does anyone knows why there is a difference between the nmap outputs and how it is possible to have a successful handshake with s_client but curl refuses to establish such a secure connection. And is there something particular to be fixed here and how, or this might be considered as expected behavior?
For some demonstration on HTTPS weakness, I'd like to enable SSLv3 on one sub domain of my webserver. I use nginx 1.12.2 on debian 8, and already tried to add the following line
ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
and then a sudo service nginx restart, but ssllabs still shows SSL as disabled (with the clear-cache option).
Apparently the version of openssl I have supports SSLv3 (openssl ciphers -v), so I don't understand why SSLv3 isn't enabled.
Thanks !
Try this command to compare with SSLLabs result :
openssl s_client -ssl3 -connect youserver:443
If the handshake is OK, you probably need to configure the cipers in the NGINX config.
With new versions of openssl, configurations goes in exclusion-way. You can use this command to test SSLv3 protocol
openssl s_client -connect youserver:443 -no_tls1_2 -no_tls1_1 -no_tls1
But the best way to ensure wich versions of SSL/TLS are working on the remote werver is using NMAP:
nmap -sV --script ssl-enum-ciphers -p 443 youserver
Nmap output will point you in the right direction, because it describes the version working protocols and every available cipher.
PORT STATE SERVICE VERSION
443/tcp open ssl/https nginx
|_http-server-header: nginx
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| Key exchange (dh 1024) of lower strength than certificate key
| TLSv1.1:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| Key exchange (dh 1024) of lower strength than certificate key
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| Key exchange (dh 1024) of lower strength than certificate key
|_ least strength: A
Hope that helps
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
I have a site https://warsoftheheroes.eu/ which is hosted using Apache with SSL with Let's Encrypt certyficate. In Chrome/Chromium browser in developer tools -> security I see this message:
Obsolete Connection Settings
The connection to this site uses a strong protocol (TLS 1.2), an obsolete key exchange (RSA), and a strong cipher (AES_128_GCM).
and here is my Apache SSL configuration:
<IfDefine SSL>
<IfDefine SSL_DEFAULT_VHOST>
<IfModule ssl_module>
Listen 443
<VirtualHost _default_:443>
ServerName localhost
Include /etc/apache2/vhosts.d/default_vhost.include
ErrorLog /var/log/apache2/ssl_error_log
<IfModule log_config_module>
TransferLog /var/log/apache2/ssl_access_log
</IfModule>
SSLEngine on
SSLProtocol ALL -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:HIGH:!RC4:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK
SSLHonorCipherOrder On
SSLCertificateFile /home/wof/ssl/fullchain1.pem
SSLCertificateKeyFile /home/wof/ssl/privkey1.pem
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory "/var/www/localhost/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
<IfModule setenvif_module>
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</IfModule>
<IfModule log_config_module>
CustomLog /var/log/apache2/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</IfModule>
</VirtualHost>
</IfModule>
</IfDefine>
</IfDefine>
# vim: ts=4 filetype=apache
What should I change in this config file to get rid of this obsolete key exchange?
According to the SSLLabs test your site does not support any ECDHE ciphers, even if it looks like that you have configured these ciphers in your server configuration. Since TLS 1.2 support (which you have) and ECDHE support (which you don't have) got both added within OpenSSL 1.0.1 my guess is that you have a version of OpenSSL which is compiled without support for ECC (and thus ECDHE).
As far as I know older versions of RHEL (and thus CentOS too) and Fedora got shipped with ECC support removed for patent reasons so you might check if you are using one of the affected systems. The output of openssl ciphers -V gives you which ciphers are supported and you should check if ECDHE is supported there.
Sorry for my mistake earlier. Mixed some things up.
This is how to see what ciphers are supported on a server and in what order they are preferred:
nmap --script ssl-enum-ciphers -p 443 warsoftheheroes.eu
Starting Nmap 7.40 ( https://nmap.org ) at 2017-05-10 17:23 CEST
Nmap scan report for warsoftheheroes.eu (81.163.204.80)
Host is up (0.051s latency).
rDNS record for 81.163.204.80: pppoe-static-a-80.interblock.pl
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.1:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A
As you can see, the third option for TLSv1.2 is TLS_RSA_WITH_AES_128_GCM_SHA256 which is part of 'AES128' that you have enabled in your configuration.
Steffen Ullrich is probably right about the missing ECDHE support, which is probably why the cipher with RSA Key Exchange is at third position. I think the ECDHE ciphers would be preferred if they were supported.
I have 2 seemingly identical glassfish installations (installed using the same installer, same OS - SLES 11 SP2 - with the same installed packages and updates, same JRE/ JDK, same web applications deployed in the same way, similar keystores - different PKs, same method of getting/ signing, etc.), however, the two installations have 2 different sets of available ciphersuites. I believe that this is causing Server A to give a "Server has a weak, ephemeral Diffie-Hellman public key" error when visiting the application.
Server A:
Available Common Ciphersuites:
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
Available Ephemeral Diffie-Hellman Ciphersuites:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Available 40 bit and 56 bit Ciphersuites:
SSL_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DES_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
Available ECC Ciphersuites:
none
Server B:
Available Common Ciphersuites:
TLS_RSA_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_RC4_128_MD5
Available Ephemeral Diffie-Hellman Ciphersuites:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Available 40 bit and 56 bit Ciphersuites:
none
Available ECC Ciphersuites:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
What could be causing this difference in available ciphersuites?
It turns out that asenv.conf ({glassfish installation}/config/asenv.conf) was defining AS_JAVA=... and glassfish was using this instead of the version of java defined in the path and JAVA_HOME. Pointing AS_JAVA to the correct jre solved the issue.