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.
Unfortunately, this is likely to prove a bit more challenging than HTTPS Everywhere because of issues with STARTTLS,
Although many mailservers enable STARTTLS, most still do not validate certificates. Without certificate validation, an active attacker on the network can read and even modify emails sent through your supposedly “secure” connection. Since it’s not common practice to validate certificates, there’s often little incentive to present valid certificates in the first place. A brief experiment on Censys shows that about half of the mailservers that support STARTTLS use self-signed certificates.
. . .
When two mailservers support STARTTLS, their insecure connection is opportunistically upgraded to a secure one. In order to make that upgrade, the two mailservers ask each other if they support STARTTLS. Since this initial negotiation is unencrypted, network attackers can alter these messages to make it seem like neither server supports STARTTLS, causing any emails to be sent unencrypted. ISPs in the U.S. and abroad have been caught doing exactly this, and in 2014, several researchers found that encryption on outbound email from several countries were being regularly stripped.
But you have to start somewhere, and the EFF should be commended for going beyond simply issuing policy prescriptions and recommendations, and doing a lot of the heavy lifting to improve end user security.
So I got my Note 8 and started going the laborious, multi-day process of moving all of my apps, data and settings when I ran into an odd roadblock. I couldn’t get my Note 8 to encrypt my SD card.
I’ve got a 200gb microSD card that I unencrypted on my V20 and had been using without an issue in my Note 8. Since it can take hours to for Android to encrypt such a large microSD I waited until the end of the day and got the encryption process going.
Except rather than actually encrypt the microSD card, the process was stuck for about 20 minutes (way too long) with this message:
Encrypting SD card: 0%
It never advanced past that. A couple Google searches only turned up a single forum post about that specific problem, though there were other posts regarding Android getting stuck encrypting SD cards. One of the replies to the user who had the same problem I was experiencing set off a light bulb in my head:
Is your lockscreen locked with a password? If not, the SD card won’t encrypt. (You should be given that message as soon as you try to encrypt it.)
Okay, I’ve got a lockscreen password set, so it should start encry….hey, wait a minute, it couldn’t possibly be… oh, FFS, it is.
So, I own a Samsung Gear S3 watch. Typically I set my phone up so that it will unlock without having to enter my phone password as long as it is connected via Bluetooth to the watch.
And wouldn’t you know it, the second I disabled that feature on the phone, the encryption process actually started.
Okay, that’s ridiculous. If having something like that option turned on is going to prevent the OS from encrypting the microSD card, then the OS shouldn’t allow the users to choose “Encrypt SD card” until the unlock feature causing the problem is resolved.
The “Encrypt SD Card” button should be grayed out with a message like:
This device can be unlocked by the presence of a paired Bluetooth device. The SD card cannot be encrypted while the phone is configured this way.
A better option would be to allow the user to encrypt the microSD card in this state, since it applies only to the initial encrypting of the card rather than its ongoing use.
What’s the point of the system refusing to allow you to encrypt a microSD card if the device can be unlocked by the a Bluetooth device, when it’s going to allow the user to routinely access the data on the microSD card via this method once it is finally encrypted?
Let’s Encrypt announced this week that they’d passed the 100 million certificates issued threshhold,
Let’s Encrypt has reached a milestone: we’ve now issued more than 100,000,000 certificates. This number reflects at least a few things:
First, it illustrates the strong demand for our services. We’d like to thank all of the sysadmins, web developers, and everyone else managing servers for prioritizing protecting your visitors with HTTPS.
Second, it illustrates our ability to scale. I’m incredibly proud of the work our engineering teams have done to make this volume of issuance possible. I’m also very grateful to our operational partners, including IdenTrust, Akamai, and Sumo Logic.
Third, it illustrates the power of automated certificate management. If getting and managing certificates from Let’s Encrypt always required manual steps there is simply no way we’d be able to serve as many sites as we do. We’d like to thank our community for creating a wide range of clients for automating certificate issuance and management.
The press release also notes that when Let’s Encrypt began issuing certificates, Firefox’s Telemetry report found that
. . . less than 40% of page loads on the Web used HTTPS . . . In the 19 months since we launched, encrypted page loads have gone up by 18%, to nearly 58%.
A very good trend.
With the demise of TrueCrypt and the abandonment of DiskCryptor, VeraCrypt is the best remaining free, open source disk encryption solution. It is a fork of TrueCrypt project that made a number of changes designed to address limitations of TrueCrypt.
I’ve been gradually migrating all of my encrypted hard drives over to VeraCrypt and have been very pleased with its performance and ease-of-use.