[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [servlet-dev] Help please -- Servlet TCK test issue
|
On 02/03/2021 22:28, Stuart Douglas wrote:
On Tue, 2 Mar 2021 at 20:18, arjan tijms <arjan.tijms@xxxxxxxxx
<mailto:arjan.tijms@xxxxxxxxx>> wrote:
Hi,
In general, TLS 1.3 is not fully compatible with Servlet since for
some reason the JEP decided to exclude Post-Handshake Authentication
in Java. See https://openjdk.java.net/jeps/332
<https://openjdk.java.net/jeps/332>.
This is exactly what Servlet needs.
Technically I don't think Servlet does need it, it's just the way the
TCK is written needs it. AFAIK the spec does not explicitly require
support for post handshake auth.
It might not be explicitly called out but the the specification clearly
does require support for post handshake authentication.
Without it you can't have application A using BASIC auth over TLS and
application B using CLIENT-CERT and navigate from app A to app B in the
same connection.
Similarly, without it you can't implement security constraints that
protect an entire application with TLS but only require CLIENT-CERT
authentication for a subset of the application and allows access to the
rest without a certificate.
There ways you can hack around some of these complications (make
certificates optional, make certificates required for the entire app)
but you quickly come up against use cases where these workarounds are
insufficient.
From memory the issue with the TCK is that if you use REQUIRED for the
client auth mode and always request certificates some tests will fail
that are not expecting an
authenticated user, which is why post handshake auth is required. My
memory may be a bit out of date though, it has been a few years since I
ran into this.
The TCK is testing at least one of the scenarios above and confirming
that renegotation (TLS <=1.2) or post handshake authentication (TLS
1.3+) is available.
Technically these tests could probably be challenged,
My view is that any such challenge should be rejected.
or worked around by only
exposing the user/client cert info if auth is actually required (it has
been a few years though, so my
memory may be incorrect).
I don't think that is possible.
The approach Tomcat took is that if you want to pass the TCK in a
configuration that uses a pure JDK/JSSE solution then you need to
configure the container to use TLS <=1.2 only. Neither the servlet
specification nor the TCK requires TLS 1.3.
I don't think the TCK should limit the client to TLS <=1.2. I think the
server should do that if it can't support TLS 1.3 with post-handshake
authentication.
Mark
