Hi all,
Ever since upgrading to Java 8u161 we are running into performance problems
that were caused by the implementation of extended master secret.
First problem was described in 8219568; server does not allow resuming
legacy sessions even when jdk.tls.allowLegacyResumption is set to true.
esumption is
> expected? I did not get the point from JDK-8219568 and this
> description. It would be helpful if there is a test code to reproduce
> the behavior.
>
> Thanks,
> Xuelei
>
> On 4/6/2019 11:36 AM, Daniel Jeliński wrote:
> > Hi all,
> > Ever
; On 4/8/2019 9:59 AM, Daniel Jeliński wrote:
> > Hi Xuelei,
> > Thanks for your response!
> > My understanding is that legacy resumption = resumption of a session
> > that was established without extended master secret extension.
> >
> > Our Java application
ase.
Tested on OpenJDK 11.0.6.
Regards,
Daniel Jeliński
[1]
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
[2] http://mail.openjdk.java.net/pipermail/security-dev/2017-May/015902.html
[3] https://gist.github.com/djelinski/b4543a3eb7ea66306044c08b41bba00f
k.java.net/jdk/jdk/file/ee1d592a9f53/src/java.base/share/classes/sun/security/validator/Validator.java#l267
wt., 27 paź 2020 o 18:44 Daniel Jeliński napisał(a):
> Hi all,
>
> TL;DR: both SSL server and client ignore KeyUsage certificate extension
> when determining the list of a
Sure Xuelei. Filed 9067508 for the client issue, and 9067509 for the
server one.
Thanks!
Daniel
sob., 31 paź 2020 o 17:23 Xue-Lei Fan napisał(a):
> Hi Daniel,
>
> Would you mind file a bug for the tracking?
>
> Xuelei
>
> On Oct 31, 2020, at 5:45 AM, Daniel Jeliński
-8245576/src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java>
> by
> using ConcurrentHashMap, if you have a chance, would you like to evaluate
> if it could be improved further with your ideas?
>
> Thanks,
> Xuelei
>
> On Jan 27, 2021, at 1:28 AM, Daniel
Hi all,
What's the right spot to report documentation issues?
I've been reading the JSSE reference guide and noticed that in section
"Resuming Session Without Server-Side State"
t;
> On 05/02/2021 14:03, Sean Mullan wrote:
> > If you have a JBS account, you can file a bug in the docs/guides
> > category.
> >
> > However, I have also forwarded your email to our internal docs
> > engineer, so we will follow-up on it.
> >
> > Thanks,
Hi all,
I'd like to modify the MemoryCache class that is used for caching SSL
sessions in Java 11; when the cache is overloaded (full cache with no
expired entries), the computational complexity of put operation is linear
in the cache size.
I am aware that the current Java versions are using
cketExtension extension in TLS 1.3). But in JDK 14 or later,
> there is usually no need to change the default (=stateless).
>
> Regards,
>
> Ralph
>
>
>
> Gesendet: Freitag, 05. Februar 2021 um 08:42 Uhr
> Von: "Daniel Jeliński"
> An: security-dev@openjdk.j
maintainers prefer to backport as much of a patch as
> possible.
>
> Thanks,
> Paul
>
> -Original Message-
> From: security-dev on behalf of Daniel
> Jeliński
> Date: Tuesday, March 9, 2021 at 3:37 PM
> To: "jdk-updates-...@openjdk.java.net"
&g
Thanks again Paul.
Could you sponsor the change? As far as I can tell, I'd need to add a
fix request now, but I don't have access to issue tracker.
Thanks,
Daniel
wt., 16 mar 2021 o 18:59 Hohensee, Paul napisał(a):
>
> Looks good! :)
>
> -Original Message-----
> From:
Hi Xuelei,
I reviewed the RFC above (I hope I'm not too late!) and have some
concerns about the security properties of the proposed solution.
Essentially they would apply to all schemes using session ticket
encryption keys derived from a long-lived secret.
How does this apply to TLS versions
>
> Thanks,
> Paul
>
> -Original Message-
> From: security-dev on behalf of
> "Hohensee, Paul"
> Date: Wednesday, March 17, 2021 at 1:01 PM
> To: Daniel Jeliński
> Cc: "jdk-updates-...@openjdk.java.net" ,
> "security-dev@openjdk.java.
Hi,
Please review this 11u backport; this is the same patch as for head,
except for microbenchmark makefile changes that did not apply because
the file doesn't exist in 11u, and the actual microbenchmark, which
would only add weight for no benefit.
Bug:
On Fri, 24 Sep 2021 13:32:01 GMT, Weijun Wang wrote:
>> The default list of providers defined in java.security file can be
>> overridden with a custom file, declared with
>> `-Djava.security.properties=/path/to/custom.security` command line parameter.
>> If the new list of providers is shorter
On Fri, 24 Sep 2021 08:01:07 GMT, Daniel Jeliński
wrote:
> The default list of providers defined in java.security file can be overridden
> with a custom file, declared with
> `-Djava.security.properties=/path/to/custom.security` command line parameter.
> If the new list
On Sat, 2 Oct 2021 05:45:47 GMT, Clive Verghese wrote:
> Hi,
>
> We have identified that the `HandshakeContext` initialization takes up a
> close to 50% of the flame graph for startHandshake. I have moved the
> computation of the `activeProtocols` and `activeCipherSuites` from the
>
Hi all,
During routine examination of thread dumps I noticed a stack trace you
may find interesting. Relevant part:
java.lang.Thread.State: RUNNABLE
...
at java.lang.IllegalStateException.(java.base@11.0.11/Unknown Source)
at javax.crypto.Cipher.checkCipherState(java.base@11.0.11/Unknown
On Mon, 29 Nov 2021 08:42:22 GMT, Daniel Jeliński wrote:
> All TLS 1.3 handshakes in compatibility mode must send a non-empty SessionID
> field. Currently TLS1.3 session resumptions are sending empty session ID.
> This patch fixes that problem.
>
> All jdk_core tests passed.
> All TLS 1.3 handshakes in compatibility mode must send a non-empty SessionID
> field. Currently TLS1.3 session resumptions are sending empty session ID.
> This patch fixes that problem.
>
> All jdk_core tests passed. The newly added check passes with the patch, fails
> w
On Tue, 21 Dec 2021 21:25:53 GMT, Anthony Scarpino
wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update copyright year
>
> Please add " 2021," to the copyright of R
nd yes, the Project Lead is Mark Reinhold, mark dot reinhold at oracle dot
> com.
>
> Good luck!
>
> --Weijun
>
> > On Dec 21, 2021, at 5:29 AM, Daniel Jeliński wrote:
> >
> > Hi Weijun,
> >
> >> The "Account Help" link on https://id.openjd
Hi Weijun,
> The "Account Help" link on https://id.openjdk.java.net/console/login leads to
> https://wiki.openjdk.java.net/display/general/FAQ. It seems you need to
> become an OpenJDK author first to get an account.
Right. This page then leads to
Trivial change. Issue reported by
[lgtm.com](https://lgtm.com/projects/g/openjdk/jdk/alerts/?mode=tree=java=1952840153).
-
Commit messages:
- Add missing spaces
Changes: https://git.openjdk.java.net/jdk/pull/6894/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6894=00
se/JDK-8279043 for this and
> added a noreg-trivial label.
>
> The usual process is to submit the PR with the associated bug id AFAIK.
>
> Thanks,
>
> Valerie
>
> On 12/20/2021 11:04 AM, Daniel Jeliński wrote:
> > Hello,
> > I fixed a few exception strings that had
On Mon, 20 Dec 2021 14:50:08 GMT, Daniel Jeliński wrote:
> Trivial change. Issue reported by
> [lgtm.com](https://lgtm.com/projects/g/openjdk/jdk/alerts/?mode=tree=java=1952840153).
This pull request has now been integrated.
Changeset: f31dead6
Author:Daniel Jelinski
Committer:
On Mon, 20 Dec 2021 14:50:08 GMT, Daniel Jeliński wrote:
> Trivial change. Issue reported by
> [lgtm.com](https://lgtm.com/projects/g/openjdk/jdk/alerts/?mode=tree=java=1952840153).
Thanks! bug title fixed.
-
PR: https://git.openjdk.java.net/jdk/pull/6894
Hello,
Some time ago I filed an issue on bugreport
(https://bugs.openjdk.java.net/browse/JDK-8277881) about the issue
where Java does not fill SessionID field in ClientHello message when
resuming a TLS 1.3 session.
The SessionID field is not required by TLS1.3; its resumption
mechanism relies on
Hello,
I fixed a few exception strings that had missing spaces between words;
the PR can be found here https://github.com/openjdk/jdk/pull/6894.
I could use some assistance with a JBS ticket and reviews here.
On a side note, how can I get a JBS account?
Regards,
Daniel
On Fri, 22 Oct 2021 18:24:22 GMT, Daniel Jeliński wrote:
> The current code that changes cipher suites disposes the new suite instead of
> the old one, which usually silently fails. This patch fixes the code to
> dispose the old instance instead.
>
> DTLS appears t
All TLS 1.3 handshakes in compatibility mode must send a non-empty SessionID
field. Currently TLS1.3 session resumptions are sending empty session ID. This
patch fixes that problem.
All jdk_core tests passed. The newly added check passes with the patch, fails
without it.
-
Commit
On Mon, 1 Nov 2021 19:49:32 GMT, Xue-Lei Andrew Fan wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Dispose write cipher after changing ciphers
>
> src/java.base/share/classes/sun/
ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
avoid modifying DTLSOutputRecord
-
Changes:
- all: https://git.openjdk.java.net/
On Sun, 24 Oct 2021 04:58:45 GMT, Xue-Lei Andrew Fan wrote:
>> Did you want to cover the update for line 222 at OutputRecord.java as well?
>
>> After reviewing the scope of changes to fix writeCipher disposal I decided
>> to remove it entirely. It would probably be a nice follow-up enhancement,
The current code that changes cipher suites disposes the new suite instead of
the old one, which usually silently fails. This patch fixes the code to dispose
the old instance instead.
DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly
[disposes the old
On Fri, 22 Oct 2021 19:25:38 GMT, Daniel Jeliński wrote:
>> The current code that changes cipher suites disposes the new suite instead
>> of the old one, which usually silently fails. This patch fixes the code to
>> dispose the old instance instead.
>>
>>
ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Fix one more case
-
Changes:
- all: https://git.openjdk.java.net/jdk/pul
On Fri, 22 Oct 2021 18:24:22 GMT, Daniel Jeliński wrote:
> The current code that changes cipher suites disposes the new suite instead of
> the old one, which usually silently fails. This patch fixes the code to
> dispose the old instance instead.
>
> DTLS appears t
ice if you could also update similar issues in (DTLS)OutRecord
> files.
>
> Thanks,
> Xuelei
>
> On Oct 22, 2021, at 8:14 AM, Daniel Jeliński wrote:
>
> Hi all,
> During routine examination of thread dumps I noticed a stack trace you
> may find interesting. Re
On Fri, 22 Oct 2021 18:45:31 GMT, Xue-Lei Andrew Fan wrote:
>> The current code that changes cipher suites disposes the new suite instead
>> of the old one, which usually silently fails. This patch fixes the code to
>> dispose the old instance instead.
>>
>> DTLS appears to be unaffected:
On Fri, 22 Oct 2021 18:45:31 GMT, Xue-Lei Andrew Fan wrote:
>> The current code that changes cipher suites disposes the new suite instead
>> of the old one, which usually silently fails. This patch fixes the code to
>> dispose the old instance instead.
>>
>> DTLS appears to be unaffected:
ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Do not dispose writeCipher in changeCipherSpec - we may still need it
---
On Fri, 5 Nov 2021 22:57:24 GMT, Xue-Lei Andrew Fan wrote:
>> src/java.base/share/classes/sun/security/ssl/HandshakeContext.java line 74:
>>
>>> 72: "sun.security.ssl.allowLegacyHelloMessages", true);
>>> 73:
>>> 74: static Cache
>>> handshakeContextCache;
>>
>> I
On Wed, 3 Nov 2021 09:12:29 GMT, Daniel Jeliński wrote:
>> src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java line
>> 436:
>>
>>> 434:
>>> 435: void queueUpCipherDispose() {
>>> 436: RecordMemo lastMem
ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
bugfix
-
Changes:
- all: https://git.openjdk.java.net/jdk/pul
On Tue, 2 Nov 2021 23:43:42 GMT, Xue-Lei Andrew Fan wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> avoid modifying DTLSOutputRecord
>
> src/java.base/share/classes/sun/security/
On Tue, 2 Nov 2021 23:35:51 GMT, Xue-Lei Andrew Fan wrote:
> Please hold off on the integration, the regression testing failed.
could you point me to the failing test? I'm running the jdk_security suite;
only sun/security/mscapi/ShortRSAKeyWithinTLS is failing, and it's failing
because of
ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57)
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Dispose write cipher after changing ciphers
-
Changes:
- all: https://git.openjdk.j
On Sun, 24 Oct 2021 04:58:45 GMT, Xue-Lei Andrew Fan wrote:
>> Did you want to cover the update for line 222 at OutputRecord.java as well?
>
>> After reviewing the scope of changes to fix writeCipher disposal I decided
>> to remove it entirely. It would probably be a nice follow-up enhancement,
On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeliński wrote:
>> Please review this PR that enables
>> [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170)
>> compiler flag, which makes
On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeliński wrote:
> Please review this PR that enables
> [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170)
> compiler flag, which makes assigning a strin
Please review this PR that enables
[Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170)
compiler flag, which makes assigning a string literal to a non-const pointer a
compile-time error.
This type of
On Tue, 22 Feb 2022 11:33:52 GMT, Magnus Ihse Bursie wrote:
>> Please review this PR that enables
>> [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170)
>> compiler flag, which makes assigning a string
d that the build passes both with and without `--enable-debug`, both
> with VS2017 and VS2019.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Move strictStrings to toolchain_cflags
-
Changes:
- all: https://
On Tue, 22 Feb 2022 16:35:09 GMT, Magnus Ihse Bursie wrote:
>> Done
>
> Did you forget to push the fix?
Push works better when connected... this time it's pushed for real.
-
PR: https://git.openjdk.java.net/jdk/pull/7565
During TLS handshake, hundreds of constraints are evaluated to determine which
cipher suites are usable. Most of the evaluations are performed using
`HandshakeContext#algorithmConstraints` object. By default that object contains
a `SSLAlgorithmConstraints` instance wrapping another
On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeliński wrote:
> During TLS handshake, hundreds of constraints are evaluated to determine
> which cipher suites are usable. Most of the evaluations are performed using
> `HandshakeContext#algorithmConstraints` object. By default that object
&
On Tue, 12 Apr 2022 15:40:46 GMT, Claes Redestad wrote:
>> While this is technically true, `SSLAlgorithmConstraints` is an internal
>> class, so it's very unlikely that we will ever get `SSLAlgorithmConstraints`
>> other than `DEFAULT` here.
>
> Right, I see even `DEFAULT_SSL_ONLY` is only
On Tue, 12 Apr 2022 13:38:17 GMT, Claes Redestad wrote:
>> During TLS handshake, hundreds of constraints are evaluated to determine
>> which cipher suites are usable. Most of the evaluations are performed using
>> `HandshakeContext#algorithmConstraints` object. By default that object
>>
On Wed, 13 Apr 2022 06:45:20 GMT, Xue-Lei Andrew Fan wrote:
>> During TLS handshake, hundreds of constraints are evaluated to determine
>> which cipher suites are usable. Most of the evaluations are performed using
>> `HandshakeContext#algorithmConstraints` object. By default that object
>>
On Thu, 7 Apr 2022 20:17:28 GMT, Xue-Lei Andrew Fan wrote:
>> Please review the update to remove finalizer method in the SunJSSE provider
>> implementation. It is one of the efforts to clean up the use of finalizer
>> method in JDK.
>
> Xue-Lei Andrew Fan has updated the pull request
On Thu, 14 Apr 2022 14:58:24 GMT, Xue-Lei Andrew Fan wrote:
>> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java
>> line 73:
>>
>>> 71:
>>> 72: static AlgorithmConstraints wrap(AlgorithmConstraints
>>> userSpecifiedConstraints) {
>>> 73: if
nce, and avoid
> duplicate checks.
Daniel Jeliński has updated the pull request incrementally with two additional
commits since the last revision:
- add more factory methods, update copyright
- return DEFAULT also when user constraints are null
-
Changes:
- all: https://git.
On Thu, 14 Apr 2022 21:05:06 GMT, Daniel Jeliński wrote:
>> During TLS handshake, hundreds of constraints are evaluated to determine
>> which cipher suites are usable. Most of the evaluations are performed using
>> `HandshakeContext#algorithmConstraints` object. By d
Profiling the TLS handshakes using SSLHandshake benchmark shows that a large
portion of time is spent in HandshakeContext initialization, specifically in
DisabledAlgorithmConstraints class.
There are only a few instances of that class, and they are immutable. Caching
the results should be a
On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeliński wrote:
> Profiling the TLS handshakes using SSLHandshake benchmark shows that a large
> portion of time is spent in HandshakeContext initialization, specifically in
> DisabledAlgorithmConstraints class.
>
> There are only
On Fri, 22 Apr 2022 02:13:14 GMT, David Schlosnagle
wrote:
>> Profiling the TLS handshakes using SSLHandshake benchmark shows that a large
>> portion of time is spent in HandshakeContext initialization, specifically in
>> DisabledAlgorithmConstraints class.
>>
>> There are only a few
> > The complication with caching is while something like an algorithm
> > name only could be easy in a hashmap, it gets more complicated when
> > you get into key sizes. Such as, how to represent RSA 1k being
> > disallowed and but 2k allowed.. or certificate usage..
> >
On Fri, 22 Apr 2022 06:26:01 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have the simple update reviewed.
>
> In the NativeGSSContext constructor for imported context, the assert is use
> on the object field, instead of the input parameters. As in a constructor,
> `'this'` object does not
On Wed, 20 Apr 2022 04:19:38 GMT, Xue-Lei Andrew Fan wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Replace remaining constructors with factory methods
>
> src/java.base/
On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeliński wrote:
> During TLS handshake, hundreds of constraints are evaluated to determine
> which cipher suites are usable. Most of the evaluations are performed using
> `HandshakeContext#algorithmConstraints` object. By default that object
&
nce, and avoid
> duplicate checks.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Reduce line length
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8199/files
- new: https://git.openjdk.java.net/jdk/pull
On Wed, 13 Apr 2022 06:46:51 GMT, Xue-Lei Andrew Fan wrote:
>> Daniel Jeliński has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - add more factory methods, update copyright
>> - return DEFAULT also
nce, and avoid
> duplicate checks.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Replace remaining constructors with factory methods
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8199/files
- new: ht
On Tue, 19 Apr 2022 14:23:07 GMT, Xue-Lei Andrew Fan wrote:
>> Daniel Jeliński has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - add more factory methods, update copyright
>> - return DEFAULT also when use
On Sat, 23 Apr 2022 14:57:01 GMT, Xue-Lei Andrew Fan wrote:
>> Profiling the TLS handshakes using SSLHandshake benchmark shows that a large
>> portion of time is spent in HandshakeContext initialization, specifically in
>> DisabledAlgorithmConstraints class.
>>
>> There are only a few
On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeliński wrote:
> Profiling the TLS handshakes using SSLHandshake benchmark shows that a large
> portion of time is spent in HandshakeContext initialization, specifically in
> DisabledAlgorithmConstraints class.
>
> There are only
On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeliński wrote:
> Profiling the TLS handshakes using SSLHandshake benchmark shows that a large
> portion of time is spent in HandshakeContext initialization, specifically in
> DisabledAlgorithmConstraints class.
>
> There are only
On Mon, 25 Apr 2022 13:22:34 GMT, Daniel Fuchs wrote:
>> Right, soft references are likely to be cleaned if they are not used in an
>> entire GC cycle.
>> Using a soft reference for each map entry would not help here; note that all
>> keys and all values in this map are GC roots (keys are enum
On Mon, 25 Apr 2022 14:33:13 GMT, Xue-Lei Andrew Fan wrote:
>> `SoftReference`s are guaranteed to survive one GC after use; beyond that
>> their lifespan is determined by `SoftRefLRUPolicyMSPerMB` and the amount of
>> memory available.
>
>> With all the above in mind I decided not to use
Session ticket extension should only contain pre-TLS1.3 stateless session
tickets; it should not be used for sending TLS1.3 pre-shared keys.
-
Commit messages:
- Send empty ticket when resuming TLS1.3
Changes: https://git.openjdk.java.net/jdk/pull/8922/files
Webrev:
On Tue, 31 May 2022 13:47:28 GMT, Sean Coffey wrote:
>> Session ticket extension should only contain pre-TLS1.3 stateless session
>> tickets; it should not be used for sending TLS1.3 pre-shared keys.
>
> src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line
> 410:
>
>>
> Session ticket extension should only contain pre-TLS1.3 stateless session
> tickets; it should not be used for sending TLS1.3 pre-shared keys.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
different check for
On Mon, 9 May 2022 19:38:36 GMT, Daniel Jeliński wrote:
> When a TLS server resumes a session from a stateless session ticket, it
> populates the `SSLSessionImpl`'s `localCerts` and `peerCerts` fields with
> certificates deserialized from the session ticket. These certificates are
On Fri, 27 May 2022 13:20:24 GMT, Daniel Jeliński wrote:
> Session ticket extension should only contain pre-TLS1.3 stateless session
> tickets; it should not be used for sending TLS1.3 pre-shared keys.
This pull request has now been integrated.
Changeset: 4662e06b
Author:Daniel Je
On Wed, 8 Jun 2022 05:05:13 GMT, Anthony Scarpino wrote:
> The bug and the PR could have used a lot more description that the issue here
> is that 1.2 and 1.3 are enabled at the same time.
As far as I can tell, 1.2 and 1.3 are both enabled by default.
> One could ask the reverse, if the
I like the idea of implementing certificate compression. Only one
concern: TLS handshakes are generally a CPU-intensive operation, and
certificate compression / decompression will only make it worse. Will
it be possible to compress a certificate once and use it across
multiple handshakes?
nce, and avoid
> duplicate checks.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Avoid nesting SSLAlgorithmConstraints
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8199/files
- new: https://git.openjd
On Wed, 13 Apr 2022 16:02:50 GMT, Xue-Lei Andrew Fan wrote:
>> Thanks @XueleiFan for the review!
>> If we do that, this will result in a behavior change for cases where
>> `enabledX509DisabledAlgConstraints` = false; is that okay? Or should we set
>> `enabledX509DisabledAlgConstraints` = true
On Wed, 27 Apr 2022 14:03:15 GMT, Daniel Jeliński wrote:
> Please review this follow up to #8349.
>
> As JCK pointed out, `permits` is supposed to throw IAE on null input.
> However, now that we're looking up the result in a `ConcurrentHashMap`, a
> `NullPointerExcep
Please review this follow up to #8349.
As JCK pointed out, `permits` is supposed to throw IAE on null input. However,
now that we're looking up the result in a `ConcurrentHashMap`, a
`NullPointerException` is thrown. This patch restores the original behavior.
Verified that the JCK test passes
.
>
> Verified that the JCK test passes with this change.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Move check to permits method
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8427/files
- new: https:/
On Wed, 27 Apr 2022 15:37:27 GMT, Xue-Lei Andrew Fan wrote:
> Maybe, the checking could be placed in permits() method (line 158-173) so
> that it follows the spec, and easier to check.
Good point!
-
PR: https://git.openjdk.java.net/jdk/pull/8427
When a TLS server resumes a session from a stateless session ticket, it
populates the `SSLSessionImpl`'s `localCerts` and `peerCerts` fields with
certificates deserialized from the session ticket. These certificates are often
the same across a large number of tickets.
This patch implements a
On Mon, 9 May 2022 19:38:36 GMT, Daniel Jeliński wrote:
> When a TLS server resumes a session from a stateless session ticket, it
> populates the `SSLSessionImpl`'s `localCerts` and `peerCerts` fields with
> certificates deserialized from the session ticket. These certificates are
97 matches
Mail list logo
