Bug 1478087 - Tomcat is unaware of sslProtocols setting according to catalina logs
Tomcat is unaware of sslProtocols setting according to catalina logs
Status: MODIFIED
Product: Candlepin
Classification: Community
Component: candlepin (Show other bugs)
2.0
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Alex Wood
Katello QA List
: Triaged
Depends On:
Blocks: 1477666
  Show dependency treegraph
 
Reported: 2017-08-03 10:35 EDT by Chris Snyder
Modified: 2018-02-13 20:15 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1477666
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Github candlepin/candlepin/pull/1804 None None None 2017-11-07 09:56 EST

  None (edit)
Description Chris Snyder 2017-08-03 10:35:39 EDT
+++ This bug was initially created as a clone of Bug #1477666 +++

Description of problem:
Tomcat as used by Candlepin ignores the sslProtocol setting. I want to offer TLSv1.1 and TLSv1.2 only and I modify /etc/tomcat/server.xml accordingly but it does not pick up.
In contrast, modifying the cipher list on the same file applies just as expected.


Version-Release number of selected component (if applicable):
Verified on tomcat-7.0.69-11.el7_3.noarch on Satellite 6.2.10.


How reproducible:
Every time.

Steps to Reproduce:
1. Open /etc/tomcat/server.xml and edit the 8443 connector settings
2. Change sslProtocols from "TLSv1.2,TLSv1.1,TLSv1" to simply "TLSv1.2"
3. Save, restart tomcat service
4. # nmap --script +ssl-enum-ciphers localhost -p 8443

Actual results:

TLSv1.0 and TLSv1.1 and TLSv1.2 are still offered:

PORT     STATE SERVICE
8443/tcp open  https-alt
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|     compressors: 
|       NULL
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|     compressors: 
|       NULL
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|     compressors: 
|       NULL
|_  least strength: strong




Expected results:

Only TLSv1.2 should be offered i.e. something like this output only:

PORT     STATE SERVICE
8443/tcp open  https-alt
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|     compressors: 
|       NULL
|_  least strength: strong




Additional info:

/var/log/catalina.log says: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'sslProtocols' to 'TLSv1.2,TLSv1.1,TLSv1' did not find a matching property.

I also tried replacing 'sslProtocols' with 'sslProtocol' (singular) as this is the correct keyword. Still, tomcat did not pick the change and kept offering TLSv1.1 and TLSv1.0.


In contrast, setting the cipher list on the same connector was correctly picked by tomcat.
Comment 2 mirko.schmidt 2017-08-03 10:41:00 EDT
Hello,

Yes, the correct settings should read:

root@satellite# grep ssl.*Prot /etc/tomcat/server.xml
               sslProtocol="TLSv1.2"
               sslEnabledProtocols="TLSv1.2"

Then the change will be picked up:


# /root/testssl.sh https://127.0.0.1:8443

No mapping file found

No engine or GOST support via engine with your /usr/bin/openssl

###########################################################
    testssl.sh       2.8 from https://testssl.sh/
    (1.582 2017/05/10 19:04:47)

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.1e-fips 11 Feb 2013" [~121 ciphers]
 on katello:/usr/bin/openssl
 (built: "Feb 20 14:38:48 2017", platform: "linux-x86_64")


 Start 2017-08-03 16:33:26    -->> 127.0.0.1:8443 (127.0.0.1) <<--

 rDNS (127.0.0.1):       localhost.
 Service detected:       HTTP


 Testing protocols (via sockets except TLS 1.2, SPDY+HTTP2)

 SSLv2               not offered (OK)
 SSLv3               not offered (OK)
 TLS 1               not offered
 TLS 1.1             not offered
 TLS 1.2             offered (OK)
 Version tolerance   downgraded to TLSv1.2 (OK)
 SPDY/NPN            not offered
 HTTP2/ALPN          Local problem: /usr/bin/openssl doesn't support HTTP2/ALPN


Best regards.
Comment 3 mirko.schmidt 2017-08-03 10:51:45 EDT
If you are changing defaults there, you could also set the following by default:

