https://bz.apache.org/bugzilla/show_bug.cgi?id=69802
--- Comment #2 from Grzegorz Grzybek <[email protected]> --- Hmm, you're right about hitting CLIENT-CERT protected endpoint after browsing to some normal one. But still - this could work if browser establishes new connection when requesting new URL. The point is that no one can control this and Servlet specification doesn't cover this. So if something's wrong, it's the Servlet specification. CLIENT-CERT is kind of separate kind of authentication, because it's not related to HTTP, but underlying TLS. We could imagine some TCP or even IP related authentication and get the same issues. There's not much about CLIENT-CERT in the spec. Only about attributes: https://jakarta.ee/specifications/servlet/6.1/jakarta-servlet-spec-6.1#ssl-attributes and two sentences in "13.6.4. HTTPS Client Authentication": > End user authentication using HTTPS (HTTP over SSL) is a strong > authentication mechanism. > This mechanism requires the client to possess a Public Key Certificate (PKC). > Currently, PKCs are useful in e-commerce applications and also for a > single-signon from within the browser. Even HTTP/2 is not a big thing in Servlet 6.1 spec - especially after deprecating (why?) HTTP/2 ServerPush. So I have an impression that before TLS 1.3 and PHA and Java deciding not to implement PHA, CLIENT-CERT was based on assumption that re-negotiation will allow client to send the certificate after initial decision no to do it. How about simpler scenario, where you create SSLSocket/SSLContext to point to a keystore which simply sends what matches the CAs from `CertificateRequest` message? This is simply non-browser scenario, where PHA is not needed. Also the "until the client requires a URL with a security constraint that requires authentication" could use non-TLS connections for URLs without CLIENT-CERT. In my opinion this is highly unspecified in Servlet API specification, the spec doesn't point to TLS versions, messages and JDK implementation of TLS. In such situations I heard many times from prod managers - add this information to release notes ;) I don't know what could be done. I just feel this warning message is a bit misleading and the situation where: - auth/non-auth endpoints are mixed - user decides not to send the cert initially - TLS 1.3 is involed - JSSE implementation of TLS is used - non-auth and auth connections reuse single TCP connection / SSL session doesn't justify the warning printed in all the cases. Also - and i think this is important - your scenario: > until the client requires a URL with a security constraint that requires > authentication. > At that point a re-handshake (TLS 1.2) or PHA (TLS 1.3) is required. The thing is that CLIENT-CERT mechanism in Tomcat, when missing the certificate doesn't touch (and shouldn't) TLS, `org.apache.catalina.authenticator.SSLAuthenticator#doAuthenticate()` can only send 401. Actually, even https://jakarta.ee/specifications/servlet/6.1/jakarta-servlet-spec-6.1#processing-requests says this explicitly: > If access is restricted to permitted roles and the request has not been > authenticated, the request shall be rejected as unauthorized and a 401 > (SC_UNAUTHORIZED) status code shall be returned to cause authentication. There's no "but IF CLIENT-CERT is used AND IF TLS 1.2 is used THEN initiate re-handshake BUT IF TLS 1.3 is used AND JSSE implementation is used THEN you SHALL NOT use "optional" mTLS"... This would be absurd ;) I'm sorry for the long comment, but I had to write the thoughts down. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
