September 2020 Security Roundup

Welcome to September’s edition of SSL.com’s monthly Security Roundup! Today we’ll be talking about:

• SSL.com’s brand-new newsletter
• Changes to the CA/B Forum’s EV SSL Guidelines
• Russia’s plans to ban protocols that hide the destination of internet traffic
• The Raccoon Attack on TLS versions 1.2 and earlier
• Insecure Internet of Things (IoT) practices
  

Announcing the SSL.com Newsletter!

SSL.com is proud to announce our new monthly email newsletter! Each month we’ll send you news and information about internet security, PKI, and digital certificates, along with information about new products and services offered by SSL.com. To sign up, simply fill out the form below. (You can easily unsubscribe at any time by clicking the unsubscribe link in each email we send.):

CA/B Forum Ballot SC30: Changes to EV SSL Certificate Guidelines

In news of interest to SSL.com’s EV SSL customers, the current version (1.7.3) of the CA/Browser Forum’s EV SSL Certificate Guidelines, which went into effect on August 20, 2020, has some new requirements. Specifically, as described in CA/B Forum Ballot SC30, certificate authorities (CAs), such as SSL.com, must now publish the list of Registration and Incorporating Agencies that they use when validating EV SSL certificate requests. (The move is in line with a larger goal to make EV validation sources consistent between CAs.)

As a result, SSL.com will publish a list of the information sources we use when validating businesses and other organizations for EV certificates. When we are unable to locate an applicant’s organization in our current list of sources, we will attempt to locate another viable information source and add it to our published list before validating the order and issuing the certificate.

Russia Plans to Ban Protocols that Hide Traffic’s Destination

This story might seem familiar, if you’ve kept up-to-date with digital security news. In fact, last month we reported on a story that China’s “Great Firewall” is now blocking HTTPS traffic that uses TLS 1.3 and ENSI (Encrypted Server Name Indication) in an effort to make it easier for Chinese censors to see what sites citizens are trying to visit and to control access to said sites.

This month, a report by Catalin Cimpanu in ZDNet explained that Russia is now looking to ban the use of some protocols with an update to technology laws that “would make it illegal to use encryption protocols that fully hide the traffic’s destination.” As noted in the article, these protocols would include TLS 1.3, DoH, DoT and ESNI. The reasoning is, of course, much like the reasoning behind China’s ban — the protocols impede surveillance and censorship’s reach by the state. From the article:

Russia doesn’t use a national firewall system, but the Moscow regime relies on a system called SORM that allows law enforcement to intercept internet traffic for law enforcement purposes right at the source, in telco data centers.
Furthermore, Russia’s telecommunications ministry, the Roskomnadzor, has been running a de-facto national firewall through its regulatory power over the local ISPs. For the past decade, Roskomnadzor has been banning websites it deemed dangerous and asking ISPs to filter their traffic and block access to the respective sites.
With TLS 1.3, DoH, DoT, and ESNI gaining adoption, all of Russia’s current surveillance and censorship tools will become useless, as they rely on having access to the website identifiers that leak from encrypted web traffic.

The law is currently under consideration, pending public feedback, and will return for a vote in early October. ZDNet notes that, given the climate, “it’s almost certain that the amendment will pass.”

New TLS Attack: Raccoon

We already have a blog post about the “Raccoon Attack,” but it’s worth mentioning again as the attack can allow third-parties to break SSL/TLS encryption to read communication meant to be kept secure. As explained in a recently published academic paper, the attack exploits a timing vulnerability in TLS versions 1.2 and earlier, and could decrypt communication that includes usernames, passwords, credit card data, and other sensitive information. From our post earlier this month:

While it sounds terrifying, keep in mind that this attack can only take place under very specific and rare circumstances: the server must reuse public Diffie-Hellman keys in the handshake (already considered bad practice), and the attacker must be able to make precise timing measurements. Furthermore, the browser must support the vulnerable cipher suites (as of June 2020 all the major browsers have dropped them).

The Internet of (Vulnerable) Things, Coffee Maker Edition

While the story above wasn’t actually about attacks by raccoons, this story is really about coffee makers. To be more precise, Dan Goodin’s article in Ars Technica is about how a coffee maker was turned into a “ransom machine” by exploiting common weaknesses in Internet of Things (IoT) devices.

Basically, the (poorly named) Smarter products’ iKettle has long been a target for those looking to illustrate the dangers of easily-hacked appliances. Since 2015, versions of the kettle have been remotely commandeered through reverse engineering. Though the company has released a new version of the pot since then, the old ones are still in use, and boy are they vulnerable to what the article notes are “out of the box” attacks. Recently, a programmer named Martin Hron decided to test the limits of what a security breach on a coffeepot could look like, in a worst-case scenario kind of way:

When Hron first plugged in his Smarter coffee maker, he discovered that it immediately acted as a Wi-Fi access point that used an unsecured connection to communicate with a smartphone app. The app, in turn, is used to configure the device and, should the user choose, connect it to a home Wi-Fi network. With no encryption, the researcher had no problem learning how the phone controlled the coffee maker and, since there was no authentication either, how a rogue phone app might do the same thing.
That capability still left Hron with only a small menu of commands, none of them especially harmful. So he then examined the mechanism the coffee maker used to receive firmware updates. It turned out they were received from the phone with—you guessed it—no encryption, no authentication, and no code signing.

There is an extensive blog post on the coffeemaker hack called “The Fresh Smell of Ransomed Coffee.” There’s also an amusing video demonstrating the chaos that ensued from exploiting the coffee machine’s vulnerabilities. While it’s unlikely that an attack such as this will be coming to anyone’s kitchen soon, it’s a good reminder that “smart” means more than “convenient.”