Home Books Training Newsletter Resources
Sign up Log in

Cryptography & Security Newsletter

28

Let's Encrypt downtime

31 May 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.

Let's Encrypt downtime

On May 18th and 19th several services operated by Let's Encrypt were unavailable. This most notably affected ACME and the OCSP server.

According to a postmortem by Josh Aas from Let's Encrypt, the reason was a change in the handling of slashes in URLs. OCSP requests are base64 encoded, and base64 contains slashes as one of its encoding characters. This subsequently led to an error in the caching of the CDN and thus an overload of the systems.

The incident shed light on some of the problems that arise when a certificate authority goes offline for short periods of time. Ideally, protocols and applications should be robust enough to handle such a situation, but in reality this is often not the case. The author of this newsletter summarized the poor state of OCSP stapling implementations in two major web servers, Apache and Nginx. Neither is capable of handling OCSP outages properly.

The Caddy web server wouldn't start if the ACME server was unavailable, which led to a longer discussion in a bug report. Subsequently, Caddy changed its behavior. Caddy developer Matt Holt described the issue in a blog post.

Symantec dispute nearing an end

After several incidents in which Symantec issued illegitimate certificates, Google planned to take some harsh actions against the certificate authority, as we reported in our March newsletter. A detailed overview of the issues can be found in the Mozilla Wiki.

It seems now that Google and Symantec may come to an agreement with significantly less impact for existing Symantec customers. The core of the agreement is that Symantec will create new certificate roots that will be cross-signed by their existing ones and another certificate authority. Therefore, over the long term, the trust in the existing roots can be removed. Statements from Mozilla representatives indicate that they'll agree to the proposed plan, so Mozilla and Chrome will align their actions. Vincent Lynch has posted a summary at the SSL Store blog.

Subscribe to the Cryptography & Security Newsletter

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

Short News

  • Chrome will add more warnings for sites using HTTP. Starting in October 2017, Chrome will show a “Not secure” warning in the URL bar when users type data in forms on HTTP sites. In incognito mode, this warning will show up even when just loading such a page.
  • sslsecure.vim is a Vim plugin that highlights insecure TLS ciphers while editing configuration files.
  • As usual, more websites have moved to HTTPS by default. This month, news site The Verge, NASA, and Stack Overflow have announced HTTPS transitions. Stack Overflow has published a detailed blog post describing the challenges and details of its transition.
  • Cloudflare now supports the X25519 key exchange.
  • At the IEEE Symposium on Security and Privacy, several papers and presentations related to TLS were published. Researchers from INRIA France won the Distinguished Paper award for a formally verified TLS 1.3 implementation (Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate; see also the related video). Other papers investigated new methods for certificate revocation (CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers; see video), using symbolic execution to find bugs in certificate validation libraries (SymCerts: Practical Symbolic Execution For Exposing Noncompliance in X.509 Certificate Validation Implementations; see video) and analyzing hostname verification of TLS implementations (HVLearn: Automated Black-box Analysis of Hostname Verification in SSL/TLS Implementations; see video).
  • A carry bug was found and fixed in the elliptic curve P-256 implementation in Go's TLS library.
  • The Core Security company discovered that Trend Micro ServerProtect fetches updates over unprotected HTTP and doesn't contain any signature verification.
  • Ryan Hurst discussed OCSP revocation reasons in a blog post; he considers the ones in the standard outdated. In several follow-up blog posts (post 1, post 2, post 3), Hurst discusses short-lived certificates, with responses from Comodo's CEO.
  • Several vulnerabilities in the past have been discovered in MySQL's handling of TLS, often allowing unencrypted connections despite the configuration forbidding them. We mentioned the Riddle vulnerability in our last newsletter. It seems that the fix for Riddle was incomplete; there's now an “Again Riddle” vulnerability, which was only recently fixed.
  • A bug in LibreSSL broke the verification of certificates in certain situations with a callback function. The bug is fixed in LibreSSL 2.5.4.
  • Colm MacCárthaigh from Amazon provides a critical analysis of the zero round-trip time (0-RTT) mode in TLS 1.3. 0-RTT is a controversial feature of TLS 1.3. It allows encrypted sessions to be resumed without additional round-trips, but it comes with the risk of replay attacks.
  • A paper by Markku-Juhani Saarinen investigates possible improvements for Ring Learning with Errors algorithms: On Reliability, Reconciliation, and Error Correction in Ring-LWE Encryption. Ring Learning with Errors is a potential candidate for postquantum cryptography.
  • The Apache Hive software fails to validate domain names in certificates. This vulnerability allows for the use of arbitrary certificates signed by accepted certificate authorities for connections.
  • David Keeler from Mozilla published an investigation in which Firefox appeared to have seen valid certificates for Mozilla domains that haven't been publicly issued. However, it turned out that all those incidents could be explained in other ways: by bad memory, stale DNS servers, and locally imported root certificates that behaved like publicly trusted ones.
  • Matt Caswell from OpenSSL published a blog post about the upcoming changes in OpenSSL when using TLS 1.3.
  • ctutlz is a set of Python libraries and tools to handle Certificate Transparency.
  • For unknown reasons, users of Wi-Fi in German ICE trains saw a wrong certificate when using the PayPal web page.
  • At the Google I/O conference, Emily Schechter and operators of some important web pages presented short talks on HTTPS deployment.
  • Several popular iOS apps failed to validate TLS certificates properly and thus allowed man-in-the-middle attacks.
  • Cloudflare now supports TLS client authentication with client certificates.
  • Microsoft finally disabled support for certificates signed with SHA-1 in Edge and Internet Explorer.
  • RFC 8164 specifies opportunistic encryption for HTTP/2. Opportunistic encryption in HTTP is controversial because some people think it may be used as an excuse to avoid deploying proper HTTPS.
  • nginx-ct is a module to automatically add Certificate Transparency SCTs in the Nginx web server.
  • A draft proposal for a flag in CAA records that requires must-staple certificates has been published.
  • Mozilla discussed whether Firefox should stop performing regular OCSP checks. Because OCSP is usually implemented in soft fail mode, it has hardly any security benefit. Chrome has disabled it already for that reason.
  • An article on Motherboard discusses the impact HTTPS on Wikipedia had on censorship. On HTTPS web pages, it's impossible to censor access to single articles. Originally, people feared that the switch to HTTPS on Wikipedia would increase censorship, but research by the Harvard Center on Internet and Society argues that it has actually had the opposite effect.
  • A blog post by the company Sucuri indicates that Google may use the lack of HTTPS for password forms as a signal for their phishing list. Both Chrome and Firefox recently introduced warnings for such pages.
  • Adam Langley described the AES-GCM-SIV algorithm in a blog post. AES-GCM-SIV is a block cipher mode that has some resistance against nonce misuse.

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