> > 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] ColdBox Platform: http://www.coldbox.org Blog: http://www.codersrevolution.com On Wed, Aug 10, 2022 at 9:36 AM Xuelei Fan <[email protected]> wrote: > > > On Aug 10, 2022, at 6:49 AM, Brad Wood <[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 > 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] > ColdBox Platform: http://www.coldbox.org > Blog: http://www.codersrevolution.com > > > > On Tue, Aug 9, 2022 at 9:05 PM Xuelei Fan <[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]> wrote: >> >> I have some questions about this ticket >> 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 >> >> 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 >> >> 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] >> ColdBox Platform: http://www.coldbox.org >> Blog: http://www.codersrevolution.com >> >> >> >
