The Holidays are here, somehow, and so is the November SSL.com newsletter. This year, holiday prep might seem more overwhelming than ever. It might even seem like keeping on top of your Internet security is too daunting a task to tackle. We’re here to tell you that type of thinking is nonsense—just look at all the things that happened last month!
SSL.com Supports the ACME Protocol
On November 13, SSL.com announced support for the ACME protocol. Now our customers can easily take advantage of this popular SSL/TLS automation tool.
Originally developed the Internet Security Research Group and published as an internet standard in RFC 8555, ACME simplifies renewal and replacement of SSL/TLS certificates. That makes it easier for website owners to stay up-to-date with certificates on their sites.
You can find out more about the advantages of SSL.com’s ACME implementation in our blog post announcing the launch. When you’re ready to get started, check out our guide to certificate issuance and revocation with ACME, and our how-to on ACME automation for the Apache and Nginx server platforms.
Congress Approves IoT Cybersecurity Bill
Passed by the U.S. Congress on November 17, 2020 and heading to the White House for the President’s signature, the Internet of Things Cybersecurity Improvement Act “requires the National Institute of Standards and Technology (NIST) and the Office of Management and Budget (OMB) to take specified steps to increase cybersecurity for Internet of Things (IoT) devices.”
In an article on Threat Post, Lindsey O’Donnell explains that the federal measure is designed to put an end to the security and privacy issues that have long dogged IoT devices, and it does so in a way that aligns with existing industry standards and best practices. She writes:
The IoT Cybersecurity Improvement Act has several different parts. First, it mandates that (National Institute of Standards and Technology) must issue standards-based guidelines for the minimum security of IoT devices that are owned by the federal government. The Office of Management and Budget (OMB) must also implement requirements for federal civilian agencies to have information-security policies that are consistent with these NIST guidelines.
Under the law, federal agencies must also implement a vulnerability-disclosure policy for IoT devices, and they cannot procure devices that don’t meet the security guidelines.
O’Donnell further reports that the effort to regulate the IoT continues to be a worldwide effort, with security recommendations from the European Union Agency for Network and Information Security and promises from the United Kingdom to issue requirements for passwords and security updates.
HTTPS-Only Mode Offered in Firefox 83
Mozilla’s Firefox 83, released on November 17, offers users an HTTPS-Only Mode. By enabling it, the browser will automatically seek out HTTPS connections and ask for permission before proceeding to a site that does not support secure connections. As Mozilla’s blog post reminds us, the regular HTTP protocol is viewable by those looking to steal or tamper with data. HTTP over TLS, or HTTPS, fixes that by creating an encrypted connection between your browser and the website you are visiting, which would-be attackers cannot read.
Though most sites nowadays do support HTTPS, some sites still rely on HTTP. Or, sometimes, an insecure HTTP version of a website is the one stored in your bookmarks or reached via legacy links, and can be the default without the help of a browser that prioritizes secure HTTPS connections.
As the Mozilla blog explains, turning on the new mode now is easy:
If you are eager to try this new security enhancing feature, enabling HTTPS-Only Mode is simple:
- Click on Firefox’s menu button and choose “Preferences”.
- Select “Privacy & Security” and scroll down to the section “HTTPS-Only Mode”.
- Choose “Enable HTTPS-Only Mode in all windows”.
Apple’s Handling of OCSP Requests Raises Privacy Concerns
This month, a couple of folks sounded the alarm about Big Sur after server problems revealed Apple is tracking, and revealing, a heck of a lot about its users when checking signed application code. Essentially, the certificate-checking code was sending out a developer’s “digital fingerprint” via plain text HTTP whenever an application was launched. What does that mean? Thomas Claburn of The Register puts it succinctly enough: “Apple as well as anyone eavesdropping on the network path can at least link you by your public IP address to the kinds of application you use.”
In the wake of this information being made public, Apple promised to no longer log IP addresses. Also from The Register article:
To further protect privacy, we have stopped logging IP addresses associated with Developer ID certificate checks, and we will ensure that any collected IP addresses are removed from logs,” Apple said.
The Silicon Valley titan also said it plans to implement an encrypted protocol for developer ID certificate revocation checks, to take steps to make its servers more resilient, and to provide users with an opt-out mechanism. The Register understands that the certificate checks are cryptographically signed by Apple, so they cannot be tampered with in transit without detection, though they can be observed, and so now Apple will wrap that communication channel in encryption to shield it from prying eyes.
In addition, Apple has stopped allowing third-party apps like firewalls and VPNs to block or monitor traffic from its own apps and operating system processes to Apple’s servers in Big Sur. This is a problem for those who want to comprehensively analyze their network traffic, or simply don’t want their traffic going to Apple servers.
Though the Register article takes a solemn tone, it’s pretty measured. For a more passionate end-of-days interpretation, Jeffery Paul also breaks down the security implications on his blog.