en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

February 2020 Security Roundup

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

SSL.com’s takeaway: Though reducing certificate lifespans has been a point of conversation, there hasn’t yet been a consensus move to do so across the industry. This move by Apple could likely force that consensus and change the standard. It’s unclear what ripple effect the halving will have, but it looks like we are all about to find out!

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.

SSL.com’s takeaway: As supporters of privacy and more robust encryption, this change by Mozilla strikes us as a largely positive thing that is sure to be opposed by people who profit from collecting and selling data gathered on unsuspecting internet users.

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.”

SSL.com’s takeaway: The message here is pretty straightforward. Stop using TLS 1.0 and 1.1 on your websites, and be sure to keep your browsers updated.

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:

Schedule for blocking mixed content in Chrome

SSL.com’s takeaway: If you have a site that serves HTTP resources from HTTPS pages, cut it out! It might get you blocked.
Thank you for choosing SSL.com! If you have any questions, please contact us by email at Support@SSL.com, call 1-877-SSL-SECURE, or just click the chat link at the bottom right of this page.

Subscribe to SSL.com’s Newsletter

Don’t miss new articles and updates from SSL.com