From gnutls-devel at lists.gnutls.org Mon Jun 2 02:24:57 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 02 Jun 2025 00:24:57 +0000 Subject: [gnutls-devel] GnuTLS | Serialise `gnutls_session_t session` (#1712) References: Message-ID: Alistair Francis created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1712 As part of supporting KeyUpdate with ktls-utils/tlshd and the Linux kernel TLS implementation we need a way to save and restore the `gnutls_session_t session`. The idea is to convert the `gnutls_session_t session` to an simple byte array, save that in the kernel keyring and then restore it when required. The existing `gnutls_session_set_data()`/`gnutls_session_get_data()` functions don't save and restore enough state to just call `gnutls_session_key_update()` on the restored session without any other handshake. So the question is, is there a way to serialise the session data and if not is that something I could implement and would be accepted upstream? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1712 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 4 15:13:55 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 04 Jun 2025 13:13:55 +0000 Subject: [gnutls-devel] GnuTLS | Inconsistent/illogical behaviour in GnuTLS server when selecting group for the connection (#1713) References: Message-ID: Alicja Kario (@mention me if you need reply) created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1713 When GnuTLS server receives a connection from a client that advertises modified lists of groups and key shares, the behaviour of the server is not consistent: (* - means that the group was also sent in the key_share) *X25519MLKEM768:SECP256R1MLKEM768 = X25519MLKEM768 (GOOD) X25519MLKEM768:*SECP256R1MLKEM768 = X25519MLKEM768 (not good: not using a sent key_share) X25519MLKEM768:*SECP256R1MLKEM768:X25519:P-256:P-384 = X25519 (BAD: not hybrid) *X25519MLKEM768:*SECP256R1MLKEM768:X25519:*P-256:P-384 = X25519 (BAD: not hybrid) *X25519MLKEM768:SECP256R1MLKEM768:*P-256:P-384 = P-256 (BAD: not hybrid) *SECP256R1MLKEM768:*P-256:P-384 = P-256 (BAD: not hybrid) *SECP256R1MLKEM768:P-256:P-384 = P-256 (BAD: not hybrid and not key_share) *X25519MLKEM768:SecP256r1MLKEM768:SecP384r1MLKEM1024:X25519:secp256r1:X448:secp521r1:secp384r1:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192 = X25519MLKEM768 (GOOD: why?) *X25519MLKEM768:SecP256r1MLKEM768:SecP384r1MLKEM1024:X25519:secp256r1:X448:secp521r1:secp384r1 = X25519 (BAD: not hybrid, but the difference was just omitting FFDHE) OpenSSL fixed this issue by introducing the ``/`` syntax in groups, allowing the user to specify "try to negotiate those groups first, even at a cost of HRR", so for example: ``X25519MLKEM768:SECP256R1MLKEM768:SECP384r1MLKEM1024/X25519:P-256:P-384`` would cause the server to negotiate hybrid post-quantum groups, if at all supported by the client, even if the client did advertise just X25519 key share. The same syntax without ``/`` would negotiate the first group that is in key_shares of ClientHello and is supported by server. The nice thing about this syntax is that allows the user the flexibility to decide if they want to prefer hybrid or pure post-quantum algorithms over classical ones, or if they want to prioritise latency by prioritising key_shares that are already there. If we don't want this level of flexibility, I think the group selection still should at least prefer hybrid post-quantum groups over anything else (at the very least, when they are advertised in key_share) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1713 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 6 10:45:44 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 06 Jun 2025 08:45:44 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS doesn't validate RSA PRIVATE KEY version field (#1714) References: Message-ID: Lucky Roy created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1714 ## Description of problem: rfc8017 shows: "An RSA private key should be represented with the ASN.1 type RSAPrivateKey: RSAPrivateKey ::= SEQUENCE { version Version, modulus INTEGER, -- n publicExponent INTEGER, --e privateExponent INTEGER, -- d prime1 INTEGER, --p prime2 INTEGER, -- q exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) coefficient INTEGER, -- (inverse of q) mod p otherPrimeInfos OtherPrimeInfos OPTIONAL }, and, for version, version is the version number, for compatibility with future revisions of this document. It SHALL be 0 for this version of the document, unless multi-prime is used; in which case, it SHALL be 1." However, here GnuTLS accepts a key with version number 17.[test.zip](/uploads/ccf971bdd6b38410837ddfaebcc008c7/test.zip) ## Version of gnutls used: gnutls-cli 3.7.3 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: Steps to Reproduce: * one:gcc -o gnutls1 gnutls1.c `pkg-config --cflags --libs gnutls` * two:./gnutls1 ## Actual results: Private key loaded successfully ## Expected results: Since the version number is not 0 or 1, it should be rejected -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1714 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 9 10:21:48 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 09 Jun 2025 08:21:48 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS doesn't validate version field when parsing PKCS#8 private key (#1715) References: Message-ID: Lucky Roy created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1715 ## Description of problem: RFC 5958 shows Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2), version identifies the version of OneAsymmetricKey. If publicKey is present, then version is set to v2 else version is set to v1. However, here GnuTLS accepts a key with version number 3, and the attachment is the reproduction file. (In addition, RFC 5208 stipulates that the version number can only be 0.)[test.zip](/uploads/ac4f0f3233edb1e9eabae1580d21df22/test.zip) ## Version of gnutls used: gnutls-cli 3.7.3 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: Steps to Reproduce: * one?gcc -o test3 test3.c `pkg-config --cflags --libs gnutls` * two?./test3 ## Actual results: Accept the key. ## Expected results: Since the version number is 3, it should be rejected. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1715 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 10 12:10:44 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Jun 2025 10:10:44 +0000 Subject: [gnutls-devel] GnuTLS | Draft: record: Allow setting all record state (!1968) References: Message-ID: Alistair Francis created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1968 Project:Branches: alistair23/gnutls:alistair/session-backup to gnutls/gnutls:master Author: Alistair Francis The gnutls_record_get_state() returns a range of data, but the current gnutls_record_set_state() only supports setting seq_number. This patch adds a new gnutls_record_set_state2() function that allows restoring all of the data returned from gnutls_record_get_state(). This is working towards allowing us to support KeyUpdate in ktls-utils with the kernel keyring storing the gnutls session data [1]. This allows us to restore data which we can get from the kernel (which is previously obtained from gnutls_record_get_state()). 1: https://lore.kernel.org/kernel-tls-handshake/49a61a63-db9a-42cd-afa9-3f177400bd86 at suse.de/T/#ma9fb251a756fe427bc474f113572abc5fbe8ddab Signed-off-by: Alistair Francis Based-on: https://gitlab.com/gnutls/gnutls/-/merge_requests/1965 ## Checklist * [X] Commits have `Signed-off-by:` with name/author being identical to the commit author * [X] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [X] Documentation updated / NEWS entry present (for non-trivial changes) * [X] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1968 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 10 12:27:58 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 10 Jun 2025 10:27:58 +0000 Subject: [gnutls-devel] GnuTLS | Draft: record: Allow setting all record state (!1968) In-Reply-To: References: Message-ID: Alistair Francis commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1968#note_2553337861 I wanted to get a feel if [this is generally ok](https://gitlab.com/gnutls/gnutls/-/merge_requests/1968/diffs?commit_id=2622abb4d613f73210a3b65b395b06caf44aa704). If it is I can add some tests and mark this as non-draft -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1968#note_2553337861 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jun 12 00:24:03 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 11 Jun 2025 22:24:03 +0000 Subject: [gnutls-devel] GnuTLS | src/danetool.c: Free str on error to avoid memory leak (!1963) In-Reply-To: References: Message-ID: All discussions on merge request !1963 were resolved by Jiasheng Jiang https://gitlab.com/gnutls/gnutls/-/merge_requests/1963 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1963 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jun 12 14:18:52 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 12 Jun 2025 12:18:52 +0000 Subject: [gnutls-devel] GnuTLS | Gnutls reports an error for the authority_key_id in a CRL file. (#1716) References: Message-ID: One happy person created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1716 ## Description of problem: Hello, I am encountering the following error while parsing a CRL file with GnuTLS: error: gnutls_x509_ext_import_authority_key_id: ASN1 parser: Error in DER parsing. However, when I use OpenSSL to parse this same CRL file, the authority_key_id value is successfully parsed as: keyid:EF:69:E0:F7:D5:1D:E6:99:EC:DC:6D:D0:F7:E2:B9:5C:64:71:83:35. After inspecting the authority_key_id value in the CRL file, I cannot find the source of the problem. Could you please clarify if this is an error in the CRL file itself, or an issue with GnuTLS? ## Version of gnutls used: GnuTLS 3.8.9 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: certtool --crl-info --inder --infile crl_aki_issuer_158_gnutls.der ## Actual results: error: gnutls_x509_ext_import_authority_key_id: ASN1 parser: Value is not valid. ## Expected results: [crl_aki_issuer_158_gnutls.der](/uploads/c2131811558bafec8d141a3ab2600ee1/crl_aki_issuer_158_gnutls.der) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1716 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: