On Fri, 5 Aug 2022 12:25:36 GMT, Daniel Jeliński wrote:
> Fix `SSLEngineService` test class to make sure it does not discard any
> network data between `handshaking` and `receive`.
>
> With TLS1.3 the client starts sending application data immediately after
> sending the Finished message. The
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
> In the broken case where the conf/security/java.security configuration file
> doesn't exist, the JDK should throw an Error.
>
> CSR in progress.
Sean Coffey has updated the pull request incrementally with one additional
commit since the last revision:
CSR review comments
-
C
On Wed, 10 Aug 2022 13:52:48 GMT, Sean Coffey wrote:
>> In the broken case where the conf/security/java.security configuration file
>> doesn't exist, the JDK should throw an Error.
>>
>> CSR in progress.
>
> Sean Coffey has updated the pull request incrementally with one additional
> commit s
On Wed, 10 Aug 2022 14:03:59 GMT, Alan Bateman wrote:
>> Sean Coffey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> CSR review comments
>
> src/java.base/share/classes/java/security/Security.java line 52:
>
>> 50: * @implNote If the m
> 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
On Wed, 10 Aug 2022 14:22:43 GMT, Sean Coffey wrote:
>> src/java.base/share/classes/java/security/Security.java line 52:
>>
>>> 50: * @implNote If the master security properties file is missing, the JDK
>>> 51: * implementation will throw an {@code InternalError} when initializing
>>> the
>>>
On Fri, 5 Aug 2022 12:25:36 GMT, Daniel Jeliński wrote:
> Fix `SSLEngineService` test class to make sure it does not discard any
> network data between `handshaking` and `receive`.
>
> With TLS1.3 the client starts sending application data immediately after
> sending the Finished message. The
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 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
On Wed, 10 Aug 2022 14:43:00 GMT, Sean Mullan wrote:
>> The opening line of the java.security file denotes it as the "master
>> security properties file". I think it works well but open to suggestions.
>> Maybe we can re-use the terminology from previous paragraph.
>>
>> Fair point about the "
On Wed, 10 Aug 2022 15:40:26 GMT, Xue-Lei Andrew Fan wrote:
> Could it be a TLS implementation problem that the server should not read
> application data as handshaking data?
Not really; `SSLEngine#unwrap` does not have to consume the entire ByteBuffer,
and it's the application's responsibilit
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
On Fri, 5 Aug 2022 12:25:36 GMT, Daniel Jeliński wrote:
> Fix `SSLEngineService` test class to make sure it does not discard any
> network data between `handshaking` and `receive`.
>
> With TLS1.3 the client starts sending application data immediately after
> sending the Finished message. The
On Wed, 10 Aug 2022 16:33:27 GMT, Daniel Jeliński wrote:
> > Could it be a TLS implementation problem that the server should not read
> > application data as handshaking data?
>
> Not really; `SSLEngine#unwrap` does not have to consume the entire
> ByteBuffer, and it's the application's respon
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
On Fri, 5 Aug 2022 12:25:36 GMT, Daniel Jeliński wrote:
> Fix `SSLEngineService` test class to make sure it does not discard any
> network data between `handshaking` and `receive`.
>
> With TLS1.3 the client starts sending application data immediately after
> sending the Finished message. The
Forward port JDK 19 -> JDK 20
-
Commit messages:
- Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
- 8288769: Revert unintentional change to deflate.c
- 8291496: Allocating card table before heap causes underflow asserts in
CardTable::addr_for()
- 8290889: JDK 19 RDP
On Thu, 11 Aug 2022 00:06:35 GMT, David Holmes wrote:
> Forward port JDK 19 -> JDK 20
This pull request has now been integrated.
Changeset: 85a60235
Author:David Holmes
URL:
https://git.openjdk.org/jdk/commit/85a602355ff6e92bb468135d712e0b0b41753db4
Stats: 686 lines in 44 files
19 matches
Mail list logo
