Thanks for the help Xuelei!
~Brad
*Developer Advocate*
*Ortus Solutions, Corp *
E-mail: b...@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
On Wed, Aug 10, 2022 at 11:59 AM Xuelei Fan wrote:
> I opened the bug. As this feature does not apply to
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 wrote:
>
> The future of HTTP is my concern here
>
> I get that, but my current client requirements
>
> 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
.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: security-dev im Auftrag von Xuelei Fan
Gesendet: Wednesday, August 10, 2022 4:36:38 PM
An: Brad Wood
Cc: security-dev@openjdk.org
Betreff: Re: Post handshake client verification with TLSv1.3
On Aug 10, 2022, at 6
> On Aug 10, 2022, at 6:49 AM, Brad Wood 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
Honestly, what does HTTP/2 have to do with the ticket in question? 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
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 wrote:
>
> I have some questions about this ticket
> https://
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.op
