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:

I see, thank you very much for the information.

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