Post handshake client verification with TLSv1.3

Wed Aug 10 16:02:29 UTC 2022

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 <security-dev-retn at openjdk.org> im Auftrag von Xuelei Fan <xuelei.f at gmail.com>
Gesendet: Wednesday, August 10, 2022 4:36:38 PM
An: Brad Wood <bdw429s at gmail.com>
Cc: security-dev at openjdk.org <security-dev at openjdk.org>
Betreff: Re: Post handshake client verification with TLSv1.3

On Aug 10, 2022, at 6:49 AM, Brad Wood <bdw429s at gmail.com<mailto:bdw429s at gmail.com>> 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: brad at coldbox.org<mailto:brad at coldbox.org>
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 <xuelei.f at gmail.com<mailto:xuelei.f at gmail.com>> 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 <bdw429s at gmail.com<mailto:bdw429s at gmail.com>> 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: brad at coldbox.org<mailto:brad at coldbox.org>
ColdBox Platform: http://www.coldbox.org<http://www.coldbox.org/>
Blog: http://www.codersrevolution.com<http://www.codersrevolution.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220810/e8d54422/attachment.htm>