How to reconfigure the server.xml file to enable TSLv1.2 only

[Hetal Kataria]

Hi,

I have a web application using tomcat which is SSL configured and is currently using TSLV1 and TSLv1.1 and i need to reconfigure it so it used TSLv1.2

Java version 1.8 ,Tomcat version 8.5

The current connector code in the server.xml file is working fine (https://URL is working fine)


1. On checking the server.xml  the connector port is defined as:
   <Connector port="8443" protocol="HTTP/1.1" connectionTimeout="20000" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystorePass="xxx" keystoreFile="xxx" maxThreads="150" minSpareThreads="25" acceptCount="100" enableLookups="false"/>

2. To reconfigure the tomcat to use TSLv1.2 we need to make the above code as:
   <Connector port="8443" protocol="HTTP/1.1" connectionTimeout="20000" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" sslEnabledProtocols=”TLSv1.2” keystorePass="xxx" keystoreFile="xxx" maxThreads="150" minSpareThreads="25" acceptCount="100" enableLookups="false"/>

Steps to perform this change:

1. Stop tomcat
2. Make the above code changes in the config file.
3. Restart the tomcat.
4. Test the URL

Also is there a way to verify if the protocol is using TSLv1.2 version only. Please note, we cannot install any 3rd party tool or utility to check this on the server due to client restrictions.

Thanks!

[Tim Moores]

If the host is publicly accessible, you could run a test with https://www.ssllabs.com/ssltest/. But given that the port is 8443, it probably isn't.

If you can get to the same network with an Android device, you can run an SSL scan with an app like this one. Or from a laptop equipped with https://github.com/rbsec/sslscan/

[Ron McLeod]

Tim Moores wrote:If the host is publicly accessible, you could run a test with https://www.ssllabs.com/ssltest/. But given that the port is 8443, it probably isn't.

SSL Labs is a great test/analysis tool, but as Tim mentioned, it isn't going to work with a port other than 443.  One work-around, if you have Internet-facing firewall, would be to temporarily rewrite the destination port for Internet traffic for port 443 to 8443, so that the online tool would be able to access your Tomcat instance.

[Ron McLeod]

Another option would be to use nmap - it will show supported versions of TLS as well as the cipher suites:
nmap --script ssl-enum-ciphers -p 8443 tomcat.example.com Starting Nmap 6.49BETA1 ( http://nmap.org ) at 2019-12-18 08:02 Pacific Standard Time Nmap scan report for tomcat.example.com (192.168.100.125) Host is up (0.00013s latency). PORT    STATE SERVICE 8443/tcp open  https-alt | ssl-enum-ciphers: |   TLSv1.0: |     ciphers: |       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A |       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A |       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 256) - A |       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A |       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A |       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A |       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A |       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 256) - A |       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A |       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A |       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 256) - C |       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 256) - C |       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C |     compressors: |       NULL |     cipher preference: server |   TLSv1.1: |     ciphers: |       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A |       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A |       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 256) - A |       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A |       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A |       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A |       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A |       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 256) - A |       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A |       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A |       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 256) - C |       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 256) - C |       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C |     compressors: |       NULL |     cipher preference: server |   TLSv1.2: |     ciphers: |       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (dh 256) - A |       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (dh 256) - A |       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A |       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 256) - A |       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 256) - A |       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A |       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 256) - A |       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A |       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A |       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A |       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A |       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (dh 256) - A |       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (dh 256) - A |       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A |       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 256) - A |       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 256) - A |       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A |       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 256) - A |       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A |       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A |       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A |       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A |       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 256) - C |       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 256) - C |       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C |     compressors: |       NULL |     cipher preference: server |_  least strength: C

[Ron McLeod]

Another way would be using curl, and forcing it to use the various SSL/TLS versions to see which ones are supported:
$ curl --sslv3 https://tomcat.example.com:8443 curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s). $ curl --tlsv1.0 https://tomcat.example.com:8443 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html> .. </html>
The version options are:
    --tlsv1
    --tlsv1.0
    --tlsv1.1
    --tlsv1.2
    --sslv2
    --sslv3

[Tim Holloway]

Welcome to the Ranch, Hetal!

It's also worth noting that for web applications that will appear on the public Internet (where you would need to be most careful about limiting TLS protocols), that it's generally not recommended to connect Tomcat directly.

DNS services don't record port numbers, only IP addresses, so http will assume port 80 by default and https will assume port 443. To get to port 8443, the client would have to explicitly request it in their URL request (that is, https://myserver.com:8443). Which is inconvenient and error prone.

Port values below 4096 are not available to general application program users such as Tomcat, so to actually use Tomcat directly on ports 80 and 443 would require running Tomcat as a privileged user, which is a security risk.

More often, a reverse proxy server such as Apache, Nginx or IIS is used as the public web interface and an internal connection is made from the proxy server to Tomcat. The internal connection is generally not encrypted, since it's usually done vie an encoded channel and one hopes that your backend LAN is secured against public access anyway. So in a case like this, the limits on transport protocols would be made in the configuration of the proxy server, not Tomcat, since that's where the decryption will be done.

In addition to software proxy servers there are also hardware proxy servers, which are often also load balancers for a cluster of backend appservers. Here, too, the TLS constraints to would be done in their configurations.