Post handshake client verification with TLSv1.3

[Xuelei Fan]

> On Aug 10, 2022, at 6:49 AM, Brad Wood <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 <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 <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
>>  <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 <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/a8699fc7/attachment.htm>