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.
Related
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.
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?
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?
We've been having issues getting a successful SSL connection from a client app trying to connect using wininet on windows xp sp3 (ie v6). The client hello looks off to me, why would the hello state its version as SSL 2.0 and then state the handshake version as SSL 3.0? Is there something coded incorrectly from the app using wininet?
SSLv2 Record Layer: Client Hello
[Version: SSL 2.0 (0x0002)] <---------------------
Length: 76
Handshake Message Type: Client Hello (1)
Version: SSL 3.0 (0x0300) <---------------------
Cipher Spec Length: 51
Session ID Length: 0
Challenge Length: 16
Cipher Specs (17 specs)
Challenge
SSLv3 and TLSv1.x have a compatibility mode in case the client also supports v2 servers, as described in the TLS specification (Backward Compatibility With SSL).
Some clients support this. For example Oracle/Sun Java has an SSLv2Hello pseudo-protocol, which uses SSLv2 Hello, but doesn't actually support SSLv2.
I know this issue is solved but I will share some more info about the subject which may be useful for viewers
"The client sends a SSLv2 ClientHello so that a server who understands only SSLv2 can process that message, and continue with a SSLv2 handshake. But the SSLv2 ClientHello also says "by the way, I know SSLv3, so if you know SSLv3 too, let's do SSLv3 instead of SSLv2", which is what usually happens (servers who know only of SSLv2 are extremely rare nowadays)."
I took it from Thomas Pornin's comment, link
https://security.stackexchange.com/questions/34827/why-clients-offer-handshaking-with-ssl-2-0-protocol