JDK 11 and some Cipher Suite are not working that are configured in conf/server.xml but it does not work - ssl

I have configured 4 ciphers in server.xml file as following but ONLY 2 RSA are working and ECDHE_ECDSA does not work. I have scan tomcat with multiple tools only RSA are showing in all.
How can I make TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 work ?
<Connector port="${tomcat.secure.port}" protocol="org.apache.coyote.http11.Http11NioProtocol"
address="${tomcat.address}" maxThreads="150" SSLEnabled="true"
scheme="https" secure="true" maxSwallowSize="-1" maxPostSize="-1">
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" readTimeout="50000" streamReadTimeout ="-1" streamWriteTimeout="-1"
overheadContinuationThreshold="0" overheadDataThreshold="0" overheadWindowUpdateThreshold="0"/>
<SSLHostConfig protocols="TLSv1.2+TLSv1.3"
ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256">
<Certificate certificateKeystoreFile="/tmp/tomcat_keystore.jks"
certificateKeystorePassword="${keystore.password}"
certificateKeyPassword="${key.password}"
certificateKeystoreType="PKCS12"
certificateKeystoreProvider="SUN"/>
</SSLHostConfig>
</Connector>
APACHE TOMCAT/9.0.53
java --version
openjdk 11.0.11 2021-04-20
OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2.14.04)
OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2.14.04, mixed mode, sharing)
Scan Result:
nmap --script ssl-enum-ciphers -p 443 10.40.43.26
Starting Nmap 7.92 ( https://nmap.org ) at 2022-01-28 18:08 PST
Nmap scan report for vd (10.40.43.26)
Host is up (0.021s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: A
sslscan 10.40.43.26:443
Version: 2.0.11-static
OpenSSL 1.1.1m 14 Dec 2021
Connected to 10.40.43.26
Testing SSL server 10.40.43.26 on port 443 using SNI name 10.40.43.26
SSL/TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0 disabled
TLSv1.1 disabled
TLSv1.2 enabled
TLSv1.3 disabled
TLS Fallback SCSV:
Server supports TLS Fallback SCSV
TLS renegotiation:
Session renegotiation not supported
TLS Compression:
OpenSSL version does not support compression
Rebuild with zlib1g-dev package for zlib support
Heartbleed:
TLSv1.2 not vulnerable to heartbleed
Supported Server Cipher(s):
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253
SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength: 2048
Update:
You must set up multiple types of certificates for tomcat and all four ciphers worked.
<SSLHostConfig protocols="TLSv1.2+TLSv1.3"
ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256">
<Certificate certificateKeystoreFile="/tmp/RSA/tomcat_keystore.jks"
certificateKeystorePassword="${keystore.password}"
certificateKeyPassword="${key.password}"
certificateKeystoreType="PKCS12"
certificateKeystoreProvider="SUN" type="RSA"/>
<Certificate certificateKeystoreFile="/tmp/ECC/tomcat_keystore.jks"
certificateKeystorePassword="${keystore.password}"
certificateKeyPassword="${key.password}"
certificateKeystoreType="PKCS12"
certificateKeystoreProvider="SUN" type="EC"/>
</SSLHostConfig>

ECDSA ciphers require that the server has an ECC certificate. It is likely that you have only a RSA certificate though (which is the common case), which means that ECDSA ciphers will not be supported even if they are configured.

Related

Needs clarification about Nmap and OpenSSL results

I have configured the below cipher list in Apache's ssl.conf file. And my application is running on RHEL 8.5 OS with OpenSSL version 1.1.1k.
SSLCipherSuite ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES256-CCM:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305
I'm running the below Nmap command to test the strength of the cipher suites which I used in my application,
nmap -sV --script ssl-enum-ciphers -p 8443 <IP_ADDRESS>
Please find the below output snippet.
TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: A
And I knew that the certificates which I used in the application are signed with RSA. so it displays the ciphers which are having RSA authentication.
Also, When I try to execute the below command, I got "error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40" error.
openssl s_client -connect XX.XX.XX.XX:8443 -cipher ECDHE-RSA-CHACHA20-POLY1305
My queries,
Why "ECDHE-RSA-CHACHA20-POLY1305 and DHE-RSA-AES256-CCM" are not displayed by Nmap command even though they have RSA authentication?
Why the handshake failure happened with that cipher?
Thanks.

Go https client issue - remote error: tls: handshake failure

I am hitting this error 'remote error: tls: handshake failure':
~/go/bin/aci-tls 10.0.0.201 user pass
2016/12/20 18:12:04 post error: Post https://10.0.0.201/api/aaaLogin.json: remote error: tls: handshake failure
Code is basic HTTPS client: https://play.golang.org/p/cqPT0oR__q
OpenSSL is happy with this https server:
$ openssl s_client -connect 10.0.0.201:443
(snip)
SSL handshake has read 1383 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
(snip)
Tested on:
$ go version
go version go1.7.4 linux/386
C:\>go version
go version go1.7.4 windows/amd64
gotlsscan says:
lab#ubu:~$ go version
go version go1.8beta2 linux/386
lab#ubu:~$ ~/go/bin/gotlsscan -host 10.0.0.201 | grep -v NOT
Testing SSL30 (DISABLED)
Testing TLS1.0
Testing TLS1.1
Testing TLS1.2
lab#ubu:~$
lab#ubu:~$ ~/go/bin/gotlsscan -insecure -host 10.0.0.201 | grep -v NOT
Testing SSL30 (DISABLED)
Testing TLS1.0
Testing TLS1.1
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA [OK]
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA [OK]
Testing TLS1.2
How can I further troubleshoot this issue?
The server for some reason doesn't accept the TLS1.2 handshake, nor does it properly fall back to TLS1.1. You can force the client to use only TLS1.1 and the compatible cipher suites with
cfg := &tls.Config{
CipherSuites: []uint16{
tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
},
PreferServerCipherSuites: true,
InsecureSkipVerify: true,
MinVersion: tls.VersionTLS11,
MaxVersion: tls.VersionTLS11,
}

How to disable TLS 1.0 in NGINX?

On the server level in nginx.conf I have:
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers '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-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
but no matter what when I run:
openssl s_client -connect www.example.com:443 -tls1
I get a valid connection for TLS 1.0. SSLLabs puts the nginx setup for the site as an A but with TLS 1.0 .
root#qa-ebd:~# openssl version -a
OpenSSL 1.0.2j 26 Sep 2016
built on: reproducible build, date unspecified
platform: linux-x86_64
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: gcc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
OPENSSLDIR: "/usr/local/openssl"
root#qa-ebd:~#
root#qa-ebd:~#
root#qa-ebd:~# nginx -V
nginx version: nginx/1.10.2
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
built with OpenSSL 1.0.1f 6 Jan 2014
TLS SNI support enabled
configure arguments: --prefix=/opt/nginx --with-http_ssl_module --with-http_geoip_module --with-http_gzip_static_module --with-http_stub_status_module --with-pcre
Open nginx configuration file (/etc/nginx/nginx.conf) and add below line in http section :
ssl_protocols TLSv1.1 TLSv1.2;
This will disable TLS1.0 for all applications in that server. You can test with the following openssl command:
openssl s_client -connect example.com:443 -tls1
You should be getting output something like :
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
The following worked for me:
Since my nginx server hosted 3 applications, I had to set
ssl_protocols TLSv1.1 TLSv1.2;
in each of the applications.
The change will not be reflected if this is specified in the particular application that is under consideration. Instead, changing it in all the applications running on that server will be the solution. After this, the following error will be received when TLSv1.0 handshake is negotiated with the server.
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1526041526
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

How should I proceed with upgrading to TLS 1.2?

EDIT: We have gotten a new server with updated openssl and are all set, so I'm voting to close this question.
We got this email from Authorize.NET about some technical updates. I am trying to figure out what needs to be done, but my skills are lacking in this area and I could use some help. They had four main points in their email:
After the update is complete on September 21st, any website or payment solution that connects via api.authorize.net that cannot validate SHA-2 signed certificates will fail to connect to Authorize.Net's servers.
Our server uses SHA-1, but we have a GoDaddy Certificate Installed that uses SHA-2.
In October of this year, due to system updates, it will be possible to receive Authorize.Net IDs (Transaction ID, Batch ID, etc.) that are not in sequential order.
I don't think this one will affect us.
As you may already be aware, new PCI DSS requirements state that all payment systems must disable TLS 1.0 by June 30, 2016. To ensure that we are compliant ahead of that date, we will be disabling TLS 1.0 first in the sandbox environment and then in our production environments. Both dates are still to be determined, but please make sure your solutions are prepared for this change as soon as possible.
I know we will need to upgrade OpenSSL on our server. This is what we currently have...
Current Version Recommended Depends On
TLS 1.0 1.2
OpenSSL 0.9.8h 1.0.1
PHP 5.2.6 5.6 Open SSL 1.0.1
Apache 2.2.10 2.4
Linux OS SUSE Enterprise SUSE Enterprise
Server 11 Server 12
Drupal 6.9 7.39 Mysql 5.0.15/PHP 5.4
MySQL 5.0.67 5.6 SUSE Enterprise Server 12 (x86_64)
phpMyAdmin 3.3.3 4.4.14.1 PHP 5.3.7/MySQL 5.5
How should I proceed with upgrading to TLS 1.2?
To meet the technical requirements, its sufficient to use either OpenSSL 1.0.1 or 1.0.2. Both provide TLS 1.2, and both trivially provide SHA-256. (There are other hidden fulfillments, like OpenSSL 1.0.0 does not provide the full compliment of EC gear and the full compliment of TLS 1.2 cipher suites, but 1.0.1 and 1.0.2 does).
In your C-Code that uses OpenSSL, all you need to do for the SSL Context or Session:
/* Useless return value ??? */
SSL_library_init();
const SSL_METHOD* method = SSLv23_method();
if(NULL == method) handleFailure();
SSL_CTX* ctx = SSL_CTX_new(method);
if(ctx == NULL) handleFailure();
/* Cannot fail ??? */
const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | \
SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1 | SSL_OP_NO_COMPRESSION;
SSL_CTX_set_options(ctx, flags);
For Apache-like server configurations, use something like the following (mine includes +TLSv1 +TLSv1.1):
# From my CentOS production server
SSLProtocol -all +TLSv1.2
You should probably tend to cipher suites, too. For that, in C-code:
const char CIHPHER_LIST[] = "HIGH:!aNULL:!RC4:!MD5"
/* Ensure at least one cipher suite is added, which indicates non-failure */
int rc = SSL_CTX_set_cipher_list(ctx, CIHPHER_LIST);
if(!(rc >= 1)) handleFailure();
And in an Apache-like configuration file:
# From my CentOS production server
SSLCipherSuite HIGH:!aNULL:!MD5:!RC4
If you want to avoid RSA key transport (TLS 1.3 is removing it), then:
SSLCipherSuite HIGH:!aNULL:!MD5:!RC4:!kRSA
When you remove RSA key transport, you are pretty much left with ephemeral key exchange protocols (modulo cipher suites like PSK and SRP).
If you want to explicitly use ephemeral key exchanges, then you will need something like kEECDH:kECDHE:kDHE:kEDH:!aNULL. See openssl ciphers(1) man page for more details.
I'm reading between the lines, but the TLS 1.2 requirement probably has something to do with authenticated encryption, and modes of operation like GCM. For that, use openssl ciphers(1) again:
$ openssl ciphers -v 'HIGH:!aNULL' | grep GCM
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
Or:
$ openssl ciphers -v 'HIGH:!aNULL' | grep GCM | grep -v "Kx=RSA" | cut -d " " -f 1
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
DHE-DSS-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
ECDH-RSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
DHE-DSS-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
ECDH-RSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-GCM-SHA256
Instead of specifying HIGH:!aNULL:!MD5:!RC4:!kRSA, you can do the following:
const char CIPHER_LIST[] =
"ECDHE-RSA-AES256-GCM-SHA384:"
"ECDHE-ECDSA-AES256-GCM-SHA384:"
"DHE-DSS-AES256-GCM-SHA384:"
"DHE-RSA-AES256-GCM-SHA384:"
"ECDH-RSA-AES256-GCM-SHA384:"
"ECDH-ECDSA-AES256-GCM-SHA384:"
"ECDHE-RSA-AES128-GCM-SHA256:"
"ECDHE-ECDSA-AES128-GCM-SHA256:"
"DHE-DSS-AES128-GCM-SHA256:"
"DHE-RSA-AES128-GCM-SHA256:"
"ECDH-RSA-AES128-GCM-SHA256:"
"ECDH-ECDSA-AES128-GCM-SHA256:"
/* Ensure at least one cipher suite is added, which indicates non-failure */
int rc = SSL_CTX_set_cipher_list(ctx, CIPHER_LIST);
if(!(rc >= 1)) handleFailure();
If you look at the AES256-GCM-SHA384 cipher suite, you'll see uses key transport (Kx=RSA), so you may want to avoid it even though its TLS 1.2. Hece the reason for the grep -v on it.
For completeness, Au=RSA is fine. It just means the server uses its RSA key for signing only. And in practice, Au=DSS is rarely used, so OpenSSL will remove the cipher suite if there's no DSS key.
Now, the hardship is probably getting a distro that provides the latest OpenSSL 1.0.2 and provides the long term support. My CentOS machines don't provide it, so I have to build it from sources, and then rebuild every library or program that depends upon OpenSSL while playing those stupid r-path games.
In your case, that looks like Apache, PHP, Drupal, MySQL, phpAdmin (does anyone really use that when security is a concern :) and friends.

Why can I connect TLSv1 if OpenSSL only support SSLv2 and SSLv3?

I am using openssl-0.9.8e-7.el5.
openssl ciphers -v shows support only for SSLv2 and SSLv3 cipher types.
However, if I test this connection using tls 1.0 it connects successfully:
openssl s_client -connect hostname:15000 -tls1
CONNECTED(00000003)
SSL handshake has read 2136 bytes and written 413 bytes
...
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
How does it show Protocol is TLSv1 yet OpenSSL itself only supports SSL 3 and 2?
SSLv3 cipher suites are usable with protocol versions SSLv3 and up, i.e also TLS1.x. The version of the cipher suite only tells you the minimal protocol version.
This also means that if you disable SSLv3 and SSLv2 ciphers suites you effectively disable not only SSLv3 but also TLS 1.0 and TLS 1.1, since new cipher suites were only introduced with TLS 1.2.