[gnutls-devel] GnuTLS | Connection problems with older servers (record packet with invalid length was received) (#811)

Development of GNU's TLS library gnutls-devel at lists.gnutls.org
Wed Jul 31 16:05:33 CEST 2019



Hanno Stock created an issue:


  ## Description of problem:

When connecting to an older server, sometimes the connection is terminated because of invalid record length errors. To me it looks as if newer versions of GnuTLS are too strict in record length checking (however I am not an expert).

This could have something to do with plaintext length vs. padded length or similar.

## Version of gnutls used:

On client side:

tried with 3.6.9-1, 3.6.8-2 and 3.6.7-4.

On server side:

libgnutls26 2.12.23-12ubuntu2.8

## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL)

Debian (buster); also tried the sid and experimental versions on said buster client.

## How reproducible:

Steps to Reproduce:

Run on older Ubuntu 14.04 machine:

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

Run on buster or newer client machine:

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

## Actual results:

### Client output:

```
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:
		sha1:21c8b2ecfc2b23da00de3371a4aa7bb8b8fc13bc
		sha256:4b18205f1c9f1038bd7e65722f0ccf37dc84e72ebd4fdd9a17c08174631ef517
	Public Key PIN:
		pin-sha256:SxggXxyfEDi9fmVyLwzPN9yE5y69T92aF8CBdGMe9Rc=

- 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.
```

### Server output:

No error shown on server:

```
* 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
- MAC: SHA1
- Compression: NULL
received: pheedei [...]
```

## Expected results:

The client should not disconnect and show the bytes that were sent to the server (because server echoes back).

## Downstream Info

This has been reported to Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933538

I am the bug reporter (not the package maintainer), however I am involved in Debian and would also be willing to dig a little deeper, but currently am not familiar with the GnuTLS code. But if someone can point me to some commits that recently changed anything about record length checking I would be willing to try some things out.

Also I'd be interested how I might debug whether it is the server that does not follow the specs or the client that is too strict. I'd reason GnuTLS should however at least support older GnuTLS servers' behavior - even if it is out of spec.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/811
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20190731/d77df702/attachment-0001.html>


More information about the Gnutls-devel mailing list