Bulletproof TLS Newsletter

Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space. Maintained by Hanno Böck.

Two large cloud providers—Google and Amazon—have stopped the use of a technique called domain fronting, which was used by encrypted messengers and privacy tools to circumvent network blockades in some countries.

Technically, domain fronting is based on the fact that in an HTTPS connection, the hostname of the target host is transmitted in two ways: (1) as part of the Server Name Indication (SNI) extension in the TLS protocol and (2) as the “Host” header in the underlying HTTP connection. In many implementations, only the HTTP part really matters for forwarding the traffic. However, an outside observer of the traffic can only see the SNI field in the TLS connection.

Thus, the trick of domain fronting is to send a connection in which the SNI part is a different hostname, while only the HTTP header contains the real target hostname of the service being used. From a network observer perspective, such connections cannot be identified; therefore, blocking a particular service is hard, and blocking all connections to a cloud provider would block many other things as well.

The developers of Tor were the first to notice that domain fronting no longer worked with Google App Engine. This was later reported in an article at The Verge. Shortly thereafter, the developers of Signal received a notice from AWS warning them that they were not allowed to use an Amazon-owned domain for their connections, effectively indicating that they wouldn’t be able to used domain fronting with AWS. A blog post by the Tor project indicates that domain fronting is still possible with Microsoft Azure, but it also mentions rumors that this option may be shut down eventually as well.

The changes that stopped domain fronting may have been in response to efforts by the Russian government to block the Telegram-encrypted messenger. In trying to block Telegram, Russia also blocked access to various large cloud providers.

Short news

• Google continues to change the security indicator for HTTPS web pages in Chrome. In September, Chrome will stop displaying “Secure” on HTTPS web pages and will only show a lock. The goal is to remove the lock as well and only have negative security indicators, making HTTPS the norm. Google announced previously that pages without HTTPS will receive a “Not Secure” indicator starting in July.
• Troy Hunt writes that the latest version of Microsoft Edge now supports upgrade-insecure-requests in Content Security Policy, a feature that will rewrite all of a page’s HTTP references to HTTPS. It also now supports Subresource Integrity.
• Digicert explained the practice of log sharding in Certificate Transparency. Due to the growth of the certificate ecosystem, operating CT logs can be challenging, so some operators choose to run logs that only accept certificates within a certain date range.
• Google introduced the top-level domain .app, which is included in the HSTS preload list. This means that browsers supporting the preload list will always load this domain over HTTPS. Google had previously added top-level domains to the preload list, but this is the first one within which domains can be bought by everyone.
• GitHub Pages introduced support for HTTPS for custom domains.
• Researchers investigated how existing cryptographic acceleration hardware for RSA and elliptic curves can be utilized to optimize lattice-based cryptography.
• Antonio Sanso discussed the filtering step in the number field sieve, which is an algorithm to perform factoring and thus attack RSA encryption.
• Researchers from Princeton University collaborated with Let’s Encrypt to investigate countermeasures to BGP attacks on the certificate-issuance process.
• In a blog post, Comodo covered the recent incidents about EV certificates given out for a company called Stripe (which was not the well-known payment provider called Stripe). Originally, Comodo had revoked that certificate, but the blog post indicates that the company sees this as a mistake because the certificate was valid and there was no reason for revocation. In response to the controversy, Entrust proposed changes to the Baseline Requirements for the issuance of EV certificates that would include not issuing certificates to companies that have existed for less than 18 months.
• Oracle announced that future OpenJDK versions will ship their own root certificate stores.
• The OpenSSL project announced that upcoming version 1.1.1 will be a long-term-support release.