On Wed, 20 Mar 2024 03:39:58 GMT, Martin Balao wrote:
> Hi,
>
> I'd like to propose a fix for "8328556: Do not extract large CKO_SECRET_KEY
> keys from the NSS Software Token". See more details in the JBS ticket [1].
>
> No regressions observed in jdk/sun/security/pkcs11.
>
> Thanks,
> Martin
On Wed, 20 Mar 2024 12:44:55 GMT, Sean Coffey wrote:
>> `useCompatibilityMode` is a client-side setting. See [the
>> spec](https://www.rfc-editor.org/rfc/rfc8446#page-141):
>>> if the client sends a non-empty session ID, the server MUST send the
>>> change_cipher_spec as described in this appen
On Thu, 21 Mar 2024 02:10:35 GMT, Prasadrao Koppula
wrote:
>> test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 98:
>>
>>> 96:
>>> 97: // client consumes ServerHello/HelloRetryRequest
>>> 98: clientResult = clientEngine.unwrap(sTOc, clientIn);
>>
>> May be it w
On Thu, 21 Mar 2024 02:03:39 GMT, Prasadrao Koppula
wrote:
>> JDK server does not send a dummy change_cipher_spec record after
>> HelloRetryRequest message.
>>
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a
>> non-empty session ID in the ClientHello message, th
On Thu, 21 Mar 2024 02:23:20 GMT, Prasadrao Koppula
wrote:
>> test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 253:
>>
>>> 251: }
>>> 252:
>>> 253: private static void log(String str) {
>>
>> I suggest method `log` accepts `String...` instead of `String`.
>> This method can c
On Wed, 20 Mar 2024 16:32:30 GMT, John Jiang wrote:
>> Prasadrao Koppula has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8326643
>
> test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 253:
>
>> 251: }
>> 252:
>> 253:
On Wed, 20 Mar 2024 10:49:55 GMT, Sibabrata Sahoo wrote:
>> Prasadrao Koppula has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8326643
>
> test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 98:
>
>> 96:
>> 97: //
On Wed, 20 Mar 2024 15:56:22 GMT, John Jiang wrote:
>> Prasadrao Koppula has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8326643
>
> test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 280:
>
>> 278: log("= " +
> JDK server does not send a dummy change_cipher_spec record after
> HelloRetryRequest message.
>
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a
> non-empty session ID in the ClientHello message, the server sends a dummy
> change_cipher_spec (CCS) record immediate
On Wed, 20 Mar 2024 11:55:36 GMT, Sean Coffey wrote:
>> Prasadrao Koppula has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8326643
>
> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 802:
>
>> 800: // a
> JDK server does not send a dummy change_cipher_spec record after
> HelloRetryRequest message.
>
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a
> non-empty session ID in the ClientHello message, the server sends a dummy
> change_cipher_spec (CCS) record immediate
> Please review the proposed fix.
>
> The patch loads system root certificates from the MacOS Keychain with
> TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store
> only.
Alexey Bakhtin has refreshed the contents of this pull request, and previous
commi
On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang wrote:
> This code change adds an alternative implementation of user-based
> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
> Depending on if the Security Manager is allowed, the methods store the
> current subject diffe
> Please review the proposed fix.
>
> The patch loads system root certificates from the MacOS Keychain with
> TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store
> only.
Alexey Bakhtin has updated the pull request incrementally with one additional
comm
On Tue, 19 Mar 2024 14:01:14 GMT, Sean Mullan wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Load root certificates from SystemRootCertificates.keychain
>
> Is it practical to add a test as described in the bug?
On Wed, 20 Mar 2024 14:45:50 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject d
See the rationale/discussion in the bug. This patch introduces the option that
allows to restore
pre-[JDK-8179503](https://bugs.openjdk.org/browse/JDK-8179503) behavior. The
default behavior does not change.
Additional testing:
- [x] `jdk_security` passes (includes new test config)
--
On Tue, 19 Mar 2024 15:23:39 GMT, rebarbora-mckvak wrote:
>> This fixes the defect described at
>> https://bugs.openjdk.org/browse/JDK-8313367
>>
>> If the process does not have write permissions, the store is opened as
>> read-only (instead of failing).
>>
>> Please note that permissions to
On Wed, 20 Mar 2024 09:55:34 GMT, Prasadrao Koppula
wrote:
>> JDK server does not send a dummy change_cipher_spec record after
>> HelloRetryRequest message.
>>
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a
>> non-empty session ID in the ClientHello message, th
On Wed, 20 Mar 2024 09:55:34 GMT, Prasadrao Koppula
wrote:
>> JDK server does not send a dummy change_cipher_spec record after
>> HelloRetryRequest message.
>>
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a
>> non-empty session ID in the ClientHello message, th
On Wed, 20 Mar 2024 14:45:50 GMT, Weijun Wang wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store the
>> current subject d
> This code change adds an alternative implementation of user-based
> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
> Depending on if the Security Manager is allowed, the methods store the
> current subject differently. See the spec change in the `Subject.java` file
On Wed, 20 Mar 2024 09:55:34 GMT, Prasadrao Koppula
wrote:
>> JDK server does not send a dummy change_cipher_spec record after
>> HelloRetryRequest message.
>>
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a
>> non-empty session ID in the ClientHello message, th
On Wed, 20 Mar 2024 12:31:02 GMT, Daniel Jeliński wrote:
>> just see this comment regards `useCompatibilityMode` - I'd a similar
>> concern. shouldn't useCompatibilityMode be checked no matter what value we
>> get for `clientHello.sessionId.length() `?
>
> `useCompatibilityMode` is a client-sid
On Wed, 20 Mar 2024 12:05:47 GMT, Sean Coffey wrote:
>> Got it. Thanks.. CH legacy_session_id uses this check for non-empty
>> sessionId.
>
> just see this comment regards `useCompatibilityMode` - I'd a similar concern.
> shouldn't useCompatibilityMode be checked no matter what value we get for
On Wed, 20 Mar 2024 10:03:22 GMT, Sibabrata Sahoo wrote:
>> (clientHello.sessionId.length() != 0) condition checks for same
>
> Got it. Thanks.. CH legacy_session_id uses this check for non-empty sessionId.
just see this comment regards `useCompatibilityMode` - I'd a similar concern.
shouldn't
On Wed, 20 Mar 2024 09:55:34 GMT, Prasadrao Koppula
wrote:
>> JDK server does not send a dummy change_cipher_spec record after
>> HelloRetryRequest message.
>>
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a
>> non-empty session ID in the ClientHello message, th
On Wed, 20 Mar 2024 09:55:34 GMT, Prasadrao Koppula
wrote:
>> JDK server does not send a dummy change_cipher_spec record after
>> HelloRetryRequest message.
>>
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a
>> non-empty session ID in the ClientHello message, th
On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang wrote:
>> This task addresses an essential aspect of our testing infrastructure: the
>> proper handling and cleanup of temporary files and socket files created
>> during test execution. The motivation behind these changes is to prevent the
>> accumu
On Wed, 20 Mar 2024 09:59:14 GMT, Prasadrao Koppula
wrote:
>> I am not an expert in this field and expressing one of my thought here and
>> my assumption could be wrong too.
>> Shouldn't it check "SSLConfiguration.useCompatibilityMode" or similar for
>> any change applicable to solve middlebox
On Wed, 20 Mar 2024 09:52:40 GMT, Sibabrata Sahoo wrote:
>> Yes, the server produces 2 CCS records in the case of HRR. According to RFC:
>>
>> "Either side can send change_cipher_spec at any time during the handshake,
>> as they must be ignored by the peer, but if the client sends a non-empty
> JDK server does not send a dummy change_cipher_spec record after
> HelloRetryRequest message.
>
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a
> non-empty session ID in the ClientHello message, the server sends a dummy
> change_cipher_spec (CCS) record immediate
On Wed, 20 Mar 2024 09:33:56 GMT, Prasadrao Koppula
wrote:
>> Will it produce 2 ChangeCipherSpec record. One after HRR and other after SH?
>
> Yes, the server produces 2 CCS records in the case of HRR. According to RFC:
>
> "Either side can send change_cipher_spec at any time during the handsha
On Wed, 20 Mar 2024 09:25:35 GMT, Sibabrata Sahoo wrote:
>> Thanks for the review, in the comments I mentioned that, this call sends a
>> dummy change_cipher_spec (CCS) record. I hope, It explains why we are
>> calling it here.
>
> Will it produce 2 ChangeCipherSpec record. One after HRR and o
On Wed, 20 Mar 2024 08:48:34 GMT, Prasadrao Koppula
wrote:
>> JDK server does not send a dummy change_cipher_spec record after
>> HelloRetryRequest message.
>>
>> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a
>> non-empty session ID in the ClientHello message, th
On Wed, 20 Mar 2024 08:26:58 GMT, Prasadrao Koppula
wrote:
>> Thanks for adding the test.
>>
>> My main concern with using changeWriteCiphers here is that it sends the
>> wrong message to the future readers of this code. It suggests that we want
>> to actually change the cipher, and sending C
> any recommendation or example of this kind of work?
Check out these JEPs, the description section:
https://openjdk.org/jeps/329
https://openjdk.org/jeps/8245551
https://openjdk.org/jeps/8281710
In the PSK case the main question is, how is the user going to
configure the keys?
Cheers,
Daniel
wt
> JDK server does not send a dummy change_cipher_spec record after
> HelloRetryRequest message.
>
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a
> non-empty session ID in the ClientHello message, the server sends a dummy
> change_cipher_spec (CCS) record immediate
On Wed, 20 Mar 2024 08:13:14 GMT, Daniel Jeliński wrote:
>>>
>>
>> IMO, utilizing shc.conContext.outputRecord.changeWriteCiphers() is a cleaner
>> approach, and we've used the same method in other instances.
>
> Thanks for adding the test.
>
> My main concern with using changeWriteCiphers her
On Wed, 20 Mar 2024 07:44:01 GMT, Prasadrao Koppula
wrote:
>> Thank you, I added a test
>
>>
>
> IMO, utilizing shc.conContext.outputRecord.changeWriteCiphers() is a cleaner
> approach, and we've used the same method in other instances.
Thanks for adding the test.
My main concern with using
> JDK server does not send a dummy change_cipher_spec record after
> HelloRetryRequest message.
>
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a
> non-empty session ID in the ClientHello message, the server sends a dummy
> change_cipher_spec (CCS) record immediate
On Wed, 20 Mar 2024 07:36:29 GMT, Prasadrao Koppula
wrote:
>> since [JDK-8281236](https://bugs.openjdk.org/browse/JDK-8281236) /
>> 5d4c71c8bd361af78c90777f17b79e95d8eb5afe / JDK 20 we have setNamedGroups
>> function to control named groups on every endpoint.
>
> Thank you, I added a test
>
> JDK server does not send a dummy change_cipher_spec record after
> HelloRetryRequest message.
>
> According to RFC 8446 (Middlebox Compatibility Mode), if the client sends a
> non-empty session ID in the ClientHello message, the server sends a dummy
> change_cipher_spec (CCS) record immediate
On Tue, 19 Mar 2024 09:03:57 GMT, Daniel Jeliński wrote:
>> Unfortunately, we lack separate properties to control named groups in both
>> the server and client. When running server and client threads in the same
>> JVM, manipulating client hello packets to prompt the server to trigger HRR
>> b
44 matches
Mail list logo
