Home Books Training Newsletter Resources
Sign up Log in

Cryptography & Security Newsletter

32

CAA is now mandatory

28 September 2017

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.

A new DNS record type should improve the security of certificate issuance. Certificate Authority Authorization (CAA) was specified in RFC 6844 in 2013, but until recently implementing it wasn’t required. That has now changed. The CA/Browser Forum has decided that starting September 8, all certificate authorities must check CAA. CAA allows domain owners to define in a DNS record which certificate authorities are allowed to issue certificates for them.

Shortly after the deadline, various people tried to verify whether certificate authorities properly check CAA. It was revealed that Comodo—the company that invented CAA—failed to check CAA records, and this was independently verified by various people. In an incident report, Comodo confirmed the issue and explained that it was due to an error in the interaction with the dig command.

Various other CAs failed to properly handle corner cases with CAA, particularly in combination with DNSSEC.

Andrew Ayer has created a CAA test suite. He also operates a CAA record generator for the company SSLMate.

Subscribe to the Cryptography & Security Newsletter

This subscription is just for the newsletter; we won't send you anything else.

Short News

  • The certificate authority PROCERT had various problems with certificates issued that violate the Baseline Requirements. Representatives from Mozilla have been unsatisfied with the explanations provided by PROCERT, and it seems the certificate authority will be distrusted in Mozilla’s root certificate store.
  • How can IoT and embedded devices use HTTPS? A blog post proposes the idea of allowing HTTPS without warnings on local IP addresses.
  • Galois has cooperated with Amazon to formally verify the HMAC implementation of the s2n library with the SAW software.
  • A vulnerability in mbedtls allows bypassing the verification of certificates in some situations.
  • An entropy loss vulnerability was discovered earlier this year in the pseudo-random number generator of NSS. Mozilla developer Franziskus Kiefer describes the details.
  • The CertReq tool from Microsoft can be used to trigger HTTP requests. While unlikely, this may in some situations enable data exfiltration.
  • Henry de Valence from Cloudflare has created an experimental key exchange with supersingular isogeny Diffie-Hellman (SIDH) for TLS 1.3. An implementation in Go is available. SIDH is a potential algorithm for postquantum cryptography.
  • The work of offloading parts of TLS connections into the Linux kernel has begun. Version 4.13 of the Linux kernel contains the necessary code. This move was proposed by Facebook. An older LWN article and a blog post by Filippo Valsorda explain the details.
  • A quantum algorithm that improves collision searches on hash functions has been published in the Cryptology ePrint Archive. This is significant, as it’s been believed until now that quantum attacks have little impact on hash function security.
  • Matt Caswell discussed what changes to OpenSSL would be necessary to support the QUIC protocol. QUIC is a protocol by Google that could replace TCP and TLS. An IETF working group is working on standardizing it.
  • Sasha Perigo has implemented a feature in Chrome that detects improperly installed man-in-the-middle software that intercepts TLS connections.
  • Daniel Bernstein and Tanja Lange have published a paper in Nature titled “Post Quantum Cryptography”.
  • Chrome developer Mike West announced that FTP will be marked as insecure in future Chrome versions. This led to a discussion in which Chris Palmer, also a Chrome developer, proposed removing FTP support altogether. FTP is usually used as a plaintext protocol and is problematic with some firewalls. In theory, there’s a TLS-enabled variant of FTP called FTPES, but it isn’t used very often and is not supported by any major browser.
  • After the Equifax breach, some people have pointed out that there also exists an Equifax root certificate because Equifax used to operate a certificate authority. However, that certificate was already removed from all major browser certificate stores a while ago. It is currently owned by Symantec.
  • Google introduced automatic certificate management for the Google App Engine.
  • MD4 has been known to be vulnerable to collision attacks since 2004. However, until very recently no publicly available attack tool existed. Now there is one, along with a detailed explanation of the attack. MD4 has been used in old certificates and TLS implementations, but it’s not part of any modern TLS stack.
  • Future versions of Chrome will enable preloaded HSTS for the whole .dev top-level domain (TLD), which is owned by Google. Some people have used .dev for testing purposes on internal machines. This is no longer possible because HSTS preloading requires a valid HTTPS connection and certificate. The .dev TLD was never intended for testing purposes; .test is a reserved TLD for that purpose.
  • mitm.watch is a test for man-in-the-middle software intercepting TLS connections. It’s operated by Nick Sullivan from Cloudflare and uses Caddy’s MITM detection heuristic.
  • Two white papers comparing the security of Google Chrome, Microsoft Edge, and Microsoft Internet Explorer have been published, one by X41 and one by Cure53. Although TLS is not the main focus of those papers, they also cover support of certain TLS-related features.
  • Thomas Susanka explains various TLS extensions in a blogpost.
  • Steven Danneman from the company Security Innovations looked at the TLS support of database servers like MySQL and PostgreSQL. He contributed support for testing TLS features on those database servers to the TestSSL script.
  • Dirk Wetter has released TestSSL 2.9.5 with many new features.
  • The author of this newsletter summarizes the lack of well-supported, secure time-setting options in a blog post.
  • StartCom is trying to get reincluded into browser trust stores. However, things aren’t going well. Gervase Markham from Mozilla summarized the situation and mentioned various problems with the security of the web interface, a questionable cross signature, and more.
  • Hardenize has introduced a certificate-monitoring feature.
  • Mozilla plans to remove support for cipher suites using Triple DES (also called 3DES). It’s seen as problematic these days due to its small block size and block-collision attacks.
  • Cloudflare introduced a new feature allowing customers to decide in which locations and countries their certificate’s private keys are held.
  • The Qualys SSL Labs test now warns about certificates from Symantec that need to be replaced due to the removal of trust of Symantec certificates by Google and Mozilla.
  • Ivan Ristić discusses in blog posts two potential ways to change HPKP in order to alleviate existing concerns about faulty configurations and potential ransom attacks: pin revocation and certificate constraints.

Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.

Remote and trainer-led, with small classes and a choice of timezones.

Join over 2,000 students who have benefited from more than a decade of deep TLS and PKI expertise.

Find out More

@feistyduck

Books

  • Bulletproof TLS and PKI
  • ModSecurity Handbook
  • OpenSSL Cookbook

Training

  • Practical TLS and PKI

Resources

  • Newsletter
  • SSL/TLS and PKI History
  • Archived Books
  • Bulletproof TLS Guide

Company

  • Support
  • Website Terms of Use
  • Terms and Conditions
  • Privacy Policy
  • About Us