RFR: 8326381: com.sun.net.httpserver.HttpsParameters and SSLStreams incorrectly handle needClientAuth and wantClientAuth

[Daniel Jeliński]

On Wed, 21 Feb 2024 06:56:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8326381?
> 
> As noted in the JBS issue, the implementation in `setNeedClientAuth()` and `setWantClientAuth()` of `com.sun.net.httpserver.HttpsParameters` wasn't matching the API specification. The commit in this PR fixes that issue and it now matches the API specification as well as what is done in `javax.net.ssl.SSLParameters` class.
> 
> Additionally, as noted in the JBS issue, the (internal class) `sun.net.httpserver.SSLStreams` had a bug where it could end up resetting the `needClientAuth` flag on the `SSLEngine` because of the way the `setNeedClientAuth()` and `setWantClientAuth()` methods were being called on the `SSLEngine`. This too has been fixed in this PR.
> 
> A new jtreg test has been introduced to reproduce the issue in the `HttpsParameters` class and verify this fix.

If I understand correctly, `com.sun.net.httpserver` is not part of the spec, and CSRs are for spec changes only.

Have you verified that the new code works as intended?
- sends a CertificateRequest message only if either of the properties is true
- refuses to connect if needClientAuth is true and the client doesn't produce a certificate

Pretty sure we don't have any tests for that, they couldn't possibly pass with the current code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17940#issuecomment-1956040278