Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2222480

Summary: Inconsistent Cipher Suite Visibility Between Tomcat Configuration and Nmap Scan
Product: Red Hat Satellite Reporter: Ganesh Payelkar <gpayelka>
Component: InstallationAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED MIGRATED QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.13.0CC: crog, ehelms, ekohlvan, jclere, nmoumoul
Target Milestone: UnspecifiedKeywords: MigratedToJIRA, Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-06-06 16:24:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ganesh Payelkar 2023-07-12 23:54:48 UTC
Description of problem:
Inconsistent Cipher Suite Visibility Between Tomcat Configuration and Nmap Scan
The Tomcat configuration is set up to include all the latest cipher suites for secure communication. However, when performing a scan using Nmap, only two cipher suites are visible. 

Version-Release number of selected component (if applicable):
satellite-6.13.1-1.el8
candlepin-4.2.13-1.el8


How reproducible:
new installation

Steps to Reproduce:
1.
2.
3.

Actual results:

# cat /usr/share/foreman-installer/modules/candlepin/manifests/params.pp
# Candlepin params
#
# @api private
class candlepin::params {
  # this comes from keystore
  $db_password = extlib::cache_data('foreman_cache_data', 'candlepin_db_password', extlib::random_password(32))

  $ciphers = [
    'TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384',
    'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384',
    'TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384',
    'TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384',
    'TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256',
    'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256',
    'TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256',
    'TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256',
  ]
}


# cat /etc/tomcat/server.xml |grep -iE "Connector port=" -A 21
    <Connector port="23443"
               address="localhost"
               protocol="HTTP/1.1"
               SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="want"
               sslProtocol="TLSv1.2"
               sslEnabledProtocols="TLSv1.2"
               keystoreFile="/etc/candlepin/certs/keystore"
               keystorePass="DsiYgkYyusdsdsdsdsdhajzsdsdsd3xnC"
               keystoreType="PKCS12"
               truststoreFile="/etc/candlepin/certs/truststore"
               truststorePass="3e4CjHpcuAAAAAAAA9MrBBBBZZFZ"
               ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
                    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
                    TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
                    TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
                    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
                    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
                    TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
                    TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256" />


# nmap --script ssl-enum-ciphers -p 23443 localhost

PORT      STATE SERVICE
23443/tcp open  unknown
| 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
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: A


Expected results:

It is important to have a visible list of ciphers available so that we can easily remove or add weak or strong ciphers as per our requirements.

Additional info:

Comment 2 Eric Helms 2023-07-28 14:04:38 UTC
@

Comment 3 Eric Helms 2023-07-28 14:05:42 UTC
Sigh, tried to set a needinfo and Bugzilla did things. @ekohlvan you've looked into this area before, could you give this an analysis?

Comment 4 Ewoud Kohl van Wijngaarden 2023-07-28 15:04:32 UTC
I suspect Java doesn't support ECDHE and ECDSA ciphers so it only picks the ECDHE_RSA_WITH_AES ciphers. Those are considered to be secure, but you're right it's a bit misleading. I've had great difficulty in understanding how Tomcat handles ciphers this could be a result of that.

It should be noted we only run candlepin on localhost, so running it using plain text would also be secure (and possibly even faster).

Comment 5 Chris "Ceiu" Rog 2023-08-03 20:29:41 UTC
A critical note in the Tomcat configuration docs [1] regarding ciphers:

> Only the ciphers that are supported by the SSL implementation will be used.

So whatever SSL implementation is being used by Tomcat likely just doesn't support the missing ciphers. 


The protocol field in the connector listed in this BZ is using the "auto-configure" option, which will use the NIO connector by default, but will also try to use the APR/native connector if it's present on the library path and properly configured. Once you sort out which connector protocol is being used, you can hopefully determine which ciphers are supported. For the NIO protocol, it's likely an extension of which ciphers are permitted in the JVM as a whole via java.security. For a native connector, that's highly variable and dependent on what SSL implementation is backing it.

[1] https://tomcat.apache.org/tomcat-9.0-doc/config/http.html

Comment 6 Jean-frederic Clere 2023-08-04 08:11:29 UTC
If you set the log to FINE in conf/logging.properties (for example: org.apache.level = FINE)
you will see in logs/catalina.out:

04-Aug-2023 09:47:22.991 FINE [main] org.apache.tomcat.util.net.openssl.ciphers.OpenSSLCipherConfigurationParser.convertForJSSE Ciphers used: [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,]
04-Aug-2023 09:47:22.991 FINE [main] org.apache.tomcat.util.net.SSLUtilBase.getEnabled The [ciphers] that are active are : [[TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]]
04-Aug-2023 09:47:22.991 FINE [main] org.apache.tomcat.util.net.SSLUtilBase.getEnabled Some of the specified [ciphers] are not supported by the SSL engine and have been skipped: [[TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256]]

So in the list we only have: [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]

so:
+++
[jfclere@fedora build]$ nmap --script ssl-enum-ciphers -p 8443 localhost
Starting Nmap 7.93 ( https://nmap.org ) at 2023-08-04 10:01 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000087s latency).

PORT     STATE SERVICE
8443/tcp open  https-alt
| 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

Nmap done: 1 IP address (1 host up) scanned in 0.99 seconds
+++

In the log you will have something like:
+++
[
SHA-256 fingerprint: 9f1dad126c3677a540e25ef84b75e3ed5bd7be14ec706c5191002a2ae114896f
SHA-1 fingerprint: 12c2170554882e7f0f2d505eaff9cad90fa57302
[
[
  Version: V3
  Subject: EMAILADDRESS=jfclere, CN=localhost, OU=testingTC, O=testers, L=Neuchatel, ST=Neuchatel, C=CH
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
+++
The key is RSA therefore RSA is used.

Comment 7 Jean-frederic Clere 2023-08-04 08:21:55 UTC
create ECDSA key and you have:
[jfclere@fedora build]$ nmap --script ssl-enum-ciphers -p 8443 localhost
Starting Nmap 7.93 ( https://nmap.org ) at 2023-08-04 10:21 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000078s latency).

PORT     STATE SERVICE
8443/tcp open  https-alt
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|     compressors: 
|       NULL
|     cipher preference: client
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds

Comment 8 Jean-frederic Clere 2023-08-08 15:23:14 UTC
I have proposed https://github.com/apache/tomcat/pull/644

Comment 9 Eric Helms 2024-06-06 16:24:12 UTC
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.