SSL.com wishes all of our customers and visitors a happy, safe, and healthy holiday season, and a prosperous 2021! We hope that the new year will turn out to be slightly less, umm… interesting than 2020 has been in some ways, but we’re sure that not a month will go by without important news from the the world of network security, digital certificates, and PKI.
OpenSSL DoS Vulnerability
We covered this issue in a blog post earlier this month, but it’s worth repeating. A high-severity vulnerability in OpenSSL was discovered that affects all versions of OpenSSL 1.0.2 and 1.1.1 prior to 1.1.1i. This vulnerability could be exploited to create a denial of service (DoS) attack. OpenSSL 1.1.1i, released on December 8, 2020, includes a fix.
OpenSSL users should update their installations as soon as possible. There are two paths to apply the fix:
- Users of OpenSSL 1.1.1 and unsupported 1.0.2 users should upgrade to 1.1.1i.
- Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2x.
OpenSSL is currently installed on the majority of HTTPS web servers. You can read more about the vulnerability in SSL.com’s blog, and in the OpenSSL Project’s Security Advisory.
Cloudflare Advocates New Privacy Protocols
Tim Anderson reported in The Register that Cloudflare is “pushing for the adoption of new internet protocols it says will enable a ‘privacy-respecting internet.'” These protocols include privacy-enhanced DNS over HTTPS (DoH), additional encryption for the TLS handshake, and security improvements for the handling of user passwords.
Oblivious DoH
DNS over HTTPS (DoH) addresses a weak link in internet privacy by encrypting DNS queries and responses, which have historically been sent as plaintext. Oblivious DoH (ODoH) takes DNS privacy protection a step further by preventing DoH servers from knowing the client’s IP address:
The essence of ODoH is that it introduces a network proxy between the client and the DoH server. The proxy has no visibility into the DNS query, which can only be read by the DoH server. The server has no knowledge of the client’s IP address. The query is private, provided the proxy and server do not collude.
Cloudflare has already declared support for ODoH, which was developed by engineers at Cloudflare, Apple, and Fastly. You can learn more by checking out their paper at arxiv.org.
Encrypted Client Hello (ECH)
Encrypted Client Hello (ECH) offers enhanced handshake encryption in TLS, going beyond Encrypted SNI (ESNI), which only protects Server Name Indication (SNI) in the TLS handshake. Cloudflare research engineer Christopher Patton writes,
While ESNI took a significant step forward, it falls short of our goal of achieving full handshake encryption. Apart from being incomplete — it only protects SNI — it is vulnerable to a handful of sophisticated attacks, which, while hard to pull off, point to theoretical weaknesses in the protocol’s design that need to be addressed.
…
Ultimately, the goal of ECH is to ensure that TLS connections made to different origin servers behind the same ECH service provider are indistinguishable from one another.
Unsurprisingly, since ECH “only makes full sense alongside DoH, and in the context of a CDN (content distribution network),” Cloudflare “sees itself as a likely ECH provider.” You can read more about ECH in the IETF’s draft proposal.
OPAQUE Passwords
OPAQUE passwords—”some sort of pun on Oblivious Pseudo-Random Function (OPRF) combined with Password Authenticated Key Exchange (PAKE)”—is a mechanism to completely avoid transfer of a user’s password to a server. OPAQUE achieves this by “having the server and client jointly calculate a salted hash to compare using an intermediary second salt. This ensures the server cannot learn the user’s password during authentication, and the user doesn’t learn the server’s secret salt.”
You can find out much more about OPAQUE passwords in this paper [PDF link] by researchers at the University of California, Irvine and IBM, and in Cloudflare engineer Tatiana Bradley’s blog post.
Leaked FTP Credentials Possibly Linked to SolarWinds Attack
Unless you’ve been spending the past few weeks in a remote, off-grid cabin (not a bad idea now that we think of it), you’ve probably heard a fair amount already about the supply-chain attack that compromised SolarWinds’ Orion IT monitoring software and many of its users in government and industry. Ravie Lakshmanan’s December 16 story in the Hacker News discusses how the attackers “likely managed to compromise the software build and code signing infrastructure of SolarWinds Orion platform as early as October 2019 to deliver the malicious backdoor through its software release process.”
The idea… was to compromise the build system, quietly inject their own code in the source code of the software, wait for the company to compile, sign packages and at last, verify if their modifications show up in the newly released updates as expected.
The October 2019 timeline aligns with security researcher Vinoth Kumer’s discovery, in November 2019, of a public GitHub repo leaking plaintext FTP credentials for Solarwinds’ update server—and that this server was accessible with the password “solarwinds123.” The repo in question had been open to the public “since 17 June 2018,” giving would-be attackers plenty of time to discover and exploit the leaked credentials.
Of course, it didn’t help that SolarWinds also advised users to disable security measures:
To make matters worse, malicious code added to an Orion software update may have gone unnoticed by antivirus software and other security tools on targeted systems owing to SolarWinds’ own support advisory, which states its products may not work properly unless their file directories are exempted from antivirus scans and group policy object (GPO) restrictions.
