2

Can users actually use the 3DES cipher to connect to a Tomcat web server, if the 3DES cipher has been disabled via registry keys in Windows: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES dword enabled 0 and dword disabled by default 1 for both client and server

Nmap scans indicates that the cipher is still available, and so does Qualys vulnerability scans:

   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D
   TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A

I've used the same method to disable TLS 1.0 on other Windows servers, which work fine and both Nmap and Qualys confirms.

Is it necessary to disable 3DES cipher in the web server as well, although Windows won't provide the cipher?

12
  • > Nmap scans indicates that the cipher is still available, and so does > Qualys vulnerability scans. Could you precise if NMap and Qualys indicate that the vulnerability is still available on the server or the workstation (if it is on the workstation it's means an authenticated/conformity scan) ?
    – user213795
    Aug 6, 2019 at 12:34
  • Not all browsers use SCHANNEL crypto. AFAIK Firefox and Chrome based browsers don't.
    – Josef
    Aug 6, 2019 at 12:38
  • Nmap scans and Qualys scans of what? AFAIK those tools scan the server, not the client. Aug 6, 2019 at 12:41
  • I've updated post with Nmap output. Nmap reports that 3DES is still available via ssl-enum-ciphers scan. Qualys still reports the vulnerability to be present after a fresh scan of the web server.
    – QuantumSec
    Aug 6, 2019 at 12:44
  • 1
    While 3DES is an ancient algorithm with substandard security margins and terrible performance, in the long list of security vulnerabilities to worry about 3DES would be very far down that list. Aug 6, 2019 at 12:46

1 Answer 1

3

This is now beginning to sound like a Tomcat configuration question. Although I have no personal experience with Tomcat, some links suggest that this section of the Tomcat documentation guide looks appropriate, in particular the ciphers attribute in the configuration file conf/server.xml. From the docs:

ciphers attribute:

The ciphers to enable using the OpenSSL syntax. (See the OpenSSL documentation for the list of ciphers supported and the syntax). Alternatively, a comma separated list of ciphers using the standard OpenSSL cipher names or the standard JSSE cipher names may be used.

When converting from OpenSSL syntax to JSSE ciphers for JSSE based connectors, the behaviour of the OpenSSL syntax parsing is kept aligned with the behaviour of the OpenSSL 1.1.0 development branch.

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

If not specified, a default (using the OpenSSL notation) of HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA will be used.

Note that, by default, the order in which ciphers are defined is treated as an order of preference. See honorCipherOrder.

So you now have a way to specify what you want. Actually, you have two ways, either OpenSSL syntax or a JSSE ciphersuite list, and each has it's pros and cons.

The OpenSSL syntax provides a compact specification that allows you specify what you don't want in addition to what you do. The downside is that the terse notation makes it hard to understand just what you're getting.

The JSSE ciphersuite syntax is quite straightforward. You just explicitly list each allowable ciphersuite from this (check here for Java 11)long list, separated by commas. The downside is that as new ciphers are added over time you will have to add to this list to allow their use.

1
  • 1
    This 'interchangeable' configuration is only on Tomcat 8.5 up; if still using lower you must use only the config matching the SSL/TLS implementation you either specify or default to. Aug 7, 2019 at 3:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .