I opened the bug. As this feature does not apply to HTTP/2, it may be not enabled by default. But please stay tuned for what it may look like.
Xuelei > On Aug 10, 2022, at 9:04 AM, Brad Wood <[email protected]> wrote: > > The future of HTTP is my concern here > > I get that, but my current client requirements is my concern here :) Let's > not throw the baby out with the bathwater because of what may come. If there > is a post-handshake client verification that works via TLSv1.3 over HTTP/1, > let's not prevent people from using that today (taking into account Browser > support, of course). Once the HTTP/2 spec has been ironed out (which I know > can take years) then java can cross that bridge when it comes to it. > > Thanks! > > ~Brad > > Developer Advocate > Ortus Solutions, Corp > > E-mail: [email protected] <mailto:[email protected]> > ColdBox Platform: http://www.coldbox.org <http://www.coldbox.org/> > Blog: http://www.codersrevolution.com <http://www.codersrevolution.com/> > > > > On Wed, Aug 10, 2022 at 9:36 AM Xuelei Fan <[email protected] > <mailto:[email protected]>> wrote: > > >> On Aug 10, 2022, at 6:49 AM, Brad Wood <[email protected] >> <mailto:[email protected]>> wrote: >> >> Honestly, what does HTTP/2 have to do with the ticket in question? > > The future of HTTP is my concern here. Thank you for sharing the link (draft > RFC) bellow. > > Xuelei > > > >> TLS 1.3 supports a post-handshake method of requesting client certs >> without renegotiating the entire SSL handshake. Java needs to support this. >> >> >> From my research, any other web server such as Nginx simply requires that >> HTTP/1 be used when this feature is needed. I suggest we do the same. If >> you are concerned about the future of HTP/2, I would direct you to some >> proposed updates to the HTTP/2 which will accommodate post handshake client >> cert requests: >> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-http2-secondary-certs >> >> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-http2-secondary-certs> >> In the mean time, I have no issues using HTTP/1 for the specific apps that >> require this. >> >> Thanks! >> >> ~Brad >> >> Developer Advocate >> Ortus Solutions, Corp >> >> E-mail: [email protected] <mailto:[email protected]> >> ColdBox Platform: http://www.coldbox.org <http://www.coldbox.org/> >> Blog: http://www.codersrevolution.com <http://www.codersrevolution.com/> >> >> >> >> On Tue, Aug 9, 2022 at 9:05 PM Xuelei Fan <[email protected] >> <mailto:[email protected]>> wrote: >> If we have a look from the viewpoint of HTTP/2, how applications could meet >> the requirements in HTTP/2? Did you have a plan to have the application >> works with HTTP/2 in the future? >> >> Xuelei >> >>> On Aug 9, 2022, at 12:29 PM, Brad Wood <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I have some questions about this ticket >>> https://bugs.openjdk.org/browse/JDK-8206923 >>> <https://bugs.openjdk.org/browse/JDK-8206923> >>> which was closed as "won't fix". I fully realize that TLS 1.3 forbids SSL >>> renegotiation after the handshake in the traditional manner, but I'm >>> curious if the process defined here can be used instead: >>> https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html >>> >>> <https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html> >>> I'm new to this, but it appears to be describing how to accomplish >>> post-handshake client verification which works on TLS 1.3. >>> >>> There's not a lot of information online, but this ticket appears to be >>> Python adding support for this: >>> https://bugs.python.org/issue34670 <https://bugs.python.org/issue34670> >>> >>> Can we discuss reopening the openjdk ticket if this is actually possible? >>> The use case for this is a rather common requirement-- to have an SSL site >>> which doesn't prompt the user for a client cert until they visit a secured >>> area, and then the client cert request is sent, prompting the user at that >>> point. >>> Currently, I have to disable both HTTP/2 and TLS 1.3 in order for this to >>> work. I don't mind sticking to HTTP/1. but I have concerns about disabling >>> TLSv1.3 and what that means for the future security of my apps. >>> >>> Thanks! >>> >>> ~Brad >>> >>> Developer Advocate >>> Ortus Solutions, Corp >>> >>> E-mail: [email protected] <mailto:[email protected]> >>> ColdBox Platform: http://www.coldbox.org <http://www.coldbox.org/> >>> Blog: http://www.codersrevolution.com <http://www.codersrevolution.com/> >>> >> >
