We have a client whose supported TLS 1.2 Cipher Suite is noted this format...
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
And we have the server (nginx I think?) whose supported list is in this notation...
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM
The client cannot establish the connection, so I assume the client/server do not agree on a supported Cipher. Any ideas how I can obtain a list of supported ciphers from the abbreviated server notation?
I know that EECDH is an alias for ECDHE, so I would have assumed one of these two ciphers would have matched.
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Any ideas why not?
openssl ciphers -V 'EECDH+AESGCM:EDH+AESGCM' gives you all the ciphers in OpenSSL notations. To translate this to the notation from the RFC see the mapping at the end of man ciphers. When doing this you get the following shared ciphers which you already correctly identified:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
But, these are both ECDSA ciphers so they require the server to have an ECC certificate. I assume that in your case the server has only an RSA certificate (which is still more common) so that essentially there are no shared ciphers. Instead the client would need to offer these ciphers:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA384
If your server is publicly available, head over to SSLLabs and test your server for supported cipher suites. It will give you a list in the format you require.
If you server isn't public you can do the same thing with testssl.sh.
Related
Currently on our windows server (Windows 2016 R2) , we have following cipher suites installed:-
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
Still the following security vulnerabilities are reported for our server as
TLS/SSL Birthday attacks on 64-bit block ciphers (SWEET32)
TLS/SSL Server Supports 3DES Cipher Suite <-- However there are no 3DES ciphers as listed above
TLS/SSL Server Supports The Use of Static Key Ciphers
I am using tomcat 9.0.62.
How can I fix these security vulnerabilities.
I have configured my Tomcat 8.5 cipher suites as below
<Connector
....
sslEnabledProtocols="TLSv1.2"
ciphers="
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"
... />
While testing the site with www.ssllabs.com I find strange result in Server Supported Cipher Suites section. The list is as below :
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 .... OK
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 .... WEAK
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA .... WEAK
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 .... OK
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 .... WEAK
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA .... WEAK
Where are the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 come from, I have not configure them in server.xml ?!
Is it any default list of cipher suites in tomcat ?!
When you specify ciphers, no additional ciphers will be made available, regardless of the capabilities of the cryptographic provider being used (e.g. JSSE, OpenSSL, etc.).
If you are seeing a different set of cipher suites being negotiated, I would check two things:
Your configuration is actually being used. Try adding a syntactic error to your XML configuration file to see if Tomcat still starts. Tomcat should refuse to start if the file is not well-formed, confirming that you are in fact changing the right configuration file.
If you are not directly connecting to Tomcat, you may be negotiating your TLS handshake with another network component such as a reverse proxy which is terminating TLS. If that's the case, the configuration of Tomcat is not relevant; the client is really talking to the reverse proxy and not to Tomcat, so the list of ciphers will be different as far as the client can tell. You will need to reconfigure the reverse proxy in this situation. The cipher suites list in Tomcat is still important, as you want to be using a secure cipher suite even "inside" your own network.
I am testing SSL, my use case is if the client wants to do a Renegotiation but propose different set of ciphers this time, is there a way this could be tested with openssl s_client. I know R will send a Reneg request, but how do I include Ciphers also?
Although I mention ssh-dss for HostKeyAlgorithms in /etc/ssh/ssh_config. ssh-rsa key pair can be used to login!
HostKeyAlgorithms ssh-dss
Some useful info on the above issue
In practice, a RSA key will work everywhere. ECDSA support is newer, so some old client or server may have trouble with ECDSA keys. A DSA key used to work everywhere, as per the SSH standard (RFC 4251 and subsequent), but this changed recently: OpenSSH 7.0 and higher no longer accept DSA keys by default.
My understanding is that that 3DES can be configured to use multiple modes including cipher block chaining (CBC) and electronic code book (ECB).
Does anyone know which one is used by IIS whenever 3DES is configured in the machineKey?