# /etc/tomcat/tomcat.conf
JAVA_OPTS="-Djdk.tls.ephemeralDHKeySize=2048"

This will enable a 2048 bits Diffie Hellman group for the key exchange (instead of the default 1024 bits). Unfortunately java doesn't offer more at the moment.
Comment 4 mirko.schmidt 2017-08-04 03:35:50 EDT
I wanted to add my proposal of the cipher list in the server.xml which will result in the following list of ciphers that are offered by the server:

Result:
=======

Testing all 121 locally available ciphers against the server, ordered by encryption strength

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.  Encryption Bits
------------------------------------------------------------------------
 xc030   ECDHE-RSA-AES256-GCM-SHA384       ECDH 521   AESGCM    256
 xc028   ECDHE-RSA-AES256-SHA384           ECDH 521   AES       256
 x9f     DHE-RSA-AES256-GCM-SHA384         DH 2048    AESGCM    256
 x6b     DHE-RSA-AES256-SHA256             DH 2048    AES       256
 x9d     AES256-GCM-SHA384                 RSA        AESGCM    256
 x3d     AES256-SHA256                     RSA        AES       256
 xc02f   ECDHE-RSA-AES128-GCM-SHA256       ECDH 521   AESGCM    128
 xc027   ECDHE-RSA-AES128-SHA256           ECDH 521   AES       128
 x9e     DHE-RSA-AES128-GCM-SHA256         DH 2048    AESGCM    128
 x67     DHE-RSA-AES128-SHA256             DH 2048    AES       128
 x9c     AES128-GCM-SHA256                 RSA        AESGCM    128
 x3c     AES128-SHA256                     RSA        AES       128

Perfect forward secrecy is offered with the following ciphers:

Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4

PFS is offered (OK)          DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-SHA256 DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384

A modern client would choose something like:

 Negotiated protocol          TLSv1.2
 Negotiated cipher            ECDHE-RSA-AES256-GCM-SHA384, 521 bit ECDH (limited sense as client will pick)

Changes:
========
You may also want to tighten the security of the server.xml as the keystore password is world readable at the moment (chgrp tomcat /etc/tomcat/server.xml; chmod 640 /etc/tomcat/server.xml):

# ll -ltr /etc/tomcat/server.xml
-rw-r-----. 1 root tomcat 7713 Aug  4 08:52 /etc/tomcat/server.xml

# grep ciphers /etc/tomcat/server.xml
               ciphers="TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384"

Best regards.
Comment 5 Alex Wood 2017-11-06 13:51:50 EST
The Tomcat 7 documentation (https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support) is somewhat ambiguous here.

There are two supported options, sslEnabledProtocols and sslProtocol.  Both options support the JVM constants for SSL/TLS protocol versions (https://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SSLContext) and the documentation notes that the options "overlap."  The difference between the two isn't really spelled out although from searching it seems that one option is retained for compatibility reasons.

My recommendation would therefore be to set both values to "TLSv1.1,TLSv1.2" to support TLS 1.1 and 1.2.  TLSv1 should not be enabled unless there is no other choice due to older clients.  No SSL version should ever be enabled due to well known protocol vulnerabilities (e.g. POODLE).  If we wanted to enforce TLSv1.2 only the correct setting would be "TLSv1.2".  Using 1.2 only is an admirable goal, but client considerations may demand otherwise.

This change would need to be implemented in the Satellite installer along with setting the file mode to 660 and the ownership to root.tomcat (the ownership should already be correct).
Comment 9 Rich Jerrido 2018-02-13 10:10:43 EST
Do note that in the Satellite use case, the server.xml file is configured/managed via puppet. This commit (https://github.com/theforeman/puppet-candlepin/commit/7320f16d2acfab52d7da26e3b4bdee44501244a9) allows the sslProtocols (and sslEnabledProtocols) value to be set via custom-hiera.yml

Note You need to log in before you can comment on or make changes to this bug.