<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="en">
<head>
<meta content="text/html; charset=US-ASCII" http-equiv="Content-Type">
<title>
GitLab
</title>
<style>img {
max-width: 100%; height: auto;
}
</style>
</head>
<body>
<div class="content">
<p class="details" style="font-style: italic; color: #666;">
<a href="https://gitlab.com/pfg666">Paul</a> created an issue: <a href="https://gitlab.com/gnutls/gnutls/-/issues/1244">#1244</a>
</p>
<div></div>
<h2 dir="auto">
<a id="user-content-version-of-gnutls-used" class="anchor" href="#version-of-gnutls-used" aria-hidden="true"></a>Version of gnutls used:</h2>
<p dir="auto">3.7.1</p>
<h2 dir="auto">
<a id="user-content-operating-system" class="anchor" href="#operating-system" aria-hidden="true"></a>Operating System</h2>
<p dir="auto">Ubuntu 20</p>
<h2 dir="auto">
<a id="user-content-description-of-problem" class="anchor" href="#description-of-problem" aria-hidden="true"></a>Description of problem:</h2>
<p dir="auto">The <a href="https://datatracker.ietf.org/doc/html/rfc5246#section-7.2.2" rel="nofollow noreferrer noopener" target="_blank">RFC</a> states the following on processing fatal alerts:</p>
<blockquote dir="auto">
<p>Upon transmission or receipt of a fatal alert message, both
parties immediately close the connection.</p>
</blockquote>
<p dir="auto">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:</p>
<p dir="auto"><a class="no-attachment-icon gfm" href="https://gitlab.com/gnutls/gnutls/uploads/5f08842fa7d11743f10feb3cfb97fc94/gnutls_continueafteralert.png" target="_blank" rel="noopener noreferrer" data-link="true"><img src="https://gitlab.com/gnutls/gnutls/uploads/5f08842fa7d11743f10feb3cfb97fc94/gnutls_continueafteralert.png" alt="gnutls_continueafteralert" class="gfm" style="max-width: 100%; height: auto;"></a></p>
<p dir="auto">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.</p>
<h2 dir="auto">
<a id="user-content-how-reproducible" class="anchor" href="#how-reproducible" aria-hidden="true"></a>How reproducible:</h2>
<p dir="auto">I attached files necessary for <a href="https://gitlab.com/gnutls/gnutls/uploads/4013c1c4173a746706fa8981fe7ffe58/reproduce.tar.gz" data-link="true" class="gfm">reproduction</a> using <a href="https://github.com/assist-project/dtls-fuzzer/" rel="nofollow noreferrer noopener" target="_blank">DTLS-Fuzzer</a>. 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:
<code>sudo apt-get install openjdk-8-jdk</code></p>
<p dir="auto">Unpack the archive, <code>cd</code> to resulting folder and run <code>bash reproduce.sh</code>, while running an instance of Wireshark on the side. The reproduction script will:</p>
<ul dir="auto">
<li>setup DTLS-Fuzzer;</li>
<li>launch gnutls-serv utility (it is assumed the correct version of GnuTLS is already installed)</li>
<li>launch DTLS-Fuzzer to execute input sequence found in 'test_sequence' to expose this problem.</li>
</ul>
<h2 dir="auto">
<a id="user-content-actual-results" class="anchor" href="#actual-results" aria-hidden="true"></a>Actual results:</h2>
<p dir="auto">The client generates the ClientKeyExchange flight of messages, despite not having generated ClientHello after processing the Alert.</p>
<h2 dir="auto">
<a id="user-content-expected-results" class="anchor" href="#expected-results" aria-hidden="true"></a>Expected results:</h2>
<p dir="auto">If the RFC had been followed, the client would have rejected the ServerHello/would not have generated the ClientKeyExchange flight of messages.</p>
<p dir="auto">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.</p>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #666;">
—
<br>
Reply to this email directly or <a href="https://gitlab.com/gnutls/gnutls/-/issues/1244">view it on GitLab</a>.
<br>
You're receiving this email because of your account on gitlab.com.
If you'd like to receive fewer emails, you can
<a href="https://gitlab.com/-/sent_notifications/8f29326fa475ebeeec91d787d142e9f1/unsubscribe">unsubscribe</a>
from this thread or
adjust your notification settings.
<script type="application/ld+json">{"@context":"http://schema.org","@type":"EmailMessage","action":{"@type":"ViewAction","name":"View Issue","url":"https://gitlab.com/gnutls/gnutls/-/issues/1244"}}</script>
</p>
</div>
</body>
</html>