Cryptography & Security Newsletter

Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Hanno Böck.

MTA-STS is a recent standard that enables more secure TLS connections between mail servers. Although several email providers already have published MTA-STS policies for inbound connections, Gmail recently became the first major email provider to actually check those policies and thus implement MTA-STS on both sides of a connection.

TLS connections between mail servers have long been possible via the STARTTLS feature. However, these connections were never properly authenticated and were vulnerable to both downgrades and man-in-the-middle attacks.

With MTA-STS, which was published in September of last year as an RFC, mail server owners can publish a policy for certificate validation on a standardized subdomain (mta-sts) and indicate via DNS that they have such a policy. Similar to HSTS, these policies have a lifetime, and thus mail servers can store them. A permanent network attacker can still prevent a server from fetching the policy, but an attacker with only temporary access to a network connection is unable to listen to or manipulate connections.

MTA-STS has the support of many large email providers and thus likely soon will be supported for the majority of email connections. Although publishing policies is relatively simple, supporting outbound MTA-STS requires proper support from the mail server software. The Courier mail server recently added support in version 1.0.7. Postfix doesn’t support it out of the box yet, but an external module can be used.

Short News

• A buffer overflow was found in axTLS and fixed in version 2.1.5.
• Kathleen Wilson from Mozilla explains the Common CA Database (CCADB) in a blog post.
• Let’s Encrypt will change the default intermediate certificate to its own root. Originally, Let’s Encrypt was cross-signed by IdenTrust. The old intermediate can still be used for compatibility with older clients.
• Andrew Ayer explains challenges in deploying MTA-STS and proposes ways DNS providers can automate its deployment in a blog post.
• Wayne Thayer from Mozilla has raised concerns about the certificate authority Certinomis and has started documenting problems with Certinomis in a wiki page.
• The nonce-misuse-resistant encryption mode AES-GCM-SIV has been published as an RFC.
• A research paper investigates fault-based attacks on elliptic curve cryptography.
• The Dutch National Cyber Security Centrum (NCSC) published guidelines for the deployment of TLS, with a focus on TLS 1.3.
• By using traffic side-channels, researchers were able to identify user choices in the interactive Netflix movie Black Mirror: Bandersnatch.
• Node.js 12.0.0 adds support for TLS 1.3.
• GnuTLS 3.6.7 fixes two memory-corruption security vulnerabilities.
• A blog post from the company Trail of Bits explains the risks of zero round trip time (0-RTT) connections in TLS 1.3.
• Researchers from NCC Group showed how to extract keys from hardware keystores in the Qualcomm chips that are used in many mobile devices.
• A weakness in the preshared key mode of TLS 1.3 was discovered and named the Selfie attack. Although the practical implications are small, it’s noteworthy that it wasn’t discovered during the formal verification of the TLS 1.3 protocol.
• The first version of EverCrypt has been published. EverCrypt is a library that provides cryptographic algorithms with formally verified correctness.
• A blog post from SentinelOne explains the background and state of domain fronting. (We focused on domain fronting last year in the May newsletter.)
• A blog post explains how the URL bar with the HTTPS security indicator can be faked by a web page on mobile browsers.