How to set strict protocol or skip weak algorithms in your integrations?

 Hi! 

Today I would like to share a curious story related to the integration of Jira (adoptJDK 11) and the ERP system which works on old Java 6.

You would say to me, welcome to the "blood enterprise systems".

So during our security audit, IDS detected the non-secure protocol TLSv1.1 in that inter-connected communication Jira DC and that ERP system, correctly one of the cipher suites TLS_RSA_WITH_AES_128_CBC_SHA. Yes, it's an old cipher suite, and that tutorial can be used for any other cipher suite as well. 

How we can fix it? 

  1. Set string TLS protocol for all Jira (don’t forget for all nodes), TLS1.3 , TLS1.2. And please, keep in your mind the bug (JDK-8211806 : TLS 1.3 handshake server name indication is missing on a session resume)
  2. Adjust java.security configurations

 

Below table describe the small background and default protocols in your jdk/jre: 

 

JDK 8

(March 2014 to present)

JDK 7

(July 2011 to present)

JDK 6

(2006 to end of public updates 2013)

TLS Protocols

TLSv1.2 (default)

TLSv1.1

TLSv1

SSLv3

TLSv1.2

TLSv1.1

TLSv1 (default)

SSLv3


TLS v1.1 (JDK 6 update 111 and above)

TLSv1 (default)

SSLv3

JSSE Ciphers:

Ciphers in JDK 8

Ciphers in JDK 7

Ciphers in JDK 6

Reference:

JDK 8 JSSE

JDK 7 JSSE

JDK 6 JSSE

Java Cryptography Extension, Unlimited Strength (explained later)

JCE for JDK 8

JCE for JDK 7

JCE for JDK 6

Table 1. Diagnosing TLS, SSL, and HTTPS [1]

 

How to set the strong exact protocols? 

  1. {installation_directory}/bin/setenv.sh the next line, 
CATALINA_OPTS="-Djdk.tls.server.protocols=TLSv1.2 -Djdk.tls.client.protocols=TLSv1.2 ${CATALINA_OPTS}"

What we need to do if we have the next from InfoSec team:  

As part of the security scan, weak ciphers were identified and marked as ‘critical’ which require remediation. i.e. TLS_RSA_WITH_AES_128_CBC_SHA [highlighted below] to allow the project to proceed without an exception.

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK         256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK             128

TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   WEAK       128

So how to adjust the used algorithms? Just open the java installation directory in the next path {conf}/security/java.security.

Open via vim and adjust the next line:

jdk.tls.legacyAlgorithms= \
        K_NULL, C_NULL, M_NULL, \
        DH_anon, ECDH_anon, \
        RC4_128, RC4_40, DES_CBC, DES40_CBC, \
        3DES_EDE_CBC, \
        AES_128_CBC, AES_256_CBC

Then you can validate if you use installation without a reverse proxy. 

 

nmap -script ssl-enum-ciphers -p 443  jiratest.example.com

Starting Nmap 7.91 ( https://nmap.org ) at 2021-06-08 23:38 MSK
Nmap scan report for jiratest.example.com 
Host is up (0.013s latency).

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       Key exchange (ecdh_x25519) of lower strength than certificate key
|_  least strength: A
Nmap done: 1 IP address (1 host up) scanned in 12.16 seconds

For the inter-connection where Jira is a client, you can use tshark / wireshark to double check. 

Hope it helps.

 

Cheers,

Gonchik Tsymzhitov 

 

References:

  1. https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https
  2. https://www.java.com/en/configure_crypto.html
  3. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8211806

Comments

Popular posts from this blog

Overview and practical use cases with open source tracing tool for Java Apps. Glowroot. Installation

Atlassian Community, let's collaborate and provide stats to vendors about our SQL index usage

How only 2 parameters of PostgreSQL reduced anomaly of Jira Data Center nodes