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: From gnutls-devel at lists.gnutls.org Fri Jun 13 13:44:27 2025 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 13 Jun 2025 11:44:27 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_session_t unsafe to use from multiple threads due to TLS 1.3 rekeying (#1717) References: Message-ID: Daniel P_ Berrang? created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1717 ## Description of problem: Note, this bug reports comes out of a QEMU bug we've been struggling to resolve for a few years https://gitlab.com/qemu-project/qemu/-/issues/1937 I've also seen https://gitlab.com/gnutls/gnutls/-/issues/1567 talking about SEGVs, which may well ultimately be the same problem as this bug. I've never managed to create any SEGV in my own testing though, only error return codes. The GNUTLS docs about thread safety have a list of conditions which, if satisfied, are expected to allow a `gnutls_session_t` object to be used for concurrent I/O from 2 threads (ie for parallel `gnutls_record_send` & `gnutls_record_recv`, but **nothing** else): https://gnutls.org/manual/gnutls.html#Thread-safety AFAICT, even if an application follows that guidance, usage of `gnutls_session_t` from 2 threads for concurrent send & recv remains unsafe by default. At the very least this appears always unsafe if TLS 1.3 is negotiated for the connection, I've not checked if older TLS protocol versions are similarly impacted by default. In my testing any TLS 1.3 rekeying message sent **or** received, will corrupt the internal session state if there are concurrent send & recv operations taking place in separate threads. If the application sets `GNUTLS_NO_AUTO_REKEY` on their `gnutls_session_t` object, that will merely prevent *their end* of the connection *initiating* a rekey operation. The remote peer may still initiate a rekey operation, either automatically or manually. In addition the rekey request from the remote peer, might have set the flag to require the local peer to initiate its own rekey for the other direction of the channel. IOW setting `GNUTLS_NO_AUTO_REKEY` is insufficient to prevent rekeying in either direction on a TLS 1.3 session. As an alternative an application could arrange for `CHACHA20-POLY1305` to be the only listed algorithm in the priority string, since that algorithm does not require automatic rekeying. The problem with this is that there's no guarantee the remote peer will support this - only `AES-128` is mandated by the RFC IIUC, or an admin defined priority string on the remote peer may prevent `CHACHA20-POLY1305` being offered. Lets assume the handshake does negotiate `CHACHA20-POLY1305`, such that auto-rekeying is not required. This is still not sufficient to guarantee that an application's usage of `gnutls_session_t` from multiple threads for send & recv is safe. The remote implementation may have (redundantly) enabled auto-rekeying for `CHACHA20-POLY1305`, or the remote peer's application code could initiate a manual rekeying at any time regardless of cipher choice. AFAICT, the only way to safely use `gnutls_session_t` for concurrent I/O from two threads is to have an application level mutex acquired & released around `gnutls_record_send` and `gnutls_record_recv` calls, but that has problems which make it suboptimal: * It eliminates concurrency entirely defeating the point of using 2 threads * It entirely prevents all progress if one thread sits in a blocking `gnutls_record_recv` while wanting to also call `gnutls_record_send` To mitigate the second problem there are two options * Use poll() to detect readability/writability before calling gnutls_record_send/recv, so they (hopefully) don't block. * Register custom push/pull functions which then release + reaquire the mutex either side of the recv/send sockets syscalls. The second option would rely on GNUTLS' concurrency problems being confined to exclusively **after** the syscall completes, or exclusively **before** the syscall is invoked. If there is anything in GNUTLS rekey process which relies on state being maintained across the OS syscall, then this release+reacquire dance would still be potentially unsafe. My testing so far though, hasn't exposed a problem with release+reacquire dance inside the push+pull functions. Both mitigations share the problem, however, that the application mutex is preventing any concurrency on the cipher operations. Even with hardware accelerated AES, cipher operations can be a performance bottleneck, so neither are really viable workarounds if needing to maximise concurrency in the general case. Conceptually I also don't like the idea of setting GNUTLS_NO_AUTO_REKEY as that is disabling a cryptographic security recommendation from the TLS 1.3 RFC, and thus not rekeying could be considered a security bug / CVE in any app that does that. AFAICT, the only way to fix this without impacting concurrency/performance, is for GNUTLS to have its own private mutex(es) or rw-lock to protect its internal session state across the rekey handling, when there are concurrent send/recv operations taking place. ## Version of gnutls used: Fedora build of 3.8.9 and upstream git master build of af6a39894e0dc8e1dd3f9690f7fc011d0ffe86b5 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Fedora and Upstream. ## How reproducible: Non-deterministic frequency, but will always eventually hit when TLS 1.3 is negotiated and concurrent `gnutls_record_{send,recv}` calls are made from 2 threads. Steps to Reproduce: Use the following demo program which acts as both a single threaded server and two-threaded client (one send, one recv) [tlsrekey.c](/uploads/d9a9465521cc287814085ec4e49b9fd3/tlsrekey.c) A default build of it will operate correctly, since all rekeying is disabled on server and client. To demonstrate the flaw with client initiated auto-rekeying ``` $ gcc -g -Wall -lgnutls -o tlsrekey tlsrekey.c -DCLIENT_AUTO_REKEY $ ./tlsrekey 1569408: client sender 1569407: client receiver 1569409: server echo 1569408: send: The specified session has been invalidated for some reason. 1569407: recv: Decryption has failed. ``` This shows the client gnutls_record_send() call failing with invalid session, and the client gnutls_record_recv() call failing with bad decryption. It suggests the client's automatic rekey has corrupted its own session state To demonstrate the flaw with server initiated auto-rekeying ``` $ gcc -g -Wall -lgnutls -o tlsrekey tlsrekey.c -DSERVER_AUTO_REKEY $ ./tlsrekey 1569654: client receiver 1569655: client sender 1569656: server echo 1569656: echo recv: Decryption has failed. ``` This shows the server gnutls_record_recv() call failing with bad decryption. The server is single threaded, however, so this is not a server flaw. It suggests the threaded client has sent bad data after receiving the server's rekey operation. To demonstrate the flaw with server initiated manual rekeying ``` $ gcc -g -Wall -lgnutls -o tlsrekey tlsrekey.c -DSERVER_MANUAL_REKEY $ ./tlsrekey 1569673: client receiver 1569674: client sender 1569675: server echo 1569675: echo recv: Decryption has failed. ``` This shows the same behaviour as the server auto-rekeying, likely triggering client session state corruption. Note the response to server rekeying is somewhat non-deterministic - it often takes many rekeying requests from the server before the client goes wrong. IME, frequency of problems can be improved with ``GNUTLS_DEBUG_LEVEL=5`` since that tweaks the timing of the race. In testing auto-rekeying failures, I advise making it rekey more often than every 16 million records to speed things up. The following patch does that, and also adds some printfs which make the race hit more frequently (less verbose that using ``GNUTLS_DEBUG_LEVEL`` for this purpose): [rekey-faster.patch](/uploads/d34e69334e51db76ad0e96ddd23e328a/rekey-faster.patch) When building the test program `-DLOCK` and `-DUNLOCK_IO` can be defined to implement the workarounds discussed above and show that GNUTLS no longer corrupts its state. As mentioned though, these workarounds harm concurrency of I/O and/or cipher operations. ## Actual results: `gnutls_record_recv` and `gnutls_recv_send` called concurrently from 2 threads, will periodically fail when a TLS 1.3 rekeying operation is performed, whether initiated by the local or remote peer, whether automatic or manually initiated by the remote peer. ## Expected results: `gnutls_record_recv` and `gnutls_recv_send` can be safely called concurrently from 2 threads, provided they are the only GNUTLS APIs used (as per https://gnutls.org/manual/gnutls.html#Thread-safety) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1717 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: