<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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? <div class=""><br class=""></div><div class="">Xuelei<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 9, 2022, at 12:29 PM, Brad Wood <<a href="mailto:bdw429s@gmail.com" class="">bdw429s@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I have some questions about this ticket<div class=""><a href="https://bugs.openjdk.org/browse/JDK-8206923" class="">https://bugs.openjdk.org/browse/JDK-8206923</a></div><div class="">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:</div><div class=""><a href="https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html" class="">https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html<br clear="all" class=""></a><div class=""><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div dir="ltr" class=""><div class=""></div><div class=""><br class=""></div><div class="">I'm new to this, but it appears to be describing how to accomplish post-handshake client verification which works on TLS 1.3. </div><div class=""><br class=""></div><div class="">There's not a lot of information online, but this ticket appears to be Python adding support for this:</div><div class=""><a href="https://bugs.python.org/issue34670" class="">https://bugs.python.org/issue34670</a><br class=""></div><div class=""><br class=""></div><div class="">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. </div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class=""><br class=""></div><div class="">~Brad</div><div class=""><br class=""></div><div class=""><b class="">Developer Advocate</b></div><div class=""><i class="">Ortus Solutions, Corp </i></div><div class=""><b class=""><br class=""></b></div><div class="">E-mail: <a href="mailto:brad@coldbox.org" target="_blank" class="">brad@coldbox.org</a></div><div class="">ColdBox Platform: <a href="http://www.coldbox.org/" target="_blank" class="">http://www.coldbox.org</a> </div><div class="">Blog: <a href="http://www.codersrevolution.com/" target="_blank" class="">http://www.codersrevolution.com</a></div><div class=""><br class=""></div></div></div></div></div></div></div>
</div></blockquote></div><br class=""></div></body></html>