Emacs and TLS
I&#x27;m the new guy mentioned in the article. This article is a bit late to the party and misses a lot of details that I&#x27;ve discovered since June.<p>One of the reasons prompted this giant thread on the emacs-devel mailing list is when I was updating my Emacs config to try out Gnus for email and newsgroup, I discovered that no one seems to know exactly what a good TLS Emacs config should look like and that Emacs comes with horrible defaults. In addition, I was shocked that I&#x27;ve been exposed to a dozen TLS vulns that might cause arbitrary code execution the whole time since package.el became a part of Emacs back in circa-2013. After stuffing myself with about a dozen RFCs and many dozen more papers and Chrome and Firefox blog posts, here&#x27;s what I found very concerning:<p>1. The initial &quot;a bit concerning&quot; and &quot;very concerning&quot; qualifiers I originally posted aren&#x27;t as clear cut anymore, most of the 2 dozen failing badssl tests are actually quite bad.<p>2. NSM has got half a foot in the 2010s and half a foot in the 2000s. The latest stable version of Emacs (26.1) only checks for SHA1 end-certificate, usage of SSL, DH &lt; 1024 bits and a noop RC4 cipher check (GnuTLS actually calls it ARCFOUR).<p>3. The half-done pinning mechanism does Trust on First Use while the user can&#x27;t even see the entire cert chain or the end cert.<p>4. Only one fingerprint per host for TOFU, where Google low balances at least between 2 end-certs AFAIK.<p>5. Excessive and theatrical prompts for any URL that has not been visited on a security level called &#x27;paranoid.<p>6. Multiple prompts for different problems found for the same TLS handshake.<p>7. Setting one option in a configuration group called GnuTLS to true bypasses NSM entirely. i.e. no cipher suite checks and happily accepts any 256-bit DH key exchange attempts.<p>8. No attempt to do any OCSP or Certificate Transparency revocation checking.<p>9. 4 packages intermingled with each other all securing some network connections badly with no documented relationships between them.<p>10. Virtually no one who has commit access to the Emacs repo understands TLS.<p>11. RMS prefixes every one of his email with:<p><pre><code>  [[[ To any NSA and FBI agents reading my email: please consider    ]]]
  [[[ whether defending the US Constitution against all enemies,     ]]]
  [[[ foreign or domestic, requires you to follow Snowden&#x27;s example. ]]]
</code></pre>
while Emacs&#x27;s network security settings is basically saying please come fuck me.<p>The good news is, a few of these problems are already fixed on master and I&#x27;ve pushed a branch called &quot;netsec&quot; to the Emacs repo last week that fixes most of the rest. OCSP is coming this weekend. CT is going to wait quite a bit longer as GnuTLS has no plan to support it anytime soon. I have hope to make at least some of these security fixes to Emacs 26.2 or 26.3 in the short term. Medium term plan is to lobby for requiring TLS for all email protocols because RFC 8314. The long plan is obviously support TLS 1.3 for Emacs 27, and possibly HTTP2.