Bug#933538: libgnutls30: still fails with older servers

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view

Bug#933538: libgnutls30: still fails with older servers

Hanno Stock-2
Package: libgnutls30
Version: 3.6.7-4
Severity: important

Dear Maintainer,

   * What led up to the situation?

First, I had problems using sogo-tool for a sogo instance connected
to an older LDAP Server.

Restoring a user gave this error:

2019-07-31 12:51:37.411 sogo-tool[11248:11248] Received packet with illegal length: 16624
2019-07-31 12:51:37.411 sogo-tool[11248:11248] Fatal LDAP error during ldap_result: Can't contact LDAP server

   * What exactly did you do (or not do) that was effective (or

In order to isolate the problem, I used gnutls-utils for opening a
server on the older LDAP machine:

gnutls-serv --echo --x509keyfile /etc/ssl/private/ssl-cert-snakeoil.key --x509certfile /etc/ssl/certs/ssl-cert-snakeoil.pem

The server runs libgnutls26 2.12.23-12ubuntu2.8

On the client machine (buster) I tried

pwgen 16383 | gnutls-cli --no-ca-verification --port 5556 server

   * What was the outcome of this action?

On the client I get something like this:

root@groupware-beta:~# pwgen 16383 | gnutls-cli --no-ca-verification --port 5556 ldap.company.x
Processed 130 CA certificate(s).
Resolving 'redacted'...
Connecting to 'redacted:5556'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `CN=redacted', issuer `CN=redacted', serial 0x00e120b43d69e2e4d8, RSA key 2048 bits, signed using RSA-SHA256, activated `2017-07-06 10:03:48 UTC', expires `2027-07-04 10:03:48 UTC', pin-sha256="SxggXxyfEDi9fmVyLwzPN9yE5y69T92aF8CBdGMe9Rc="
        Public Key ID:
        Public Key PIN:

- Successfully sent 0 certificate(s) to server.
- Description: (TLS1.2)-(RSA)-(AES-256-CBC)-(SHA1)
- Session ID: 74:27:72:45:ED:A4:AA:BD:4C:06:1C:43:3D:1C:71:3D:AE:02:14:06:7D:72:25:01:ED:4F:50:BF:C5:67:1C:79
- Options: safe renegotiation,
- Handshake was completed

- Simple Client Mode:

|<1>| Received packet with illegal length: 16624
*** Fatal error: A TLS record packet with invalid length was received.
*** Server has terminated the connection abnormally.

The server does not show anything abnormal:

* Successful handshake from IPv4 REDACTED_IP port 43420
- Given server name[1]: ldap.indurad.x
- Certificate type: X.509
No certificates found!
- Could not verify certificate (err: The peer did not send any certificate.)
- Version: TLS1.2
- Key Exchange: RSA
- Cipher: AES-256-CBC
- Compression: NULL
received: pheedei [...]

   * What outcome did you expect instead?

Successful connection to server and echo of the sent bytes.

I also tried this with libgnutls30 3.6.8-2 on the client side (taken
from testing). Same problem persists.

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/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  libhogweed4    3.4.1-1
ii  libidn2-0      2.0.5-1
ii  libnettle6     3.4.1-1
ii  libp11-kit0    0.23.15-2
ii  libtasn1-6     4.13-3
ii  libunistring2  0.9.10-1

libgnutls30 recommends no packages.

Versions of packages libgnutls30 suggests:
ii  gnutls-bin  3.6.7-4

-- no debconf information

Reply | Threaded
Open this post in threaded view

Bug#933538: (no subject)

Hanno Stock-2
This bug seems very similar to #929907, however the fix from the
mentioned bug does not seem to fix this problem with even older server

I think this is a serious regression and should be marked as serious.

Reply | Threaded
Open this post in threaded view

Bug#933538: (no subject)

Hanno Stock-4
In reply to this post by Hanno Stock-2
also fails with 3.6.9-1 from experimental - so I guess this should be
forwarded upstream...