<!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=utf-8" http-equiv="Content-Type">
<title>
GitLab
</title>
<style>img {
max-width: 100%; height: auto;
}
</style>
</head>
<body>
<div class="content">
<div style="">
<p dir="auto">Being able to find such issues as part of a CI run would indeed be a nice
feature, however there are some obstacles. Results like this have been
discovered through evolutionary fuzzing techniques. In order for this to
produce results multiple instances need to run for days or weeks, which is
usually not desirable as part of the regular CI run.</p>
<p dir="auto">In order to resolve the issue across the entire code base and not only w.r.t.
ECDHE I'd suggest the following steps:</p>
<ol dir="auto">
<li>Identify the code locations that are responsible for sending TLS Alerts</li>
<li>Make sure that upon receipt of a fatal alert the connection is immediately
terminated. Do not respond with any alerts of your own.*(1)</li>
<li>Use you IDE or tools like ctags/cscope to identify all code locations that
call the code locations identified in step 1.</li>
<li>Review the alert type selected by the code locations identified in step 3.
If this alert type is an <code>INTERNAL_ERROR</code> it is <em>very</em> likely it needs to
be replaced with an appropriate protocol related alert. Cases where sending
an INTERNAL_ERROR would be OK are for instance:
<ul>
<li>A memory allocation request to the OS failed</li>
<li>Starting a thread or forking a process failed</li>
<li>A write to disk failed (i.e. because the hard drive is full)</li>
<li>...</li>
</ul>
</li>
</ol>
<p dir="auto">(*1) Side note: You may send alerts in response to non fatal alerts. Be
aware however that sending a non fatal alert puts you in a situation where
you can not foresee how the peer will react.</p>
<p dir="auto">Section 7.2.2 in RFC 5246 states</p>
<pre class="code highlight js-syntax-highlight plaintext" lang="plaintext" v-pre="true"><code><span id="LC1" class="line" lang="plaintext"> If an alert with a level of warning is sent and received, generally</span>
<span id="LC2" class="line" lang="plaintext"> the connection can continue normally. If the receiving party decides</span>
<span id="LC3" class="line" lang="plaintext"> not to proceed with the connection (e.g., after having received a</span>
<span id="LC4" class="line" lang="plaintext"> no_renegotiation alert that it is not willing to accept), it SHOULD</span>
<span id="LC5" class="line" lang="plaintext"> send a fatal alert to terminate the connection. Given this, the</span>
<span id="LC6" class="line" lang="plaintext"> sending party cannot, in general, know how the receiving party will</span>
<span id="LC7" class="line" lang="plaintext"> behave. Therefore, warning alerts are not very useful when the</span>
<span id="LC8" class="line" lang="plaintext"> sending party wants to continue the connection, and thus are</span>
<span id="LC9" class="line" lang="plaintext"> sometimes omitted. For example, if a peer decides to accept an</span>
<span id="LC10" class="line" lang="plaintext"> expired certificate (perhaps after confirming this with the user) and</span>
<span id="LC11" class="line" lang="plaintext"> wants to continue the connection, it would not generally send a</span>
<span id="LC12" class="line" lang="plaintext"> certificate_expired alert.</span></code></pre>
</div>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #777777;">
—
<br>
Reply to this email directly or <a href="https://gitlab.com/gnutls/gnutls/issues/672#note_131126590">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/f808b99f98a95d799b74dd450cbabaf5/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/672#note_131126590"}}</script>
</p>
</div>
</body>
</html>