I think I just need some info for configuration.
I was using Gatling version 3.5.1 and a simple soap xml api test was working. I upgraded to 3.7.6 for another test and started getting the error “Protocol TLSv1.3 is not supported”. So I rechecked the previous test and found this now had an issue.
I know there have been changes in 3.4 to make HTTP: enable TLSv1.3 by default when available gatling/gatling#3927. So I presume something changed since 3.5.1 to stop making it a default.
What do I need to change (in my gatling.conf I presume) to get this working again.
I checked the upgrade notes but did not find the answer. Sorry I appreciate it is a config I need to do but am a bit lost as to what. I saw in the gatling.conf there is enabledProtocols and useOpenSsl. I have tried playing with these settings but to no avail.
Your guidance would be gratefully appreciated.
I am using Java jdk 1.8.0_191 and jre 1.8.0_191
Thanks in advance
Old Gatling versions were using an old version of Netty that, when using TLSv1.3, was trying to work around Java itself not supporting it. This approach was buggy and didn’t work.
Modern versions of Netty and hence modern versions of Gatling only enable TLSv1.3 when the Java version supports it.
You’re using a very old Java version: 1.8.0_191 that was released Oct 16, 2018, almost 4 years ago. It doesn’t support TLSv1.3 and is more than seriously lagging behind in terms of security fixes.
If you insist on staying on Java 8 instead of upgrading to Java 11 or 17, you should upgrade to 8u332.
Yes the version of Java I am currently using is very old. Unfortunately at the bank it is very difficult moving Java versions. So we are stuck on Java 8 (moving to 11 or 17 is a dream for us, we only just migrated our Linux servers to 8). However, on contacting the group level they do have jdk 8u312-b07 available. TLS 1.3 has been supported since version 8u261 b12. So I will work on getting this installed. In the meantime (as this takes a long time in the banking world) I have reverted back to Gatling 3.5.1 and this is working. I appreciate this is just a short term solution as we will not have benefit of the bug fixes and improvements the later versions give. We may even have issues that have already been fixed…
Thanks of the quick responses to my problems.
this is working
Well, not really. You might experience some TLS issues because of the old Netty version I mentioned.
So we are stuck on Java 8 (moving to 11 or 17 is a dream for us, we only just migrated our Linux servers to 8).
That’s sad. Major Java frameworks are upgrading their Java version baseline, eg:
We’re also considering such move.
Sticking to old unmaintained versions is pretty risky.
I completely agree with you. It is frustrating for me as well.
But unfortunately the big institutions are often lagging behind when it comes to technology and innovation. On our company systems I cannot install any software, I need to raise a ticket and wait. Upgrading to jdk 8u312-b07 will happen sometime in the future but we are supposed to be agile. Maven central is seen as a golden source so I can use any dependencies from there. If I reference a new dependency / version this is copied to our Nexus and the usual security checks are done.
TLS 1.3 is currently disabled on our load balance and will not be activated until Q3/ Q4.
So the tests are working for the moment, hopefully I will not find any further issues or I can work round them.