Summary

Configure Jira to use only the TLSv1.3 protocol when connecting as a client and disable all other protocols. This can be achieved by setting the value of the jdk.tls.disabledAlgorithms or by adding startup properties to ensure Jira exclusively utilises TLSv1.3.

After implementing the aforementioned changes, the sslhandshake may still indicate TLSv1.2 as the clientHello Protocol. The aim of this article is to explain why the Tlsv1.2 protocol continues to appear as the clientHello protocol despite being disabled.

Environment

Jira Server/Data Center on any version from 9.4.0.
.

Diagnosis

Restrict the TLS versions used by Jira when connecting as a client. We can achieve this by setting the lower protocol values in the jdk.tls.disabledAlgorithms parameter in <JAVA_HOME>/lib/security/java.security. Another approach is to add the following startup properties to configure these settings:

-Djdk.tls.client.protocols=TLSv1.3

By implementing these adjustments, Jira is expected to initiate the SSL handshake using the TLSv1.3 protocol when acting as a client. Enable the below debug parameter as outlined in the documentation, restart Jira to replicate the issue, and examine the SSL handshake debug logs.

-Djavax.net.debug=all

However in the SSL debug handshake logs below the clientHello protocol still displays TLSv1.2 even though its disabled.

"ClientHello": {
  "client version"      : "TLSv1.2",
  "random"              : "FB54B80D226ECB51D25ECC5A2F9BC28E540C4AEDE0B62598CD0699481AF8707C",
  "session id"          : "9580F42696CB4A648B4C4EB73CC5BFF6FD8155A314E4DDE9166094CE6DB79EAF",
  "cipher suites"       : "[TLS_AES_256_GCM_SHA384(0x1302), TLS_AES_128_GCM_SHA256(0x1301), TLS_CHACHA20_POLY1305_SHA256(0x1303)]",
  "compression methods" : "00",
    "supported_versions (43)": {
      "versions": [TLSv1.3]
    },
    "key_share (51)": {
      "client_shares": [ 
        {
          "named group": x25519
          "key_exchange": {
            0000: 2D 88 77 D8 18 3D 76 80   9D 83 49 B7 B9 E3 0F 94  -.w..=v...I.....
            0010: B3 13 30 25 9A A0 C1 FD   E6 23 55 7E CC B3 AF 24  ..0%.....#U....$
          }
        },
javax.net.ssl|DEBUG|F1|http-nio-8081-exec-1|2024-08-27 14:34:43.207 GMT|null:-1|WRITE: TLSv1.3 handshake, length = 364
javax.net.ssl|DEBUG|F1|http-nio-8081-exec-1|2024-08-27 14:34:43.207 GMT|null:-1|Raw write (
  0000: 16 03 03 01 6C 01 00 01   68 03 03 FB 54 B8 0D 22  ....l...h...T.."
  0010: 6E CB 51 D2 5E CC 5A 2F   9B C2 8E 54 0C 4A ED E0  n.Q.^.Z/...T.J..
  0020: B6 25 98 CD 06 99 48 1A   F8 70 7C 20 95 80 F4 26  .%....H..p. ...&
  0030: 96 CB 4A 64 8B 4C 4E B7   3C C5 BF F6 FD 81 55 A3  ..Jd.LN.<.....U.
  0040: 14 E4 DD E9 16 60 94 CE   6D B7 9E AF 00 06 13 02  .....`..m.......
  0050: 13 01 13 03 01 00 01 19   00 00 00 2A 00 28 00 00  ...........*.(..
  0060: 25 6E 61 76 6E 65 65 74   68 61 7A 75 72 65 73 71  %navneethazuresq
  0070: 6C 2E 64 61 74 61 62 61   73 65 2E 77 69 6E 64 6F  l.database.windo

Cause

It may be unexpected to see TLS 1.2 in the ClientHello message; however, this is likely due to backward compatibility considerations, as some web servers on the Internet might not yet support TLS 1.3. This design choice is intentional, as outlined in RFC8446. Please review the images below illustrating the variance in the handshake process between TLS 1.2 and TLS 1.3.

When utilising TLS 1.3 as the protocol, the ClientHello includes sharing key_share, signature_algorithms, pre_shared_key, and other elements. The clientHello debug handshake traces in below example correspond precisely to the handshake flow of TLSv1.3 described above.

Solution

It is important to note that even though TLSv1.2 is disabled and only TLSv1.3 is enabled, it is expected to still see TLSv1.2 as the client version. Under the clientHello section ensure that TLSv1.3 appears under supported_versions. Along with that, you should also see key_share, key_exchange, and other relevant details. This confirms that Jira is indeed using TLSv1.3 as the outbound protocol, despite TLSv1.2 being displayed as the client_version.