On Mon, 9 Jan 2023 18:38:33 GMT, Volker Simonis wrote:
>> Please clarify that, if the field is updated on one thread under
>> synchronized block, why we will read the correct "currentKeyID" here on
>> another thread if no synchronization is used in this place?
>
>> Please clarify that, if the f
On Mon, 9 Jan 2023 17:34:06 GMT, Sergey Bylokhov wrote:
> Please clarify that, if the field is updated on one thread under synchronized
> block, why we will read the correct "currentKeyID" here on another thread if
> no synchronization is used in this place?
I only said that if another thread
On Mon, 9 Jan 2023 16:12:18 GMT, Volker Simonis wrote:
>> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line
>> 209:
>>
>>> 207: // Package-private, used only from
>>> SessionTicketExtension.KeyState::getCurrentKey.
>>> 208: SessionTicketExtension.StatelessKey
On Tue, 3 Jan 2023 17:43:43 GMT, Volker Simonis wrote:
>> Looks good to me. Thanks!
>
>> Looks good to me. Thanks!
>
> Thanks @XueleiFan!
>
> I've updated the copyright year to 2023 and will wait one or two more days
> just in case @ascarpino wants to take one more look as well.
> Hi @simoni
On Sat, 7 Jan 2023 08:24:42 GMT, Sergey Bylokhov wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updated copyright year to 2023
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line
>
On Sat, 7 Jan 2023 08:26:12 GMT, Sergey Bylokhov wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updated copyright year to 2023
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line
>
On Sat, 7 Jan 2023 08:21:38 GMT, Sergey Bylokhov wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updated copyright year to 2023
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line
>
On Tue, 3 Jan 2023 17:45:12 GMT, Volker Simonis wrote:
>> Currently, TLS session tickets introduced by
>> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
>> `SessionTicketExtension$StatelessKey`) are generated in the class
>> `SessionTicketExtension` and they use a s
On Tue, 3 Jan 2023 17:43:43 GMT, Volker Simonis wrote:
>> Looks good to me. Thanks!
>
>> Looks good to me. Thanks!
>
> Thanks @XueleiFan!
>
> I've updated the copyright year to 2023 and will wait one or two more days
> just in case @ascarpino wants to take one more look as well.
Hi @simonis,
On Mon, 2 Jan 2023 03:05:27 GMT, Xue-Lei Andrew Fan wrote:
> Looks good to me. Thanks!
Thanks @XueleiFan!
I've updated the copyright year to 2023 and will wait one or two more days just
in case @ascarpino wants to take one more look as well.
-
PR: https://git.openjdk.org/jdk/pull
> Currently, TLS session tickets introduced by
> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
> `SessionTicketExtension$StatelessKey`) are generated in the class
> `SessionTicketExtension` and they use a single, global key ID
> (`currentKeyID`) for all `SSLContext`
On Fri, 23 Dec 2022 11:51:32 GMT, Volker Simonis wrote:
>> Currently, TLS session tickets introduced by
>> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
>> `SessionTicketExtension$StatelessKey`) are generated in the class
>> `SessionTicketExtension` and they use a
On Thu, 22 Dec 2022 14:56:16 GMT, Volker Simonis wrote:
>>> The same example with the 1000 connections being opened alternatively on
>>> two different contexts will instead create 1000 `StatelessKey` instances:
>>
>> That's obviously not the expected behaviors. It is a good catch for the
>> `
> Currently, TLS session tickets introduced by
> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
> `SessionTicketExtension$StatelessKey`) are generated in the class
> `SessionTicketExtension` and they use a single, global key ID
> (`currentKeyID`) for all `SSLContext`
On Thu, 22 Dec 2022 19:13:21 GMT, Xue-Lei Andrew Fan wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Moved stateless key logic from SSLContextImpl to SSLSessionContextImpl and
>> addressed comments by @XueleiFan
On Thu, 22 Dec 2022 17:15:36 GMT, Anthony Scarpino
wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Moved stateless key logic from SSLContextImpl to SSLSessionContextImpl and
>> addressed comments by @XueleiFan
On Thu, 22 Dec 2022 18:54:16 GMT, Xue-Lei Andrew Fan wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Moved stateless key logic from SSLContextImpl to SSLSessionContextImpl and
>> addressed comments by @XueleiFan
On Thu, 22 Dec 2022 18:59:14 GMT, Xue-Lei Andrew Fan wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Moved stateless key logic from SSLContextImpl to SSLSessionContextImpl and
>> addressed comments by @XueleiFan
On Thu, 22 Dec 2022 14:56:16 GMT, Volker Simonis wrote:
>>> The same example with the 1000 connections being opened alternatively on
>>> two different contexts will instead create 1000 `StatelessKey` instances:
>>
>> That's obviously not the expected behaviors. It is a good catch for the
>> `
On Thu, 22 Dec 2022 15:00:18 GMT, Volker Simonis wrote:
>> Currently, TLS session tickets introduced by
>> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
>> `SessionTicketExtension$StatelessKey`) are generated in the class
>> `SessionTicketExtension` and they use a
On Thu, 22 Dec 2022 14:56:16 GMT, Volker Simonis wrote:
> For simplicity I've therefor decided to use the `KeyGenerator.init()` method
> which
> doesn't require an extra secure random instance.
I understand the logic, but some users like to use a particular provider,
keygen should use the rand
On Thu, 22 Dec 2022 15:00:18 GMT, Volker Simonis wrote:
>> Currently, TLS session tickets introduced by
>> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
>> `SessionTicketExtension$StatelessKey`) are generated in the class
>> `SessionTicketExtension` and they use a
On Sun, 11 Dec 2022 20:38:16 GMT, Xue-Lei Andrew Fan wrote:
>> Currently, TLS session tickets introduced by
>> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
>> `SessionTicketExtension$StatelessKey`) are generated in the class
>> `SessionTicketExtension` and they us
> Currently, TLS session tickets introduced by
> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
> `SessionTicketExtension$StatelessKey`) are generated in the class
> `SessionTicketExtension` and they use a single, global key ID
> (`currentKeyID`) for all `SSLContext`
On Wed, 21 Dec 2022 22:53:44 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 80:
>>
>>> 78:
>>> 79: protected SessionTicketExtension.StatelessKey getKey() {
>>> 80: SessionTicketExtension.StatelessKey ssk = serverCache.getKey();
On Wed, 21 Dec 2022 22:53:49 GMT, Anthony Scarpino
wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Optimized initialisation of currentKeyID and deletion of expired session
>> keys as proposed by @schlosna
>
> s
On Wed, 21 Dec 2022 20:23:25 GMT, Xue-Lei Andrew Fan wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Optimized initialisation of currentKeyID and deletion of expired session
>> keys as proposed by @schlosna
>
>
On Wed, 21 Dec 2022 20:11:44 GMT, Xue-Lei Andrew Fan wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Optimized initialisation of currentKeyID and deletion of expired session
>> keys as proposed by @schlosna
>
>
On Wed, 21 Dec 2022 20:07:40 GMT, Xue-Lei Andrew Fan wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Optimized initialisation of currentKeyID and deletion of expired session
>> keys as proposed by @schlosna
>
>
On Wed, 21 Dec 2022 19:46:57 GMT, Xue-Lei Andrew Fan wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Optimized initialisation of currentKeyID and deletion of expired session
>> keys as proposed by @schlosna
>
>
On Wed, 21 Dec 2022 19:34:19 GMT, Xue-Lei Andrew Fan wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Optimized initialisation of currentKeyID and deletion of expired session
>> keys as proposed by @schlosna
>
>
On Wed, 21 Dec 2022 15:05:13 GMT, Volker Simonis wrote:
>> Currently, TLS session tickets introduced by
>> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
>> `SessionTicketExtension$StatelessKey`) are generated in the class
>> `SessionTicketExtension` and they use a
On Wed, 21 Dec 2022 20:15:57 GMT, Xue-Lei Andrew Fan wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Optimized initialisation of currentKeyID and deletion of expired session
>> keys as proposed by @schlosna
>
>
On Wed, 21 Dec 2022 15:05:13 GMT, Volker Simonis wrote:
>> Currently, TLS session tickets introduced by
>> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
>> `SessionTicketExtension$StatelessKey`) are generated in the class
>> `SessionTicketExtension` and they use a
> Currently, TLS session tickets introduced by
> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
> `SessionTicketExtension$StatelessKey`) are generated in the class
> `SessionTicketExtension` and they use a single, global key ID
> (`currentKeyID`) for all `SSLContext`
On Wed, 21 Dec 2022 00:10:08 GMT, David Schlosnagle wrote:
>> Volker Simonis has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Some refactoring and simplification. Moved most of the implementation
>> from SessionTicketExtension to SSLSe
On Wed, 21 Dec 2022 00:22:37 GMT, David Schlosnagle wrote:
>> Volker Simonis has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Some refactoring and simplification. Moved most of the implementation
>> from SessionTicketExtension to SSLSe
On Tue, 20 Dec 2022 23:50:15 GMT, Volker Simonis wrote:
>> Currently, TLS session tickets introduced by
>> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
>> `SessionTicketExtension$StatelessKey`) are generated in the class
>> `SessionTicketExtension` and they use a
On Sun, 11 Dec 2022 20:38:16 GMT, Xue-Lei Andrew Fan wrote:
>> Currently, TLS session tickets introduced by
>> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
>> `SessionTicketExtension$StatelessKey`) are generated in the class
>> `SessionTicketExtension` and they us
> Currently, TLS session tickets introduced by
> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
> `SessionTicketExtension$StatelessKey`) are generated in the class
> `SessionTicketExtension` and they use a single, global key ID
> (`currentKeyID`) for all `SSLContext`
On Mon, 12 Dec 2022 10:06:19 GMT, Volker Simonis wrote:
> `encrypt()` will call `getCurrentKey()` which isn't synchronized.
If we think that all that try/catch blocks in the encode/cleanup will save us,
then why we added the sync block around cleanup. But If we try synchronize
work with keys,
On Sun, 11 Dec 2022 23:52:25 GMT, Sergey Bylokhov wrote:
> > You're right, but that's actually an improvement compared to the initial
> > implementation where cleanup/destroy wasn't synchronized at all :)
> > With regards to the missing synchronization of key usage and key
> > destruction, I th
On Sun, 11 Dec 2022 20:38:16 GMT, Xue-Lei Andrew Fan wrote:
> > The same example with the 1000 connections being opened alternatively on
> > two different contexts will instead create 1000 `StatelessKey` instances:
>
> That's obviously not the expected behaviors. It is a good catch for the
> `
On Sun, 11 Dec 2022 16:28:05 GMT, Volker Simonis wrote:
> You're right, but that's actually an improvement compared to the initial
> implementation where cleanup/destroy wasn't synchronized at all :)
> With regards to the missing synchronization of key usage and key destruction,
> I think this
On Thu, 8 Dec 2022 13:09:11 GMT, Volker Simonis wrote:
> Currently, TLS session tickets introduced by
> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
> `SessionTicketExtension$StatelessKey`) are generated in the class
> `SessionTicketExtension` and they use a singl
On Thu, 8 Dec 2022 18:52:31 GMT, Sergey Bylokhov wrote:
> I have asked some of the next questions already
> [here](https://mail.openjdk.org/pipermail/security-dev/2022-December/033797.html).
> Would like to mention some of them;
>
> * The main question I have: is it safe to assume that the
On Thu, 8 Dec 2022 13:09:11 GMT, Volker Simonis wrote:
> Currently, TLS session tickets introduced by
> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
> `SessionTicketExtension$StatelessKey`) are generated in the class
> `SessionTicketExtension` and they use a singl
On Thu, 8 Dec 2022 13:09:11 GMT, Volker Simonis wrote:
> Currently, TLS session tickets introduced by
> [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018) in JDK 13 (i.e.
> `SessionTicketExtension$StatelessKey`) are generated in the class
> `SessionTicketExtension` and they use a singl
48 matches
Mail list logo
