Bug#929907: libgnutls30: Connections to older GnUTLS servers break
On 2019-06-04 Andreas Metzler wrote:
> On 2019-06-03 Dominik George wrote:
[...]
> >pwgen 16383 | gnutls-cli --no-ca-verification --port 5556 localhost
> > From a size of 16383 bytes onwards, I get:
> > |<1>| Received packet with illegal length: 16385
> > |<1>| Discarded message[1] due to invalid decryption
> > *** Fatal error: A TLS record packet with invalid length was received.
> > *** Server has terminated the connection abnormally.
[...]
> Will try a bisect to check why .8 works, but might not have time before
> weekend.
Hello Dominik,
the attached cherry-picked patch fixes the gnutls-cli reproducer. - Does
it also help for your original problem?
TIA, cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
>From 2dc96e3b8d0e043bebf0815edaaa945f66ac0531 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Thu, 25 Apr 2019 17:08:43 +0200
Subject: [PATCH] ext/record_size_limit: distinguish sending and receiving
limits
The previous behavior was that both sending and receiving limits are
negotiated to be the same value. It was problematic when:
- client sends a record_size_limit with a large value in CH
- server sends a record_size_limit with a smaller value in EE
- client updates the limit for both sending and receiving, upon
receiving EE
- server sends a Certificate message larger than the limit
With this patch, each peer maintains the sending / receiving limits
separately so not to confuse with the contradicting settings.
Andreas Metzler for Debian upload:
Strip out addition of gnutls_record_set_max_recv_size() to the API from
this patchset.
--- a/lib/constate.c
+++ b/lib/constate.c
@@ -821,14 +821,12 @@ int _gnutls_write_connection_state_init(
session->security_parameters.epoch_next;
int ret;
- /* reset max_record_recv_size if it was negotiated in the
+ /* reset max_record_send_size if it was negotiated in the
* previous handshake using the record_size_limit extension */
- if (session->security_parameters.max_record_recv_size !=
- session->security_parameters.max_record_send_size &&
- !(session->internals.hsk_flags & HSK_RECORD_SIZE_LIMIT_NEGOTIATED) &&
+ if (!(session->internals.hsk_flags & HSK_RECORD_SIZE_LIMIT_NEGOTIATED) &&
session->security_parameters.entity == GNUTLS_SERVER)
- session->security_parameters.max_record_recv_size =
- session->security_parameters.max_record_send_size;
+ session->security_parameters.max_record_send_size =
+ session->security_parameters.max_user_record_send_size;
/* Update internals from CipherSuite selected.
* If we are resuming just copy the connection session
--- a/lib/dtls.c
+++ b/lib/dtls.c
@@ -65,8 +65,8 @@ transmit_message(gnutls_session_t sessio
unsigned int mtu =
gnutls_dtls_get_data_mtu(session);
- if (session->security_parameters.max_record_recv_size < mtu)
- mtu = session->security_parameters.max_record_recv_size;
+ if (session->security_parameters.max_record_send_size < mtu)
+ mtu = session->security_parameters.max_record_send_size;
mtu -= DTLS_HANDSHAKE_HEADER_SIZE;
--- a/lib/ext/max_record.c
+++ b/lib/ext/max_record.c
@@ -105,11 +105,13 @@ _gnutls_max_record_recv_params(gnutls_se
}
if (new_size != session->security_parameters.
- max_record_send_size) {
+ max_user_record_send_size) {
gnutls_assert();
return GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER;
} else {
session->security_parameters.
+max_record_send_size = new_size;
+session->security_parameters.
max_record_recv_size = new_size;
}
@@ -132,11 +134,18 @@ _gnutls_max_record_send_params(gnutls_se
/* this function sends the client extension data (dnsname) */
if (session->security_parameters.entity == GNUTLS_CLIENT) {
- if (session->security_parameters.max_record_send_size !=
+ /* if the user limits for sending and receiving are
+ * different, that means the programmer had chosen to
+ * use record_size_limit instead */
+ if (session->security_parameters.max_user_record_send_size !=
+ session->security_parameters.max_user_record_recv_size)
+ return 0;
+
+ if (session->security_parameters.max_user_record_send_size !=
DEFAULT_MAX_RECORD_SIZE) {
ret = _gnutls_mre_record2num
(session->security_parameters.
- max_record_send_size);
+ max_user_record_send_size);
/* it's not an error, as long as we send the
* record_size_limit extension with that value */
@@ -239,23 +248,18 @@ size_t gnutls_record_get_max_size(gnutls
* @session: is a #gnutls_session_t type.
* @size: is the new size
*
- * This function sets the maximum record packet size in this
- * connection.
- *
- * The requested record size does get in effect immediately only while
- * sending data. The receive part will take effect after a successful
- * handshake.
+ * This function sets the maximum amount of plaintext sent and
+ * received in a record in this
Bug#929907: libgnutls30: Connections to older GnUTLS servers break
On 2019-06-03 Dominik George wrote: > Hi, >> Is this reproducile with gnutls-cli or is the respective server >> publically accessible? > It is reproducible. > 1. Create a buster chroot for the server, or something >similar. > 2. Install gnutls-bin 3.6.6-3 and ssl-cert. > 3. Start something like: >gnutls-serv --echo --x509keyfile /etc/ssl/private/ssl-cert-snakeoil.key > --x509certfile /etc/ssl/certs/ssl-cert-snakeoil.pem > 4. Create a buster chroot for the client. > 5. Install gnutls-bin 3.6.7-2 and pwgen (I used that to generate >random blobs of printable data). > 6. Try: >pwgen 16383 | gnutls-cli --no-ca-verification --port 5556 localhost > From a size of 16383 bytes onwards, I get: > |<1>| Received packet with illegal length: 16385 > |<1>| Discarded message[1] due to invalid decryption > *** Fatal error: A TLS record packet with invalid length was received. > *** Server has terminated the connection abnormally. Hello, with server at 3.6.6 (and .4 and .5) , client version 3.6.7 breaks, while both earlier versions and 3.6.8 connect successfully. server 3.6.8/3.6.7 does not break with client 3.6.7. Will try a bisect to check why .8 works, but might not have time before weekend. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#929907: libgnutls30: Connections to older GnUTLS servers break
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, > Is this reproducile with gnutls-cli or is the respective server > publically accessible? It is reproducible. 1. Create a buster chroot for the server, or something similar. 2. Install gnutls-bin 3.6.6-3 and ssl-cert. 3. Start something like: gnutls-serv --echo --x509keyfile /etc/ssl/private/ssl-cert-snakeoil.key --x509certfile /etc/ssl/certs/ssl-cert-snakeoil.pem 4. Create a buster chroot for the client. 5. Install gnutls-bin 3.6.7-2 and pwgen (I used that to generate random blobs of printable data). 6. Try: pwgen 16383 | gnutls-cli --no-ca-verification --port 5556 localhost - From a size of 16383 bytes onwards, I get: |<1>| Received packet with illegal length: 16385 |<1>| Discarded message[1] due to invalid decryption *** Fatal error: A TLS record packet with invalid length was received. *** Server has terminated the connection abnormally. After upgrading the server to 3.6.7-2, the problem goes away. Actually, this might as well be an issue in 3.6.6, that was masked while clients were also 3.6.6… I don't know ;)! - -nik -BEGIN PGP SIGNATURE- iQJlBAEBCgBPFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlz1locxGmh0dHBzOi8v d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYwAKCRC3mjwW oMTylrJ7D/9ji2A9+audQYrS1BYInzijlV0QBJLO3ZbAUqt0zhD0jp6Xw9gUKIpW RU/TGNCzPoXusCefCsdRZAXPHt6aMCgu0ir/oPebMqz8PfIDVoqe588E4dF608u1 /QpfpBzf2DJVfwIjuAPXHLpYL7SmCE9HRanRxR1Wdnxg7mfzhnWO0Nq0Ef7+fsvr ADMoQaQ6bXko6zS8g2+7cVcI9WURwaozErSHujBhJQjbKlAkO0hzGlpUgWYuu/gd YghSxaCIQRBuPqoF3prFRA1PkdJnJxaVBaWh15laejxxGZTbb7DRqv7MGewm+LUC oi/QsnfoZ6hdOKCCP4mGzDKn47oZuVh6ldEemhOC7RK0Gzss+1qqx5XXdcOF3Xcr brxEshkYLvSMqzLZP4JaKe8a2joTYcn42yvkszB1FlTLmBJ1sK93bRIdZQf2FYKo RT+2oLITjS9tjRbJjrfoIGzCS0UCiNkJeotYBYS33jHU94igTrLOlayNoCmCe++U KQsn+09eWnGa9jdeAE6gfGzuxz5krvG2dK2cM/+clHak53EkzRQMGX9hKOkpIa0b Bs+0bKiNbCLSQtaYx4x9vSxWJg/3XOe+TXGu6CwvYFRlTW1ZXz5uOHGvbCyFoTPK Q4bbKqP+xmcfdxibx18A2rqMsByNOiNqliC9+3PdreZ2pCPeO3X1PA== =Blay -END PGP SIGNATURE-
Bug#929907: libgnutls30: Connections to older GnUTLS servers break
Control: severity -1 serious On 2019-06-03 Dominik George wrote: > Package: libgnutls30 > Version: 3.6.7-3 > Severity: grave > Justification: renders package unusable > The update to 3.6.7-3 reproducibly breaks ldap-utils (or, maybe,the ldap > client library) when connecting to a server with the previous 3.6.6-2 > version. I am afraid it breaks more than that. GnuTLS-secured connections > are just closed with no visible reason. > Seen on more than 12 systems, then went to a system that had not got the > update yet. An ldapsearch works with 3.6.6-2, and fails after updating to > 3.6.7-3 with the connection just being closed after reading some data from > the LDAP server setill on 3.6.6-2. Upgrading GnuTLS to 3.6.7-3 on the > server made the problem go away. Hello, Is this reproducile with gnutls-cli or is the respective server publically accessible? > I am setting this critical as I cannot imagine it is expected that GnuTLS > clients require the server to be the exact same version. Downgrading to serious for the time being, critical means something different. [1] cu Andreas [1] https://www.debian.org/Bugs/Developer.en.html#severities -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Processed: Re: Bug#929907: libgnutls30: Connections to older GnUTLS servers break
Processing control commands: > severity -1 serious Bug #929907 [libgnutls30] libgnutls30: Connections to older GnUTLS servers break Severity set to 'serious' from 'grave' -- 929907: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929907 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#929907: libgnutls30: Connections to older GnUTLS servers break
Package: libgnutls30 Version: 3.6.7-3 Severity: grave Justification: renders package unusable The update to 3.6.7-3 reproducibly breaks ldap-utils (or, maybe,the ldap client library) when connecting to a server with the previous 3.6.6-2 version. I am afraid it breaks more than that. GnuTLS-secured connections are just closed with no visible reason. Seen on more than 12 systems, then went to a system that had not got the update yet. An ldapsearch works with 3.6.6-2, and fails after updating to 3.6.7-3 with the connection just being closed after reading some data from the LDAP server setill on 3.6.6-2. Upgrading GnuTLS to 3.6.7-3 on the server made the problem go away. I am setting this critical as I cannot imagine it is expected that GnuTLS clients require the server to be the exact same version. -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgnutls30 depends on: ii libc6 2.28-10 ii libgmp10 2:6.1.2+dfsg-4 ii libhogweed43.4.1-1 ii libidn2-0 2.0.5-1 ii libnettle6 3.4.1-1 ii libp11-kit00.23.15-2 ii libtasn1-6 4.13-3 ii libunistring2 0.9.10-1 libgnutls30 recommends no packages. Versions of packages libgnutls30 suggests: pn gnutls-bin -- no debconf information
