[gnutls-devel] GnuTLS | gnutls-cli does not null terminate buffer when sending messages (#534)

[Development of GNU's TLS library]

New Issue was created.

Issue 534: https://gitlab.com/gnutls/gnutls/issues/534
Author:    Hubert Kario
Assignee:  

## Description of problem:
When using `gnutls-cli`, the client will always send as much data as it was in the biggest line sent thus far (i.e. Enter does not insert a 0x00 character in the buffer). That means the server sees garbage (data from previous lines) when receiving the shorter lines from client.

## Version of gnutls used:
4e87865c0152a98b899272dbe7cf3a459e04b351

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

## How reproducible:

Steps to Reproduce:

 * `openssl req -x509 -newkey rsa -keyout /tmp/localhost.key -out /tmp/localhost.crt -subj /CN=localhost -nodes -batch`
 * `openssl s_server -key /tmp/localhost.key -cert /tmp/localhost.crt`
 * `gnutls-cli --insecure --port 4433 --inline-commands --priority NORMAL:+VERS-TLS1.3 localhost`
 * on the gnutls-cli command line enter:
   ```
   some very long line to send
   Hello!
   ```

## Actual results:
On the server side:
```
No server certificate CA names sent
CIPHER is TLS_AES_256_GCM_SHA384
Secure Renegotiation IS NOT supported
some very long line to send
Hello!
ry long line to send
DONE
shutting down SSL
CONNECTION CLOSED
```

## Expected results:

```
No server certificate CA names sent
CIPHER is TLS_AES_256_GCM_SHA384
Secure Renegotiation IS NOT supported
some very long line to send
Hello!
DONE
shutting down SSL
CONNECTION CLOSED
```

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/534
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/20180802/fe2c740d/attachment.html>