RE: https://mamot.fr/@smortex/116219434637755665
Request for help
I am stuck trying to identify the root cause of an issue with a program using #GnuTLS to communicate with a #Java service. It stopped working last summer when updating from OpenJDK 17.0.16+8-1 to 17.0.17~5ea-1 (Debian 12 packages). It also fail with all newer versions of OpenJDK.
I am not sure if this is caused by a misuse of the GnuTLS API, a regression in OpenJDK or an issue with GnuTLS itself.
Boosts appreciated! Thanks!
1/6
I'm investigating a regression that appeared after upgrading #OpenJDK in a setup where #syslog_ng communicates with a #Riemann server (a Java application).
My investigation led me to a C library (riemann-c-client, used by syslog-ng) that uses #GnuTLS to establish a mutually authenticated TLS connection to the Java service. The library provides a CLI utility that allows me to reproduce the problem, which suggests that the issue lies in this library rather than in syslog-ng itself.
If you're using #GnuTLS please note that GnuTLS defaults to weak security profile:
"The message authenticity security level is of 64 bits or more, and the certificate verification profile is set to GNUTLS_PROFILE_LOW (80-bits)."
This means for example that Diffie-Hellman group size of 1024-bits is allowed. This was deemed insufficient already 10 years ago. See https://weakdh.org/
This issue will be remedied in future GnuTLS release. Meanwhile the fix is to inject %PROFILE_MEDIUM as part of the priority string, for example "NORMAL:foo" becomes "NORMAL:%PROFILE_MEDIUM:foo". See https://gnutls.org/manual/html_node/Priority-Strings.html for details.
It's not just @bagder who gets incorrect bug reports generated by #AI for #curl. This time, it's #GnuTLS at https://gitlab.com/gnutls/gnutls/-/issues/1711.
What a waste of time :/
Description of problem: During testing of GnuTLS certificate verification, we observed that gnutls-cli accepts a server certificate whose Common Name (CN)...
#apt-listchanges: News
---------------------
#curl (8.13.0-2) unstable; urgency=medium
The curl #CLI is now back to using #OpenSSL, instead of #GnuTLS:
HTTP/3 support is still there, compared to the GnuTLS curl CLI.
The performance of HTTP/3 on OpenSSL is not as good, but it's also not used
by default.
-- Samuel Henrique <[email protected]> Sun, 06 Apr 2025 22:13:18 +0100
📰 Apareceram notícias sobre o pacote curl, ao atualizá-lo hoje no #Debian #sid (unstable) e que achei interessantes compartilhar. É o anúncio de alterações importantes, aparentemente entrando em efeito agora e iniciadas alguns meses atrás pelos mantenedores, em suma:
Romain Tartière
Harry Sintonen
openSUSE Linux
Alexander Sosedkin 
Clemens
Vitex
wolfSSL Embedded SSL/TLS; FIPS 140-3
Daltuxcurl, a partir da versão 8.8.0-2, passa a suportar HTTP/3, com os parâmetros --http3 ou --http3-only. Para conseguir isso, o programa agora passa a utilizar GnuTLS no lugar de OpenSSL. Ainda fornecerão uma variação de libcurl que continua usando OpenSSL.wcurl (veja seu manual) que facilita baixar um arquivo sem precisar lembrar os parâmetros do curl. Pode ser chamado no lugar dos usos mais simples de wget.#BSI WID-SEC-2025-0302: [NEU] [UNGEPATCHT] [mittel] #GnuTLS: Schwachstelle ermöglicht Denial of Service
Ein entfernter, anonymer Angreifer kann eine Schwachstelle in GnuTLS ausnutzen, um einen Denial of Service Angriff durchzuführen.
https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2025-0302
BSI WID Advisories Feed