Thanks for the help Xuelei! ~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 11:59 AM Xuelei Fan <[email protected]> wrote: > 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] > 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 >>> >>> >>> >> >
