[External] : Re: TLS 1.3 Post-handshake authentication

[Xue-Lei Fan]

Thanks for the detailed information.  I have a better sense of the scenarios now.  What about HTTP/2?  Will the business logic or scenarios get changed for HTTP/2? Could the change apply to HTTP/1.1 as well?

Xuelei

On Mar 5, 2021, at 5:43 AM, arjan tijms <arjan.tijms at gmail.com<mailto:arjan.tijms at gmail.com>> wrote:

Hi,

On Fri, Mar 5, 2021 at 2:05 AM Xue-Lei Fan <xuelei.fan at oracle.com<mailto:xuelei.fan at oracle.com>> wrote:
Does it mean that when switch to HTTP/2, the concern is not valid any longer?  Or there is an alternative solution?  Sorry for the questions, I know little about servlet.  I'm trying to understand the requirement of this feature.

Mark Thomas (Tomcat maintainer) recently explained this on the Servlet mailing list. I think it explains the requirement quite well, so I'll copy/paste it:

"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

(Even if the server did support PHA, the client doesn't so it will fail
there instead).

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."

The above is for HTTP/1.1, which is an important supported target of Servlet. Hope the above helps.

Kind regards,
Arjan Tijms



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20210305/b4c47cc7/attachment-0001.htm>