On Thu, 22 Feb 2024 15:23:13 GMT, Jaikiran Pai <[email protected]> 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. > > Jaikiran Pai has updated the pull request incrementally with two additional > commits since the last revision: > > - introduce a test to verify the server honours needClientAuth and > wantClientAuth when set through HttpsParameters > - deprecate the SSL parameters related methods on HttpsParameter I've updated this PR to deprecate the methods on `HttpsParameters` which were meant to set some SSL parameters. Additionally, I have also added more tests, this time to verify that if a server is configured using `HttpsParameters.setNeedClientAuth()` and `HttpsParameters.setWantClientAuth()` then the TLS handshake works as expected and fails in the case when the client doesn't present a certificate when needClientAuth is true. I have verified that without the fix source fix, the test fails and after the fix the test passes. I will focus on the CSR text including the deprecation parts tomorrow once we have an agreement on these changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17940#issuecomment-1959681626
