to vsftpd as well).
https://github.com/openssl/openssl/issues/17948
Gruß
Bernd
Bernd Eckenfels wrote on 29. June 2025 15:27 (GMT +02:00):
> We deal with a regression in JSSE regarding resumption tickets with high
> lifetime.
> In older versions with Java 11 the customer claimed a FTP S
et our hands on a working trace, we are not sure where
the regression is (that MAX_TICKET_LIFETIME seems to be introduced before the
11 Version and therefore is not the direct reason), has someone an idea, or
observed this as well?
Gruß
Bernd
—
https://bernd.eckenfels.net
leartext parameter next to the P12 file anyway making the protection not
even useful.
Gruß
Bernd
-
PR Comment: https://git.openjdk.org/jdk/pull/17956#issuecomment-2828686759
On Mon, 27 Jan 2025 22:43:32 GMT, Tim Jacomb wrote:
>> ## The change
>>
>> Without this change intermediate certificates that don't have explicit trust
>> settings are ignored not added to the truststore.
>>
>>
>>
>> ## Reproducer
>>
>> See https://github.com/timja/openjdk-intermediate-ca-r
On Tue, 11 Mar 2025 21:14:16 GMT, Weijun Wang wrote:
> usually determined by the key type.
Hm, might be a bit more complicated for PQ/T Hybrid KEMs. It can of course be
added later on, as the implementations using that (like Xwing for HPKE with
JOSE) are still in draft state.
-
P
configured. (But we also have a list where we can put TLS_RSA on. SHA1 handshakes are already on there)GreetingsBernd -- https://bernd.eckenfels.net From: Sean Mullan Sent: Thursday, February 27, 2025 8:57 PMTo: Bernd ; security-dev@openjdk.org Subject: Re: 8245545: TLS_RSA roadmap Hi Bernd,
On 2/27/25
Hello,Just noticed you plan to disable TLS_RSA ciphers in 2026. I wonder there are some Legacy entries which are both disabled and marked as Legacy, but some are only disabled.Is there a plan to this? I would expect TLS_RSA to be more likely to be re-enabled, so maybe it should be delivered on the
On Fri, 14 Feb 2025 16:43:32 GMT, Ben Perez wrote:
> It turns out that initializing a multidimensional array with `int[][] a = new
> int[rows][cols]` is slower than allocating each column in a loop. Since we do
> a lot of large multidimensional array allocations in ML-DSA, the optimized
> init
On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh wrote:
> This fix makes some minor changes to the internals of the
> `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break
> when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS
> works better now with thes
On Thu, 2 Jan 2025 14:41:48 GMT, Sean Mullan wrote:
> Periodically, we review the security algorithm requirements to see if new
> algorithms should be added or existing ones should be removed. The
> requirements are intended to improve interoperability across different SE
> implementations by
Hello,I agree that this duplication is quite confusing (I tried to find out before why it’s shipped and if it is related to keycache format, since the native tools in Windows are a bit tricky to understand in that regard if I remember my struggles correctly).So before removing it
On Mon, 23 Sep 2024 20:21:53 GMT, Artur Barashev wrote:
>> https://bugs.openjdk.org/browse/JDK-8331682
>
> Artur Barashev has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Spell user_canceled instead of user_cancelled as per RFC
Can’t review
On Sat, 21 Sep 2024 00:37:51 GMT, Artur Barashev wrote:
> It was an encrypted message while client expected a plaintext, we weren't
> misled by `plaintext` in the exception message.
In that case the title of the issue is wrong. (And also the message of the
exception does not match „it was encr
On Thu, 19 Sep 2024 21:33:11 GMT, Artur Barashev wrote:
>> https://bugs.openjdk.org/browse/JDK-8331682
>
> Artur Barashev has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add assertions. Add the final server wrap
Sorry the review dropped my
On Thu, 19 Sep 2024 21:33:11 GMT, Artur Barashev wrote:
>> https://bugs.openjdk.org/browse/JDK-8331682
>
> Artur Barashev has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add assertions. Add the final server wrap
See the actual comment at t
On Thu, 11 Apr 2024 13:01:36 GMT, Weijun Wang wrote:
> [One of the
> test](https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/mscapi/VeryLongAlias.java)
good link, thanks. Didn’t know the type is even visible for an assert.
-
PR Comment: https://git.openjdk.org/jdk/
On Wed, 10 Apr 2024 21:10:16 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 Fri, 22 Mar 2024 22:25:47 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
gt;>
>> On a related note, I think the current TLS logging is too verbose at the
>> moment. Over 3,500 lines of output are generated before a ClientHello
>> gets
>> created in a typical TLS debug capture. It's too much. Most of it is
>> iterating over certs found in the truststore (cacerts by default). Need
>> to
>> log a bug on that.
>>
>> regards,
>> Sean.
>>
>
Gruß
Bernd
—
https://bernd.eckenfels.net
On Thu, 7 Mar 2024 11:57:07 GMT, Sean Coffey wrote:
>> Proposal to improve the `java.security.debug` output so that options exist
>> to add thread ID, thread name, source of log record and a timestamp
>> information to the output.
>>
>> examples:
>> format without patch :
>>
>>
>> properties
On Fri, 1 Mar 2024 15:13:49 GMT, Sean Coffey wrote:
> Proposal to improve the `java.security.debug` output so that options exist to
> add thread ID, thread name, source of log record and a timestamp information
> to the output.
>
> examples:
> format without patch :
>
>
> properties: Initial
On Wed, 31 Jan 2024 20:07:28 GMT, John Jiang wrote:
>> If the server doesn't receive the client certificate for required client
>> authentication, it should raise error `Empty client certificate chain`.
>
> John Jiang has updated the pull request incrementally with one additional
> commit since
On Thu, 11 Jan 2024 13:33:54 GMT, John Jiang wrote:
> ECDHKeyAgreement should validate the parameters before assigning them to the
> fields.
test/jdk/sun/security/ec/ECDHKeyAgreementParamValidation.java line 90:
> 88: KeyAgreement ka = KeyAgreement.getInstance("ECDH");
> 89: ka
eady support PQC keys?
Gruß
Bernd
—
https://bernd.eckenfels.net
You would need to publish your code that somebody can debug it.GreetingsBernd-- http://bernd.eckenfels.net
Von: Filip Petr. Gesendet: Freitag, September 1, 2023 6:02 PMAn: security-dev@openjdk.org ; e...@zusammenkunft.net Betreff: Re: Modification of Client hello
s there is no hex trace in there, so it’s hard to debug). The extension is your custom code, right?GrussBernd
-- http://bernd.eckenfels.net
Von: security-dev im Auftrag von Bernd Gesendet: Freitag, September 1, 2023 4:12 PMAn: Filip Petr. ; security-dev@openjdk.org Betreff: Re: Modif
If it’s an alert from the server it’s not your Java program which „spots the unusual extension“. It’s more like your custom extensions sent are not correct to the servers interpretation. Did you maybe hardcode signatures or such?GrussBernd-- http://bernd.eckenfels.net
Hello,Can you confirm, you say the alert is coming from a non-java server, or are you saying your modified handshake is rejected by a Java server? (Or do you think the alert is not received?).I would turn on ssl debug logging and upload the traces to a gist sharing side so
On Tue, 11 Jul 2023 18:09:26 GMT, Craig Andrews wrote:
> When loading the default JVM trust store, if the JVM trust store contains an
> invalid certificate, the exception contains insufficient information to
> determine which certificate is invalid, making it very difficult to fix the
> proble
If you return the short buffer (on IOException), does it need to cache the pending exception or can you just rely on the next read hitting that underlying exception again? (Is there an actual guarantee somewhere that the read position is not altered on IOExceptions or that
Good to hear that plan,I wonder are there also special considerations for password based algorithms? One of the major annoyances are the different encoding formats (mostly about bytes derived from strings, maybe padding). Would be good if this can be an parameter.In regard
I don’t see the big advantage of changing the dir security property to avoid changing other security property. It would be good if I don’t have to modify the system.properties file, for example by always adding a etc/security.custom.properties file if present, instead. Th
On Wed, 7 Jun 2023 19:53:26 GMT, Ben Perez wrote:
>> test/jdk/sun/security/provider/DSA/SecureRandomReset.java line 51:
>>
>>> 49:
>>> 50: // Re-initialize deterministic RNG and sign
>>> 51: s.initSign(sk, deterministic());
>>
>> Does this test depend on the fact that if the re
On Thu, 1 Jun 2023 21:17:11 GMT, Ben Perez wrote:
> Fixed `engineInitSign` in `DSA.java` and added `SecureRandomReset.java` to
> DSA tests
test/jdk/sun/security/provider/DSA/SecureRandomReset.java line 51:
> 49:
> 50: // Re-initialize deterministic RNG and sign
> 51: s.initSig
On Fri, 26 May 2023 21:09:35 GMT, Mat Carter wrote:
> Added ability to load keystores from SST files on Windows. Example usage:
>
> KeyStore keyStore = KeyStore.getInstance("Windows-SST");
> try (FileInputStream fis = new FileInputStream("mykeystore.sst")) {
>keyStore.load(fis, null);
> }
>
If you can open it readonly, why not do it without any special name and only fail the write operation? Or maybe have a truststore mode, which does not have to open keys?GrussBernd-- http://bernd.eckenfels.net
Von: security-dev im Auftrag von Mat Carter Gesendet:
Not sure what exactly is cached, but for CRL only the latest CRL version should be cached and only for its lifetime (refresh time). Also, CRLs get quite large, is it compressing the entire it caches?
-- https://bernd.eckenfels.net
From: security-dev on beh
likely is expected to involves KDF from the (generic) shared secret anyway. Or explicite wrapping. So, sounds good to me. Thanks for clarifying.GrussBernd
-- http://bernd.eckenfels.net
Von: Wei-Jun Wang Gesendet: Dienstag, März 7, 2023 10:02 PMAn: Bernd Cc: security-...@openjdk.java.net
Will „Generic“ work with ciphers which need „raw“, or is that intentionally not the case?Btw I like the simplification.GrussBernd -- http://bernd.eckenfels.net
Von: security-dev im Auftrag von Wei-Jun Wang Gesendet: Freitag, März 3, 2023 6:31 PMAn: security-...@
On Wed, 25 Jan 2023 22:33:59 GMT, Valerie Peng wrote:
>> This RFE enhances existing PBE algorithms with the "SHA512/224" and
>> "SHA512/256" support.
>> Current transformation parsing in javax.crypto.Cipher class is re-written to
>> handle the additional "/" in the "SHA512/224" and "SHA512/256
{
Would be nice if somebody could open a bug for it. I think it's not worth
sponsoring a change from me for that.
Greetings
Bernd
--
http://bernd.eckenfels.net
On Wed, 14 Dec 2022 00:23:44 GMT, Valerie Peng wrote:
>> This RFE enhances existing PBE algorithms with the "SHA512/224" and
>> "SHA512/256" support.
>> Current transformation parsing in javax.crypto.Cipher class is re-written to
>> handle the additional "/" in the "SHA512/224" and "SHA512/256
On Wed, 14 Dec 2022 00:23:44 GMT, Valerie Peng wrote:
>> This RFE enhances existing PBE algorithms with the "SHA512/224" and
>> "SHA512/256" support.
>> Current transformation parsing in javax.crypto.Cipher class is re-written to
>> handle the additional "/" in the "SHA512/224" and "SHA512/256
On Mon, 14 Nov 2022 16:37:41 GMT, Xubo Zhang wrote:
>> NativePRNG SecureRandom doesn’t scale with number of threads. The
>> performance starts dropping as we increase the number of threads. Even going
>> from 1 thread to 2 threads shows significant drop. The bottleneck is the
>> singleton Rand
On Thu, 3 Nov 2022 14:59:59 GMT, Sean Mullan wrote:
> This change will disable TLS_ECDH_* cipher suites by default. These cipher
> suites do not preserve forward secrecy and are rarely used in practice. See
> the CSR for more details and rationale.
>
> Users will still be able to enable the su
Hello Carter,Thanks for the clarification. I agree there is code out there using large buffers to write to encrypting output streams, it’s just a question how often. If the internal chunking does not affect the more typical smaller chunk writers it might be worthwhile.But
Hello,good that you look into that topic. While it might not be a problem in practice (large buffers are ok, but larger than 1mb seems seldom, especially in multi threaded apps) it is still a condition which can be handled. But with AE ciphers becoming the norm, such large
On Thu, 1 Sep 2022 23:55:03 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java line
>> 75:
>>
>>> 73: * field is returned in its string format as a series of nonnegative
>>> 74: * integers separated by periods (For example, "1.3.14.7.2.1
On Thu, 1 Sep 2022 23:50:47 GMT, Weijun Wang wrote:
>> Since the algorithm is already encoded inside a PKCS #8 data block, it is
>> not necessary to provide an algorithm when a `PKCS8EncodedKeySpec` object is
>> created. The same for `X509EncodedKeySpec`.
>
> Weijun Wang has updated the pull re
BTW, after then ensures it looks like a good candidate for a system-assert for
not-null for all of those fields, right?
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von Andrey
Turbanov
Gesendet: Thursday, September 1, 2022 8:24:58 AM
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 "
.
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
Hello,
there is a longstanding issue in the PostgreSQL JDBC driver which reads
secret keys in PKCS#8 format, but does not support the newer PKCS#5 2.0
(PBES2) modes (-v1 works). The (naive) code is here:
pgjdbc/LazyKeyManager.java at 80d4ed34c99d51dd8b06df00baad0265fd620fec ·
pgjdbc/pgjdbc · GitH
53 matches
Mail list logo
