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.
The spec does not require support for these scenarios though, and these can be dealt with to some extent by serving
If you use TLS 1.2 + HTTP/2 there is no way to meet these requirements, as HTTP/2 forbids renegotiation:
> 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.
I don't know if that was the intention though, from memory it was two unrelated tests. I can't actually remember
which test fails if you change to REQUIRED.
> Technically these tests could probably be challenged,
My view is that any such challenge should be rejected.
Well the issue at hand is that at the moment we can't pass these tests with TLS 1.3, so we would essentially require a server that
wants to certify on JDK11 to disable TLS 1.3 in its default config, for a feature that is not at all required by spec and 99% of users
don't care about.
> 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.
But there are (or were) rules around the config you shipped needing to match up with what you
test, so under the Oracle rules you would have to disable TLS1.3 out of the box.
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.
Maybe just change the TCK limit the client for that test to TLS 1.2.
Stuart
Mark
