Tag: Encryption

Let’s Encrypt Crosses Billion Certificates Issued Threshold

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.

Session–Send Messages Not Metadata

Session is “an end-to-end encrypted messenger that removes sensitive metadata collection, and is designed for people who want privacy and freedom from any forms of surveillance.”

Available for Android, iOS, Mac, Windows, and Linux, Session aims to up the ante on secure messaging apps by eliminating the collection of metadata such as phone numbers from users. When signing up for a Session account, users are assigned a Session ID, which is a public key, but that Session ID is not connected to any personal information about the user.

What will Session do if compelled by a court to reveal user identities?

As Session is a project of the Loki Foundation, court orders in situations such as this would be targeted at the Foundation.

The Loki Foundation would comply with lawful orders. However, the Loki Foundation could not reveal user identities simply because the Foundation does not have access to the data required to do so. Session account creation does not use or require email addresses or phone numbers. Session IDs (which are public keys) are recorded, but there is no link between a public key and a person’s real identity, and due to Session’s decentralised network, there’s also no way to link a Session ID to a specific IP address.

The most the Loki Foundation could provide, if compelled to do so, would be tangential information such as access logs for the getsession.org website or statistics collected by the Apple App Store or Google Play Store.

The folks behind Session have a technical white paper explaining how the system works, Session: A Model for End-To-End Encrypted Conversations With Minimal Metadata Leakage.

Firefox Enables DNS over HTTPS

Mozilla created a bit of controversy today by enabling DNS over HTTPS by default in the United States.

DoH will encrypt DNS traffic from clients (browsers) to resolvers through HTTPS so that users’ web browsing can’t be intercepted or tampered with by someone spying on the network. The resolvers we’ve chosen to work with so far – Cloudflare and NextDNS – have agreed to be part of our Trusted Recursive Resolver program. The program places strong policy requirements on the resolvers and how they handle data. This includes placing strict limits on data retention so providers- including internet service providers – can no longer tap into an unprotected stream of a user’s browsing history to build a profile that can be sold, or otherwise used in ways that people have not meaningfully consented to. We hope to bring more partners into the TRR program.

I agree with Bruce Schneier that this “is a great idea, and long overdue.”

A lot of the criticism of DNS over HTTPS is reminiscent of the criticism over TLS 1.3. Enterprises took advantage of poor security in DNS and TLS 1.2 to manage their networks, which is understandable. But we shouldn’t kneecap the security of the 3.2 billion people worldwide who use the Internet in favor of special interests.

A lot of that criticism also involves “experts” talking out of both sides of their mouths. For example, Caitlin Cimpanu offers contradictory complaints in ZDNet that, on the one hand, DoH doesn’t prevent ISPs or other network providers from tracking users.

But, in the same article, Cimpanu argues that DoH bypasses enterprise policies because it makes it impossible for those enterprises to track users.

80% of Android Apps Use TLS to Encrypt Traffic

Back in 2018, Google announced that beginning with Android 9, it would prevent apps from using unencrypted connections by default. As of December 2019, Google notes that 80 percent of all apps in the Google Play store use TLS, and that rises to 90 percent of all apps targeting Android 9 and higher.

Android 7 (API level 24) introduced the Network Security Configuration in 2016, allowing app developers to configure the network security policy for their app through a declarative configuration file. To ensure apps are safe, apps targeting Android 9 (API level 28) or higher automatically have a policy set by default that prevents unencrypted traffic for every domain.

Today, we’re happy to announce that 80% of Android apps are encrypting traffic by default. The percentage is even greater for apps targeting Android 9 and higher, with 90% of them encrypting traffic by default.

Since November 1 2019, all app (updates as well as all new apps on Google Play) must target at least Android 9. As a result, we expect these numbers to continue improving. Network traffic from these apps is secure by default and any use of unencrypted connections is the result of an explicit choice by the developer.

That last sentence is a bit concerning. If app developers want to explicitly make their apps communicate through unencrypted connections, that’s fine, but as far as I can tell there is no way that consumers are made aware of this.

Just as modern browsers warn me that the website I’m visiting doesn’t use encryption, Google should inform users when they are using apps that do so as well. I’d be happy with a notification on the Google Play store page for such apps that “This app sends network traffic over unencrypted channels” or something like that.

(Yes, users could set up a packet analysis tool to look at the data their phone is sending, but they shouldn’t have to do so).

NoSnoop–A Windows Tool for Detecting HTTPS Interception Attacks

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.”

PrivateBin–A Self-Hosted, Zero Knowledge Encrypted Pastebin

PrivateBin is a self-hosted pastebin where the hosting server has zero knowledge about the contents of any pasted data. PrivateBin encrypts and decrypts the pasted data in the browser using AES 256.

What PrivateBin provides

* As a server administrator you don’t have to worry if your users post content that is considered illegal in your country. You have no knowledge of any of the pastes content. If requested or enforced, you can delete any paste from your system.

* Pastebin-like system to store text documents, code samples, etc.

* Encryption of data sent to server.

* Possibility to set a password which is required to read the paste. It further protects a paste and prevents people stumbling upon your paste’s link from being able to read it without the password.

PrivateBin has a fairly well thought-out set of features, including the ability to set expiration dates, and even a burn-after-reading option so that the paste is deleted from the server after it is accessed.