Post handshake client verification with TLSv1.3

[Xuelei Fan]

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 <bdw429s at gmail.com> 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: 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 Wed, Aug 10, 2022 at 9:36 AM Xuelei Fan <xuelei.f at gmail.com <mailto:xuelei.f at gmail.com>> wrote:
> 
> 
>> 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 <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/840a6df7/attachment.htm>