[gnutls-devel] GnuTLS | DTLS client does not reset the connection state after receiving a fatal alert (#1244)

[Read-only notification of GnuTLS library development activities]

Paul created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1244




## Version of gnutls used:
3.7.1

## Operating System
Ubuntu 20

## Description of problem:

The [RFC](https://datatracker.ietf.org/doc/html/rfc5246#section-7.2.2) states the following on processing fatal alerts:

>    Upon transmission or receipt of a fatal alert message, both
>    parties immediately close the connection. 

According to our testing, the DTLS client applications provided with GnuTLS (e.g. gnutls-cli) do not seem to clear the connection data upon processing a fatal alert, or a close_notify alert for that matter. This is illustrated in the below interaction with a GnuTLS client:

![gnutls_continueafteralert](/uploads/5f08842fa7d11743f10feb3cfb97fc94/gnutls_continueafteralert.png)

I don't know if it's the library or the application, but it is incorrect that the client after processing a fatal alert, still remembers the ClientHello it had sent before, accepts ServerHello, Certificate..., and eventually generates the ClientKeyExchange flight of messages. Receiving the fatal alert should have prompted the client to reset the connection state, and thus reject the ServerHello. 

## How reproducible:
I attached files necessary for [reproduction](/uploads/4013c1c4173a746706fa8981fe7ffe58/reproduce.tar.gz) using [DTLS-Fuzzer](https://github.com/assist-project/dtls-fuzzer/). Also included in the archive is the capture shown above. DTLS-Fuzzer requires  the JDK for Java 8. On Ubuntu, this can be installed  by running:
`sudo apt-get install openjdk-8-jdk`

Unpack the archive, `cd` to resulting folder and run `bash reproduce.sh`, while running an instance of Wireshark on the side. The reproduction script will: 
* setup DTLS-Fuzzer;
* launch gnutls-serv utility (it is assumed the correct version of GnuTLS is already installed)
* launch DTLS-Fuzzer to execute input sequence found in 'test_sequence' to expose this problem. 

## Actual results:
The client generates the ClientKeyExchange flight of messages, despite not having generated ClientHello after processing the Alert.

## Expected results:
If the RFC had been followed, the client would have rejected the ServerHello/would not have generated the ClientKeyExchange flight of messages. 

Note that this problem applies to both fatal and close_notify alerts. Both types of alerts should prompt the client to clear the connection state.

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