#gnutls — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #gnutls, aggregated by home.social.
-
I'm clearly old and stupid. I can't figure out how to submit an issue for #GnuTLS on their gitlab anymore. (I did in the past.)
So here it comes instead: gnutls_certificate_verify_peers2() does not seem to verify ExtendedKeyUsage but gnutls_certificate_verify_peers() does.
Neither case is documented clearly. This has already lead to people submitting vuln reports to gnutls-using apps for this omission.
-
🚨 CVE-2026-45185 (Dead.Letter)
Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.
ℹ️ Additional info on ZEN SecDB https://secdb.nttzen.cloud/cve/detail/CVE-2026-45185
#nttdata #zen #secdb #infosec
#deadletter #cve202645185 #exim #gnutls -
🚨 CVE-2026-45185 (Dead.Letter)
Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.
ℹ️ Additional info on ZEN SecDB https://secdb.nttzen.cloud/cve/detail/CVE-2026-45185
#nttdata #zen #secdb #infosec
#deadletter #cve202645185 #exim #gnutls -
🚨 CVE-2026-45185 (Dead.Letter)
Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.
ℹ️ Additional info on ZEN SecDB https://secdb.nttzen.cloud/cve/detail/CVE-2026-45185
#nttdata #zen #secdb #infosec
#deadletter #cve202645185 #exim #gnutls -
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 :/
-
#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
-
Обновился #OpenSSL до 3.4.0 и опять без полноценной нормальной поддержки #QUIC, т.е. непригодный для #HTTP/3 на серверной стороне. И, соответственно, ещё не ясно на сколько хорошо сделана клиентская часть :)
Аж вспомнились времена, когда желая получить #curl поддерживающий нормально работу #HTTP/3 приходилось собирать его из исходников с аналогами/форками #OpenSSL.
#HTTP/3 работает не через tcp-соединения, а использует в качестве транспорта протокол QUIC (Quick UDP Internet Connections), т.е. передаёт данные поверх udp без использования абстракций и сущностей tcp. Вот картинка про современный #HTTP
Сам по себе #QUIC не умеет передавать данные в открытом виде, а может только через #TLS v1.3, т.е. в обязательном порядке только зашифрованные. Тем самым в QUIC используется встроенный вариант TLS 1.3 крайне близкий/схожий с #DTLS, поскольку работа протокола идёт на уровне обмена udp-пакетами, а не tcp-соединений.
#curl может использовать разные альтернативы OpenSSL, т.к. изначально спроектирован таким образом, что не завязан именно на OpenSSL:- Есть официальная документация что и как с бэкендами вообще.
- Рядом, примерно там же имеется сравнение разных криптографических бэкендов.
Что предлагают по HTTP/3 авторы curl?
Вот зелёным выделена комбинация библиотек, которую полагают наиболее стабильным и полноценным вариантом
Вся загвоздка в том, что #OpenSSL пытается содержать в себе реализацию #QUIC, а не использует реализацию в виде какой-то библиотеки.
Что получается в целом?
Протокол #HTTP/3 реализуется через библиотеку #nghttp3.
Необходимая реализация #QUIC через #ngtcp2.
А для TLS используется #GnuTLS или же #wolfSSL или что-то ещё:The OpenSSL forks #LibreSSL, #BoringSSL, #AWS-LC and #quictls support the QUIC API that #curl works with using #ngtcp2.
Вот из документация примеры и детали по сборке этих составляющих. Если выбрана #GnuTLS и в системе версия далёкая от свежих, то сама она довольно быстро собирается из исходников.
В целом, вообще, про варианты добавления поддержки #HTTP/3 очень достойно расписано здесь. И есть перевод этой публикации на русском языке.
#https #http #openssl #softwaredevelopment #lang_ru @Russia -
of COURSE the memory corruption bug x509-limbo found was in #GnuTLS. #PyConUS #PyCon2024
-
Brought to you by #strace-ing sssd to the connect(), getrandom(), and few read()/write() calls before switching to #GnuTLS localization files to get the “error message”, where it became obvious no actual certificates were being checked locally… Then checking #sssd's source code, diving into the #openldap rabbit hole and its dedicated config file, ending with:
# TLS certificates (needed for GnuTLS)
TLS_CACERT /etc/ssl/certs/ca-certificates.crt -
-
WTF? #gnutls|-cli
[ ... ]
Validity:
[ ... ]
Not After: Thu Sep 30 14:01:15 UTC 2021
[ ... ]
Status: The certificate is trusted.Aeh - No ... This is expired - its by definition not trusted.
-
#GnuTLS debug client 3.7.3
Checking 10.0.0.180:9001
whether the server accepts default record size (512 bytes)... no
whether %ALLOW_SMALL_RECORDS is required... no
whether we need to disable TLS 1.2... yes
whether we need to disable TLS 1.1... yes
whether we need to disable TLS 1.0... yes
whether %NO_EXTENSIONS is required... skipped
whether %COMPAT is required... skipped
for TLS 1.0 (RFC2246) support... no
for TLS 1.0 (RFC2246) support with TLS 1.0 record version... no
for TLS 1.1 (RFC4346) support... no
fallback from TLS 1.1 to... failed
for TLS 1.2 (RFC5246) support... no
for TLS 1.3 (RFC8446) support... no
for known TLS or SSL protocols support... no -
Plenty of new APIs added to Guile GnuTLS beta version 3.7.13, please give us feedback before the next stable release! #guile #gnutls https://lists.gnutls.org/pipermail/gnutls-help/2023-July/004832.html
-
It's #GNUSpotlight time! Fifteen new GNU releases in the last month: https://u.fsf.org/3ue #bash #emacs #gnugamma #gnutls #gnusasl and more -- hurrah! Thanks again, @bandali0 @bandali and big thanks to all the devs and other contributors!
-
It's #GNUSpotlight time! Fifteen new GNU releases in the last month: https://u.fsf.org/3ue #bash #emacs #gnugamma #gnutls #gnusasl and more -- hurrah! Thanks again, @bandali0 @bandali and big thanks to all the devs and other contributors!
-
It's #GNUSpotlight time! Fifteen new GNU releases in the last month: https://u.fsf.org/3ue #bash #emacs #gnugamma #gnutls #gnusasl and more -- hurrah! Thanks again, @bandali0 @bandali and big thanks to all the devs and other contributors!
-
It's #GNUSpotlight time! Fifteen new GNU releases in the last month: https://u.fsf.org/3ue #bash #emacs #gnugamma #gnutls #gnusasl and more -- hurrah! Thanks again, @bandali0 @bandali and big thanks to all the devs and other contributors!
-
Massives #Sicherheitsproblem in #GnuTLS erlaubt Mitlesen von Kommunikation
Ein Fehler bei der Umsetzung der #TLS-Verschlüsselung gefährdet deren Sicherheit, wenn die Bibliothek GnuTLS zum Einsatz kommt.