I've spent a little time looking at this this afternoon.
The two tests are essentially the same. One configures the security
constraints in web.xml, the other via annotations.
As of Java 11, TLS 1.3 support is optional.
Most (all?) Java 11 implementations support TLS 1.3 and it is enabled by
default for both client and server.
Mostly true, although for GlassFish, as pointed out by Steve, it's not enabled by default and extra code is needed to make it support it. So GlassFish, for now, is connecting using TLS 1.2. This circumvents the issue.
The sequence of events in the test is as follows:
- Client connects.
- TLS handshake, no client authentication.
- Client sends request
- Server parses it and maps it to a web application
- Server compares request to security constraints
- Security constraints require CLIENT-CERT
- Request fails because server cannot trigger post-handshake
authentication
Correct, that's the sequence I also observed with TLS 1.3 enabled Payara running JDK 11.
My reading of the spec is that the ability to create per URL security
constraints strongly implies that renegotiation / PHA needs to be
supported. The existence of this test supports that view.
I think the test is valid and should stay.
I think so too.
I have also read through section 2.2.2 of the Jakarta Servlet TCK user's
guide. I think we should use the following rule:
<quote>
Servlet5 The Maintenance Lead can define exceptions to these Rules. Such
exceptions would be made available as above, and will apply to all
vendor implementations.
</quote>
My suggestion would be something like:
"If running on a JRE that supports TLS 1.3+ but does not support
post-handshake authentication, it is permitted to run the TCK with the
product configured to use TLS<=1.2 (i.e. disable TLS 1.3+) even if that
is not the default configuration."
Something like that indeed, or shall we "simply" (or additionally?) force this specific test in the TCK to use TLS 1.2?
Kind regards,
Arjan Tijms
Separately, we should add a note somewhere in the servlet spec that
HTTP/2 and renegotiation are not compatible.
