TLSv1.2 still showing under clientHello when minimum protcol is configuired as TLSv1.3 in Jira
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
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 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:
1
-Djdk.tls.client.protocols=TLSv1.3By 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.
1
-Djavax.net.debug=allHowever in the SSL debug handshake logs below the clientHello protocol still displays TLSv1.2 even though its disabled.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
"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.windoCause
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 utilizing 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 the example below 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.
Was this helpful?