Hello Brad, (Unrelated to the discussion if the feature should be added to JSSE TLS 1.3, but then again an argument about priotizing it since it seems to be not used with future HTTPS versions - which is relevant for the discussion if it’s needed)
Just want to mention my feeling that with all the ongoing complications and unclear future http behavior I think it would now be a good time for you to seperate the (virtual) hostnames for admin and normal activities. This would not only allows you to request certificates unconditionally, it also will increase session/cookie and XSS/CSP separation. Not to mention the additional benefit of using different access control lists in infrastructure - if needed. Before implementing this I would prefer to have more hybrid encryption features, access to existing TLS session cache (FTP Server) or more per-connection parameters instead. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev <[email protected]> im Auftrag von Xuelei Fan <[email protected]> Gesendet: Wednesday, August 10, 2022 4:36:38 PM An: Brad Wood <[email protected]> Cc: [email protected] <[email protected]> Betreff: Re: Post handshake client verification with TLSv1.3 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 > 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 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]<mailto:[email protected]> ColdBox Platform: http://www.coldbox.org<http://www.coldbox.org/> Blog: http://www.codersrevolution.com<http://www.codersrevolution.com/>
