Both food security and cybersecurity appear to be on the decline at the Food and Agriculture Organization of the United Nation’s website.
Mind you, this is an organization with an annual budget north of US $1 billion.
Just another nerd.
Both food security and cybersecurity appear to be on the decline at the Food and Agriculture Organization of the United Nation’s website.
Mind you, this is an organization with an annual budget north of US $1 billion.
Let’s Encrypt recently announced that it had issued its billionth certificate on February 27, 2020.
We issued our billionth certificate on February 27, 2020. We’re going to use this big round number as an opportunity to reflect on what has changed for us, and for the Internet, leading up to this event. In particular, we want to talk about what has happened since the last time we talked about a big round number of certificates – one hundred million.
One thing that’s different now is that the Web is much more encrypted than it was. In June of 2017 approximately 58% of page loads used HTTPS globally, 64% in the United States. Today 81% of page loads use HTTPS globally, and we’re at 91% in the United States! This is an incredible achievement. That’s a lot more privacy and security for everybody.
Another thing that’s different is that our organization has grown a bit, but not by much! In June of 2017 we were serving approximately 46M websites, and we did so with 11 full time staff and an annual budget of $2.61M. Today we serve nearly 192M websites with 13 full time staff and an annual budget of approximately $3.35M. This means we’re serving more than 4x the websites with only two additional staff and a 28% increase in budget. The additional staff and budget did more than just improve our ability to scale though – we’ve made improvements across the board to provide even more secure and reliable service.
NoSnoop is a Windows-based tool that will let users know if their SSL is being subjected to a man-in-the-middle attack.
NoSnoop is a standalone, browser-independent application that will perform SSL/TLS handshakes with a list of 250 popular websites and examine the certificate chains received from each server. It will alert on any unexpected certificates.
NoSnoop will check for obvious cases (such as interception by a local proxy, your employer’s SSL inspection gateways, or a malware infection), as well as more advanced attacks (for instance, if the root cert is valid but issued by an unexpected organization or country).
An entire scan typically takes less than 30 seconds.
This is currently in beta, so “bugs and/or false positives detections should be expected.”
Apparently, Google is automatically adding some of its TLDs to browser HSTS lists–i.e., it is impossible to access any registered domains on those TLDs without using SSL on modern browsers.
As someone who likes to see as much Internet traffic encrypted by default, I think that’s kind of cool. As someone who owns quite a few domains on those TLDs, it is annoying that this was never disclosed when I purchased those domains.
Yes, HSTS is very good, but this can create some unexpected problems. There are occasionally situations where you may need to do an http call in the process of configuring or testing a site, and registrars need to be more upfront that this is not going to be possible with these Google-administered TLDs.
So Google has built HTTPS protection directly into a handful of top-level domains—the suffixes at the end of a URL like “.com.” Google added its internal .google top-level domain to the preload list in 2015 as a sort of pilot, and in 2017 the company started using the idea more extensively with its privately run suffixes “.foo” and “.dev.” But in May 2018, Google launched public registrations of “.app,” opening up automatic, preloaded encryption to anyone that wanted it. In February of this year, it opened up .dev to the public as well.
Which means that today, when you register a site through Google that uses “.app,” “.dev,” or “.page,” that page and any others you build off it are automatically added to a list that all mainstream browsers, including Chrome, Safari, Edge, Firefox, and Opera, check when they’re setting up encrypted web connections. It’s called the HTTPS Strict Transport Security preload list, or HSTS, and browsers use it to know which sites should only load as encrypted HTTPS automatically, rather than falling back to unencrypted HTTP in some circumstances. In short, it fully automates what can otherwise be a tricky scheme to set up.
“Web security stuff is complicated, and not every end user or even every site creator understands all of the complexities,” says Ben Fried, Google’s chief information officer. “The thing that I like about using these new top-level domains in this way is it dramatically decreases the burden on each site creator to get to the best practices. Nothing has to be done, because every subdomain in that top-level domain is HTTPS only and the browser won’t even try to access it any other way.”
The breakthrough moment came from engineer Ben McIlwain’s realization that an entire top-level domain could go on the preload list. “Internally it took off from there,” Fried says. “We realized these are two things that had developed independently that all of a sudden were way more powerful when combined.”
Why the f— is ESPN still not using TLS in 2019? This is extremely irresponsible behavior from a company owned by one of the largest media companies in the world (Disney). There are zero excuses for putting its users at risk this way.
Mozilla’s Lin Clark has a cartoon guide to DNS over HTTPS that . . . well . . . bottom line, there is no way to talk about DNS over HTTPS without getting fairly technical (one of the subheads on Lin’s lengthy pice is “What isn’t fixed by TRR with DoH?”) but this is probably as close as anyone is going to get.