I was naive and thought that a lot of the issues surrounding Web browser/server security would be resolved with some significant changes agreed to by operating system makers, non-OS browser developers, and the parties that provide verification, called certificate authorities (CAs), which took place January 1, 2016.
Oh, how young and foolish was I. But real improvements have taken place, and nearing the end of 2016, you may already have seen how browsers provide you a more descriptive—and some prescriptive—alert about problems with the certificates passed by a server to a browser to create a secure connection. In some cases, you may already have been blocked from a connection, or required to approve an exception to proceed.
This is all good, partly because it helps prevent your information from being captured by malicious parties or swept up by wide-reaching, sometimes illegal government interception—any country, not just your own—and partly because more of what’s happened this year, especially recently, doesn’t require you to make any changes to gain the benefit.
It’s not just sniffing. Ne’er-do-wells with the right network position, including malware installed on, ahem, non-Macs and non-iOS devices on a local network, can insert themselves into an unsecured connection and drop in a virus-laden download instead of a legitimate one you thought you were retrieving, among other nasty tricks. This was a possibility with
the widely used Sparkle update framework, since patched. But some developers still host their software downloads on unencrypted servers.
Apple removes a CA, as do others
Web encryption requires that browser and OS makers trust CAs, who use protected cryptographic elements so that when a Web server you visit presents a certificate that identifies the server as associated with a particular domain name, you can be sure it’s a legitimate association. That’s part of the web of trust, and it requires browser and OS makers and CAs to act with integrity and transparency.
Some CAs slip up with security, with their process of allowing resellers to issue certificates, or with ethics, plain and simple. It’s rare, but CAs can be booted out of the trusted root programs run by Apple, Google, the Mozilla Foundation, and others. (You can find
a good summary of root trust at the Chromium Projects site.)
Back in April 2015, I
sniped at Apple for failing to drop CNNIC, a Chinese CA that appeared to be violating security policies. Mozilla and Google acted fast and dropped CNNIC; Apple and Microsoft did nothing. (Microsoft issued a weak security note.)
When a situation presented itself in September, Apple acted with more alacrity. The Mozilla Foundation discovered several weeks ago that the CA WoSign had what a Mozilla blog post described as a “number of technical and management problems.” WoSign operated under its own name, and also had acquired StartCom, a certificate-issuer I used to rely on for my SSL/TLS Web certificates. (You can
read all the details in Mozilla’s blog entry.)
One of these “problems” was issuing and backdating certificates signed with SHA-1, an outdated encryption algorithm that CAs had agreed, after years of prodding by Mozilla and other trusted root operators, to stop issuing. Because SHA-1 is considered “broken,” meaning malicious parties can potentially spoof a certificate that appears valid, it had to stop being used. (I
wrote about the particulars of SHA-1 in December 2015.)
presented a lengthy report, as the foundation operates in a community-driven transparent style. WoSign replied, and Mozilla evaluated its responses as unacceptable, and moved to remove WoSign and StartCom from its trusted list as of October 21.
That’s a good sign, though disappointing and surprising Microsoft remains behind the eight-ball here, as 18 months ago.
In Safari, Firefox, Chrome, and some other browsers—but not Internet Explorer—visting a site protected by a certificate signed by WoSign or StartCom that remains in place
generates a security warning.
More warnings, less worries
As I’ve written about over a couple of years, browser developers have ratcheted up the kind and nature of warnings displayed when you hit a site that’s using ineffectual or badly configured security. That includes every Web page that uses plain http, which sends all data between a browser and server as unencrypted text, as opposed to https, which uses SSL/TLS encrypted connections.
You may be seeing more routine warnings in Safari, if that’s your browser of choice. I know that I routinely receive warnings about certificate problems when I visit sites that are clearly just a bit out of date: the site’s owner failed to update a certificate, is feeding out a certificate for a domain that’s not listed in its security document, or another error that makes me stop and wonder what’s wrong. I used to use Safari’s method of bypassing a bad certificate, assuming that was just the way the Web rolled, but no longer. I try to report the problem to the Web owner or find the information elsewhere.
Web hosting services and other ways in which you might post material on the Web have been gradually moving to offering https by default and at no cost. For instance,
Squarespace just announced it would flip on certificates for all its customers with custom domains, and its users could even make an https connection the required method. (
Let’s Encrypt helped Squarespace; the project offers free basic certificates, and I’ve switched all my SSL to theirs.)
Better browser warnings, the elimination of outdated encryption, and a general shift to secured-by-default sites, no matter what the content of the site is, has pushed https usage way up. Google has been tracking secured connections via Chrome by platform, and half of pages loaded by desktop Chrome users in October are over https, up about 10 percent over just a few months.
Ultimately, the entire Web will be encrypted, and not for paranoia’s sake. Reducing points in insertion and eavesdropping allows you to live your online life more safely, whether it’s about others tracking your reading habits, your frineds—or your political activism.