Weak diffie-helman key size from TLStool

Hello,

I’ve brought this up before but due to unexpected events i could not reply to my first post.

The problem:

We have a ELK cluster running Searchguard 6 version 25. We also have a vulnerability scanner running that has scanned port 9200/TCP on our cluster and is reporting the following:

The SSL/TLS service uses Diffie-Hellman groups with insufficient strength
(key size < 2048).

Server Temporary Key Size: 1024 bits

I went and verified this by connecting to one of our elasticsearch nodes with openssl:

Notice the “Server temp key” section where it says it has a key size of 1024. How can we increase this to at least 2048?

We’ve used the offline tlstool that you provide with the following config:

###
### Self-generated certificate authority
###
#
# If you want to create a new certificate authority, you must specify its parameters here.
# You can skip this section if you only want to create CSRs
#
ca:
   root:
      # The distinguished name of this CA. You must specify a distinguished name.
      dn: CN=test.example.org

      # The size of the generated key in bits
      keysize: 2048

      # The validity of the generated certificate in days from now
      validityDays: 3650

      # Password for private key
      #   Possible values:
      #   - auto: automatically generated password, returned in config output;
      #   - none: unencrypted private key;
      #   - other values: other values are used directly as password
      pkPassword: auto

      # The name of the generated files can be changed here
      file: root-ca.pem

   # If you want to use an intermediate certificate as signing certificate,
   # please specify its parameters here. This is optional. If you remove this section,
   # the root certificate will be used for signing.
   #intermediate:
      # The distinguished name of this CA. You must specify a distinguished name.
      #dn: CN=signing.ca.example.com,OU=CA,O=Example Com\, Inc.,DC=example,DC=com

      # The size of the generated key in bits
      #keysize: 2048

      # The validity of the generated certificate in days from now
      #validityDays: 3650

      #pkPassword: auto

      # If you have a certificate revocation list, you can specify its distribution points here
      #crlDistributionPoints: URI:https://raw.githubusercontent.com/floragunncom/unittest-assets/master/revoked.crl

###
### Default values and global settings
###
defaults:

      # The validity of the generated certificate in days from now
      validityDays: 3650

      # Password for private key
      #   Possible values:
      #   - auto: automatically generated password, returned in config output;
      #   - none: unencrypted private key;
      #   - other values: other values are used directly as password
      pkPassword: auto

      # Specifies to recognize legitimate nodes by the distinguished names
      # of the certificates. This can be a list of DNs, which can contain wildcards.
      # Furthermore, it is possible to specify regular expressions by
      # enclosing the DN in //.
      # Specification of this is optional. The tool will always include
      # the DNs of the nodes specified in the nodes section.
      #nodesDn:
      #- "CN=*.example.com,OU=Ops,O=Example Com\\, Inc.,DC=example,DC=com"
      # - 'CN=node.other.com,OU=SSL,O=Test,L=Test,C=DE'
      # - 'CN=*.example.com,OU=SSL,O=Test,L=Test,C=DE'
      # - 'CN=elk-devcluster*'
      # - '/CN=.*regex/'

      # If you want to use OIDs to mark legitimate node certificates,
      # the OID can be included in the certificates by specifying the following
      # attribute

      # nodeOid: "1.2.3.4.5.5"

      # The length of auto generated passwords
      generatedPasswordLength: 12

      # Set this to true in order to generate config and certificates for
      # the HTTP interface of nodes
      httpsEnabled: true

      # Set this to true in order to re-use the node transport certificates
      # for the HTTP interfaces. Only recognized if httpsEnabled is true

      reuseTransportCertificatesForHttp: true

      # Set this to true to enable hostname verification
      #verifyHostnames: false

      # Set this to true to resolve hostnames
      #resolveHostnames: false


###
### Nodes
###
#
# Specify the nodes of your ES cluster here
#
nodes:
  - name: test01.example.org
    dn: CN=test01.example.org
    dns: test01.example.org
    ip: 192.168.1.10
  - name: test02.example.org
    dn: CN=test02.example.org
    dns: test02.example.org
    ip: 192.168.1.11
  - name: test03.example.org
    dn: CN=test03.example.org
    dns: test03.example.org
    ip: 192.168.1.12
  - name: test04.example.org
    dn: CN=test04.example.org
    dns: test04.example.org
    ip: 192.168.1.13

###
### Clients
###
#
# Specify the clients that shall access your ES cluster with certificate authentication here
#
# At least one client must be an admin user (i.e., a super-user). Admin users can
# be specified with the attribute admin: true
#
clients:
  - name: admin
    dn: CN=admin
    admin: True

The problem you are mentioning here is not about the key, but about the configuration of the TLS endpoint.

To circumvent the problem, you have several options:

  • Add the JVM parameter -Djdk.tls.ephemeralDHKeySize=matched to the file config/jvm.options on all ES nodes. See here for details: JSSE Reference Guide

  • Disable all affected ciphers. You can use the Search Guard options searchguard.ssl.transport.enabled_ciphers and searchguard.ssl.http.enabled_ciphers in elasticsearch.yml to configure the ciphers. See here Logjam: PFS Deployment Guide for “good” ciphers and general recommendations on the topic.

I see, thank you very much for the information.

I will try to disable the affected ciphers and report back on how it goes.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.