Post handshake client verification with TLSv1.3

[Brad Wood]

>
> 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
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com



On Wed, Aug 10, 2022 at 9:36 AM Xuelei Fan <xuelei.f at gmail.com> wrote:

>
>
> 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
> 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
> ColdBox Platform: http://www.coldbox.org
> Blog: http://www.codersrevolution.com
>
>
>
> On Tue, Aug 9, 2022 at 9:05 PM Xuelei Fan <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> 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
>> ColdBox Platform: http://www.coldbox.org
>> Blog: http://www.codersrevolution.com
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220810/dbd7a8ec/attachment.htm>