<!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>
<p dir="auto">I'm evaluating the vulnerabilities discussed in the paper titled <a href="http://ia.cr/2018/747" rel="nofollow noreferrer noopener" target="_blank">"Pseudo
Constant Time Implementations of TLS Are Only Pseudo Secure"</a>. I'm working on backporting security fixes to
the Debian LTS security suite which currently shipped a patched version
of GnuTLS 3.3.8.</p>
<p dir="auto">In that paper, the authors claim that:</p>
<blockquote dir="auto">
<p>However, we believe that the GnuTLS code is still vulnerable to
variants of the attacks presented in our paper due to its
padding-dependent memory accesses. We notified the GnuTLS team of our
concerns about this on June 13th 2018. Our understanding is that the
GnuTLS team does not plan to address the issues, but prefers to
promote the use of Encrypt-then-MAC (as specified in RFC 7366) when
legacy cipher suites are required.</p>
</blockquote>
<p dir="auto">In the Debian security tracker, all three issues are marked as fixed in
3.5.19 or 3.6.3:</p>
<ul dir="auto">
<li><a href="https://security-tracker.debian.org/tracker/CVE-2018-10844" rel="nofollow noreferrer noopener" target="_blank">https://security-tracker.debian.org/tracker/CVE-2018-10844</a></li>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2018-10845" rel="nofollow noreferrer noopener" target="_blank">https://security-tracker.debian.org/tracker/CVE-2018-10845</a></li>
<li><a href="https://security-tracker.debian.org/tracker/CVE-2018-10846" rel="nofollow noreferrer noopener" target="_blank">https://security-tracker.debian.org/tracker/CVE-2018-10846</a></li>
</ul>
<p dir="auto">Yet the above claim makes me wonder if our characterization is
correct. On top of the concerns outlined by the researchers, one concern
specific to LTS is we are hesitant in breaking backwards compatibility
with older clients. In that respect, Encrypt-then-MAC (EtM) might not be
an acceptable solution as, again according to the authors:</p>
<blockquote dir="auto">
<p>The “Encrypt-then-MAC” countermeasure from RFC 7366 is supported in
mbed TLS and GnuTLS, but requires client-side support and has seen
little uptake elsewhere (e.g. neither Firefox nor Chrome supports the
EtM extension).</p>
</blockquote>
<p dir="auto">Considering that at least 10% of TLS traffic still uses CBC, it seems a
little premature to enforce those new algorithms. Removing some SHA
implementations might also be a problem for us.</p>
<p dir="auto">What should be the course of action for LTS developers?</p>
<p dir="auto">Do you agree with the researcher's characterization of the solutions
deployed by the GnuTLS project? Are those CVEs really completely fixed
in GnuTLS?</p>
<p dir="auto">Thanks for any feedback.</p>
</div>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #777;">
—
<br>
Reply to this email directly or <a href="https://gitlab.com/gnutls/gnutls/issues/456#note_105579686">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/102ccc000408dc1c9b5cb3dde34734f5/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/456#note_105579686"}}</script>
</p>
</div>
</body>
</html>