Welcome to this February edition of SSL.com’s Security Roundup. It may be our shortest month, but it was still full of developments in SSL/TLS, digital certificates, and network security. This month, we’ll be covering:
- Apple limits SSL/TLS Certificates to just over a year
- DNS over HTTPS now a Firefox default
- More writing on the wall for TLS 1.0 and 1.1
- Chrome will block insecure downloads
Apple Puts New Time Limit on Certificates
As we have already reported, Apple has recently opted to limit SSL/TLS certificate lifetimes to a little over a year. At the February CA/Browser (CA/B) Forum in Bratislava, Slovakia, Apple announced that, as of September 1, 2020, their devices and Safari browser would no longer be accepting certificates with lifetimes greater than 398 days. There has been no official, written announcement from Apple as of yet. (Update: Apple announced the policy change on its website on March 3, 2020.) As The Register notes:
Cutting certificate lifetimes has been mulled by Apple, Google, and other members of CA/Browser for months. The policy has its benefits and drawbacks…The aim of the move is to improve website security by making sure devs use certs with the latest cryptographic standards, and to reduce the number of old, neglected certificates that could potentially be stolen and re-used for phishing and drive-by malware attacks. If boffins or miscreants are able to break the cryptography in a SSL/TLS standard, short-lived certificates will ensure people migrate to more secure certs within roughly a year.
That such a significant shift is happening this way is somewhat surprising, but the shift itself isn’t. Shorter certificate lifetimes, as noted by The Register, are something that the industry has been seriously considering recently. A September CA/B Forum ballot could have changed the maximum validity period of certificates from the current 825-day standard one year, but that vote failed. This time it didn’t take a vote — a company as influential as Apple can shift the standard on its own.
DNS over HTTPS Now Firefox Default
This month, Mozilla set DNS over HTTPS (DoH) as the default for U.S. users of its Firefox browser. For those new to the concept: DoH encrypts DNS information that is generally unencrypted (even on secure websites) and prevents others from seeing what websites people are visiting. For some entities that like to collect data on users (like the government, or those who hope to profit from selling said data) that’s bad news. And some also argue that the increased opacity prevents useful spying that tracks criminals and allows for parental controls on browsing. Others, like Mozilla (clearly) and the Electronic Frontier Foundation tout the benefits of DoH, stressing that encrypting web traffic improves privacy for the public and thwarts attempts to track and censor people by the government. Mozilla’s Firefox is the first browser to adopt the standard by default.
Firefox and Slack Have Had It with TLS 1.0 and 1.1
In an unambiguous move to get rid of TLS 1.0 and 1.1 entirely, Mozilla is now requiring a manual override from users attempting to connect to websites using the protocols. The change is a step towards their declared goal of blocking such sites entirely. As The Verge reports, the change signifies what is “truly the endtimes” for TLS and 1.0 and 1.1, and Mozilla will be joined by others in the near future:
Complete support will be removed from Safari in updates to Apple iOS and macOS beginning in March 2020.’ Google has said it will remove support for TLS 1.0 and 1.1 in Chrome 81 (expected on March 17). Microsoft said it would do the same ‘in the first half of 2020’.
Mozilla isn’t the only major software vendor that is steering everyone away from TLS 1.0 and 1.1. This month, Slack ended support for them as well; the company says they are making the change “to align with industry best practices for security and data integrity.”
Chrome to Block Insecure Downloads
Recently, browsers have been making the move to warn users about mixed content. Mixed content occurs when websites link to insecure HTTP content (such as images and downloads) from HTTPS pages, “mixing” the two protocols in a way that is not obvious to users without a warning (we have examined the concept more deeply in this article). Now Chrome is taking things one step further, and will be blocking mixed content from being downloaded. As the Tech Times reports:
Beginning with Chrome 82, due for release in April, Chrome will warn users if they’re about to download mixed content executables from a stable website… Then, when version 83 is released, the ones executable downloads could be blocked, and the caution can be implemented to archive files. PDFs and .Doc files will get the warning in Chrome 84, with audio, images, text, and video files showing it with the aid of the 85th version. Finally, all mixed content downloads — a non-stable file coming from a stable site — may be blocked as of the discharge of Chrome 86.
Here’s a handy chart from Google showing their warning/blocking timeline for different types of mixed content:
