[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [servlet-dev] [glassfish-dev] [jakartaee-platform-dev] Help please -- Servlet TCK test issue
|
On 3/4/21 10:29 AM, arjan tijms wrote:
Hi,
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?
Could a change like that break other implementations?
Kind regards,
Arjan Tijms
Separately, we should add a note somewhere in the servlet
spec that
HTTP/2 and renegotiation are not compatible.
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev