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?

QuantumSec
  • 88
  • 9
  • Nmap scans and Qualys scans of what? AFAIK those tools scan the server, not the client. – President James K. Polk Aug 06 '19 at 12:41
  • 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. – President James K. Polk Aug 06 '19 at 12:46
  • As stated in the question, I'm scanning a Tomcat web server for vulnerabilities and it finds a 3DES vulnerability. It's not a high risk vulnerability, but still a vulnerability that has to be fixed according to patch policy. I want to avoid that a user can send request to the web server and negotiate a TLS connection using old and insecure ciphers. As i don't control the clients I have to control ciphers server side and make sure the old ciphers are not present on the servers palette. – QuantumSec Aug 06 '19 at 12:55
  • Tomcat uses JSSE for SSL/TLS support, not schannel. @JamesKPolk's answer will help you with the configuration. – Xander Aug 06 '19 at 14:38
  • > 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) ? –  Aug 06 '19 at 12:34
  • Not all browsers use SCHANNEL crypto. AFAIK Firefox and Chrome based browsers don't. – Josef Aug 06 '19 at 12:38
  • 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 06 '19 at 12:44
  • OK, so it's a vulnerability scan on the server. So yes, it will probably lock the 3DES cipher on Windows for all application using Windows Cipher (Internet Explorer, Edge, third party apps...). As exposed by josef, somes applications don't rely on it so the vulnerability will still be present for those apps. The better way to solve the issue could be, if possible, to modify the cipher compatibility list on the server itself. –  Aug 06 '19 at 12:54
  • Thanks Voilier, so some web server applications that are not Windows based(Apache, Tomcat etc.) will have their own alternative to Windows SCHANNEL, and therefore won't be restricted by SCHANNEL policies? – QuantumSec Aug 06 '19 at 13:29
  • I think you should configure each server and/or server application to explicitly reject deprecated ciphers at the negociation phase. Configuration could vastly vary. –  Aug 06 '19 at 14:18
  • @Xander+ Tomcat (unlike many other Java TLS programs) can use for SSL/TLS _either_ JSSE _or_ APR which is basically a wrapper on OpenSSL -- but not schannel. – dave_thompson_085 Aug 07 '19 at 03:49
  • @dave_thompson_085 Ah, good to know, thanks! – Xander Aug 07 '19 at 04:02

1 Answers1

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.

President James K. Polk
  • 243
  • 2
  • 8
  • 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. – dave_thompson_085 Aug 07 '19 at 03:50