June 2020 Security Roundup

Welcome to this June edition of SSL.com’s Security Roundup. Summer is here, the pandemic continues, and so does the news about digital security! This month we’ll be taking a look at:

If you’re looking for an SSL/TLS certificate for your site, take a look at SSL.com’s affordable, high value options.

Senate To Consider Mandated Encryption Backdoors

This one is kind of yikes-y. While a lot of the country is considering scaling back the power of law enforcement, three senators have introduced a Draconian bill that will force tech companies to create encryption scheme “backdoors” that will allow law enforcement to access data in transit and on devices. As Vice Magazine’s Motherboard succinctly put it in their headline, “Republicans Who Don’t Understand Encryption Introduce Bill to Break It.”

The Bill from Senators Lindsey Graham (R-South Carolina), Tom Cotton (R-Arkansas), and Marsha Blackburn (R-Tennessee) has been widely and thoroughly criticized by the tech industry, civil rights advocates and many with common sense. As Thomas Claburn’s article in The Register explains:

The bill requires any corporate presented with a warrant – “device manufacturer, an operating system provider, a provider of remote computing service, or another person” – to help authorities “access information stored on an electronic device or to access remotely stored electronic information.”

 It doesn’t specify how encryption should be dealt with, just that it should be undoable when inconvenient to authorities…

 …Encryption, it should be said, also prevents a fair amount of crime by keeping things like online bank accounts and web browsing reasonably secure. Mandating a backdoor, which mathematically anyone could find, might not be the wisest move.

Sadly, this attempt at legislation isn’t even particularly new, just the latest lazy iteration of an attempt to bypass digital security to make things easier for the Powers That Be.

SSL.com’s takeaway: SSL.com does not support government-mandated insecurity – when end-to-end encryption is outlawed, only outlaws will have end-to-end encryption. Also note this quote from the Vice article: ‘The only caveat is “unless the independent actions of an unaffiliated entity make it technically impossible to do so,” which seems to exclude the current reality, which is that tech companies themselves have made it impossible to decrypt data stored on a phone encrypted with a passcode, or messages exchanged in end-to-end encrypted apps.’

US Government Plans to Use HTTPS on All .gov Websites

In good, belated news, the U.S. Government has announced its intent to add the “.gov” domain to the HTTP Strict Transport Security (HSTS) preload list. For now, some government sites will continue to offer HTTP to keep them accessible to users, with the intention of reaching the point where all .gov web servers will use HTTPS by default.

But, this is the federal government, and it’s important to note that none of this will be taking place overnight. Rather, the U.S. is working towards putting the .gov domain on the HSTS preload list, which will eventually redirect users to communicate over HTTPS as a default.

From the government announcement:

Note that we’re announcing an intent to preload the TLD, but not actually preloading it today. If we did that, some government websites that don’t offer HTTPS would become inaccessible to users, and we don’t want to negatively impact services on our way to enhancing them! Actually preloading is a simple step, but getting there will require concerted effort among the federal, state, local and tribal government organizations that use a common resource, but don’t often work together in this area… With concerted effort, we could preload .gov within a few years.

In the meantime, according to that same announcement, the government will be preparing individual sites for the transition, holding presentations and listening sessions, and automatically preloading all new .gov domains beginning in September. They have also created a new listserv for feedback from government agencies about challenges they expect to face.

SSL.com’s takeaway:  All websites everywhere should be using HTTPS by now, so this is a Good Idea, though a slow-moving one. We’ll take what we can get!

Comcast and Mozilla Strike Firefox DoH Deal

Comcast is the first Internet Service Provider to partner with Mozilla to provide encrypted DNS lookups in Firefox. The deal between the two companies comes after a dispute over ISP privacy and whether DNS over HTTPS takes away the ability of ISPs to track users and maintain things like parental controls.

Jon Brodkin in Ars Technica explains that Comcast will be the first ISP to join Firefox’s Trusted Recursive Resolver program, joining Cloudflare and NextDNS. The program, according to that article, “requires encrypted-DNS providers to meet privacy and transparency criteria and pledge not to block or filter domains by default ‘unless specifically required by law in the jurisdiction in which the resolver operates’.”

Previously, the two now-partners disagreed over DNS over HTTPS, which prevents people from seeing what DNS lookups browsers are making, making monitoring by ISPs pretty difficult. From the Ars Technica article:

The Comcast/Mozilla partnership is notable because ISPs have fought plans to deploy DNS over HTTPS in browsers, and Mozilla’s work on the technology is largely intended to prevent ISPs from snooping on their users’ browsing. In September 2019, industry groups including the NCTA cable lobby that Comcast belongs to wrote a letter to Congress objecting to Google’s plans for encrypted DNS in Chrome and Android. Comcast gave members of Congress a lobbying presentation that claimed the encrypted-DNS plan would “centraliz[e] a majority of worldwide DNS data with Google” and “give one provider control of Internet traffic routing and vast amounts of new data about consumers and competitors.” Comcast’s lobbying presentation also complained about Mozilla’s plan for Firefox.

Mozilla in November accused ISPs of lying to Congress in order to spread confusion about encrypted DNS. Mozilla’s letter to Congress criticized Comcast, pointing to an incident in 2014 in which Comcast “injected ads to users connected to its public Wi-Fi hotspots, potentially creating new security vulnerabilities in websites.” Mozilla said that because of the Comcast incident and others involving Verizon and AT&T, “We believe that such proactive measures [to implement encrypted DNS] have become necessary to protect users in light of the extensive record of ISP abuse of personal data.” Mozilla also pointed out the country’s lack of broadband privacy rules, which were killed by Congress in 2017 at the request of ISPs.

But, that appears to now be in the past, with a signed agreement between the two companies as of March, and an expectation that Comcast’s encrypted DNS will come to Chrome soon enough as well.

SSL.com’s takeaway: It’s good to see an ISP getting on board with encrypted DNS, but you should still read Comcast’s Xfinity privacy policy if you’re a customer.

AddTrust External CA Root Certificate Has Expired

The AddTrust External CA root certificate expired on May 30, 2020. Though most users won’t be affected by this expiration, it’s still noteworthy. Some certificates issued in the past by SSL.com chain to Sectigo’s USERTrust RSA CA root via an intermediate cross-signed by the AddTrust root. This was done to ensure compatibility with legacy devices that do not include the USERTrust root.

Luckily, devices that do include the USERTrust root, which are the vast majority, will not be impacted by the expiration. In that case, which will be true for all modern browsers, operating systems and mobile devices,  the software will simply choose a trust path leading to USERTrust and ignore the expired AddTrust certificate. We explained this all at the beginning of the month, so if you’re looking for more details, you might want to head over to our June 2 blog post. To maintain compatibility with older devices, website owners with SSL.com USERTrust certificates can download replacement intermediate and root certificates via the buttons below:



Users relying on older SSL/TLS clients, including OpenSSL 1.0.x and GnuTLS, should remove the expired AddTrust certificate from their OS root store. See our blog post for links to fixes for Red Hat Linux and Ubuntu.

SSL.com’s takeaway: If you have USERTrust certificates issued by SSL.com, you can (and should!) download a new CA bundle from our website and install them on your server.
Thank you for visiting 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. You can also find answers to many common support questions in our knowledgebase.


Subscribe to SSL.com’s Newsletter

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

We’d love your feedback

Take our survey and let us know your thoughts on your recent purchase.