Featured Articles

Trusted Boot (Anti-Evil-Maid, Heads, and PureBoot)
Introducing BusKill: A Kill Cord for your Laptop
Crowdfunding on Crowd Supply (Review of my experience)
Nightmare on Lemmy Street (A Fediverse GDPR Horror Story)
Continuous Documentation: Hosting Read the Docs on GitHub Pages (2/2)
Detecting (Malicious) Unicode in GitHub PRs
WordPress Profiling with XHProf (Debugging & Optimizing Speed)
WordPress Multisite on the Darknet (Mercator .onion alias)
Hardening Guide for phpList
previous arrow
next arrow

3TOFU: Verifying Unsigned Releases

Verifying Unsigned Releases with 3TOFU

This article introduces the concept of “3TOFU” — a harm-reduction process when downloading software that cannot be verified cryptographically.

⚠ NOTE: This article is about harm reduction.

It is dangerous to download and run binaries (or code) whose authenticity you cannot verify (using a cryptographic signature from a key stored offline). However, sometimes we cannot avoid it. If you’re going to proceed with running untrusted code, then following the steps outlined in this guide may reduce your risk.

TOFU

TOFU stands for Trust On First Use. It’s a (often abused) concept of downloading a person or org’s signing key and just blindly trusting it (instead of verifying it).

3TOFU

3TOFU is a process where a user downloads something three times at three different locations. If-and-only-if all three downloads are identical, then you trust it.

Why 3TOFU?

The EFF’s Deep Crack proved DES to be insecure and pushed a switch to 3DES.

During the Crypto Wars of the 1990s, it was illegal to export cryptography from the United States. In 1996, after intense public pressure and legal challenges, the government officially permitted export with the 56-bit DES cipher — which was a known-vulnerable cipher.

But there
. . . → Read More: 3TOFU: Verifying Unsigned Releases

Nightmare on Lemmy Street (A Fediverse GDPR Horror Story)

Nightmare on Lemmy "A Fediverse GDPR Horror Story"

This article will describe how lemmy instance admins can purge images from pict-rs (click here if you just want to know how).

This is (also) a horror story about accidentally uploading very sensitive data to Lemmy, and the (surprisingly) difficult task of deleting it.

Intro

tl;dr I (accidentally) uploaded a photo of my State-issued ID to Lemmy, and I couldn’t delete it.

Friends don’t let friends compose jerboa comments in bed before coffee (@theyshane)

A few weeks ago I woke up to my 06:00 AM alarm, snoozed my phone, rubbed my eyes, and started reading /c/worldnews (on Lemmy).

Still half-asleep, I was typing a comment when my thumb accidentally hit the “upload media” button. Up popped a gallery of images. I tried to click the back button, but I missed. I tapped on a photo. The photo that I tapped-on was a KYC selfie image (that I took the previous day for a service that has no business having such PII anyway).

That was all it took — two consecutive mis-taps while half-asleep in bed, and my dumb-ass just inadvertently uploaded a KYC selfie onto the public internet. And thanks to archaic State authentication systems, anyone with
. . . → Read More: Nightmare on Lemmy Street (A Fediverse GDPR Horror Story)

Trusted Boot (Anti-Evil-Maid, Heads, and PureBoot)

Verifying Boot Integrity with Heads, PureBoot

This post will help to provide historical context and demystify what’s under the hood of Heads, PureBoot, and other tools to provide Trusted Boot.

I will not be presenting anything new in this article; I merely hope to provide a historical timeline and a curated list of resources.

Intro

The Librem Key cryptographically verifies the system’s integrity and flashes red if it’s detected tampering

I’ve always felt bad about two things:

Because I run QubesOS, I usually disable “Secure Boot” on my laptop I travel a lot, and I don’t have a good way to verify the integrity of my laptop (eg from an Evil Maid that gains physical access to my computer)

To address this, I have turned to Heads and PureBoot — a collection of technologies including an open-source firmware/BIOS, TPM, and a USB security key that can cryptographically verify the integrity of the lowest firmware (and up the chain to the OS).

While Purism has written many articles about PureBoot and has some (minimal) documentation, I found they did a lot of hand waving without explaining how the technology works (what the hell is a “BIOS measurement”?). So I spent a great deal of
. . . → Read More: Trusted Boot (Anti-Evil-Maid, Heads, and PureBoot)

Monitoring Tor .onion Websites (uptime alerts)

Uptime Monitoring of Tor .onion Websites

This article will present a few simple website availability monitoring solutions for tor onion services.

Problem

So you’ve just setup an Onion Service for your website, but how often do you actually check that it’s working? Maybe it’s a .onion alias to an existing website, and you usually only check it on the clearnet. What’s to prevent the darknet presence of your website from going down for weeks without you noticing?

Indeed, it’s important to monitor your .onion websites so that you can discover and fix issues before your customers do. But how? Most of the popular uptime monitoring solutions (pingdom, freshping, statuscake, etc) certainly can’t monitor .onion websites.

This guide will enumerate some solutions for monitoring .onion websites, so you get an email alert if your site goes down.

Michael Altfield

Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡

About Michael


. . . → Read More: Monitoring Tor .onion Websites (uptime alerts)

WordPress Multisite on the Darknet (Mercator .onion alias)

How to use a .onion with Wordpress Multisite

This article will describe how to point a .onion domain at your existing wordpress sites (on wordpress multisite) so that your website will be accessible both on the clearnet and directly on the darknet via a .onion domain.

Intro

There are numerous security benefits for why millions of people use tor every day. Besides the obvious privacy benefits for journalists, activists, cancer patients, etc — Tor has a fundamentally different approach to encryption (read: it’s more secure).

Instead of using the untrustworthy X.509 PKI model, all connections to a v3 .onion address is made to a single pinned certificate that is directly correlated to the domain itself (the domain is just a hash of the public key + some metadata).

Moreover, some of the most secure operating systems send all the user’s Internet traffic through the Tor network — for the ultimate data security & privacy of its users.

In short, your users are much safer communicating to your site using a .onion domain than its clearnet domain.

For all these reasons, I wanted to make all my wordpress sites directly available to tor users. Unfortunately, I found that it’s not especially easy to point a .onion domain at
. . . → Read More: WordPress Multisite on the Darknet (Mercator .onion alias)

We’re on the Darknet! Visit this site at our tor .onion

Visit this site on our .onion

This website is now accessible on the darknet. And how!

Why

Fun fact: the most popular website on the darknet is facebook. There are hundreds of other popular sites on the darknet, including debian, the CIA, the NYT, the BBC, ProPublica, and–now–michaelaltfield.net.

michaelahgu3sqef5yz3u242nok2uczduq5oxqfkwq646tvjhdnl35id.onion

michaelahgu 3sqef5yz3u2 42nok2uczdu q5oxqfkwq64 6tvjhdnl35i     d.onion

All of these organizations chose to make their websites available over .onion addresses so their website will be accessible from millions of daily tor users without leaving the darknet. Besides the obvious privacy benefits for journalists, activists, cancer patients, etc — Tor has a fundamentally different approach to encryption (read: it’s more secure).

Instead of using the untrustworthy X.509 PKI model, all connections to a v3 .onion address is made to a single pinned certificate that is directly correlated to the domain itself (the domain is just a hash of the public key + some metadata).

Moreover, some of the most secure operating systems send all the user’s Internet traffic through the Tor network — for the ultimate data security & privacy of its users.

In short, your users are much safer communicating to your site using a .onion domain than its clearnet domain.

For all these reasons, I
. . . → Read More: We’re on the Darknet! Visit this site at our tor .onion

New Thumb Drive Encryption Procedure

In this article, I’ll describe a procedure for preparing a brand-new USB flash drive for use. First we’ll securely erase all the data on the drive, then we’ll encrypt the entire drive, and–finally–we’ll check the drive for bad blocks.

Ah, remember the good-ole days of spinning disks? When your OS could tell your hard *disk* to shred a specific sector? Like it or not, those days are gone in the land of USB flash volumes.

There’s a lot of great reads on the complications of securely erasing data on a USB thumb drive. Unfortunately, a lot of the techniques are not universal to all technologies or manufacturers. Consequently, my approach is more ignorant, straight-forward, and broad (at the risk of causing these cheap usb drives to fail sooner & the process taking longer):

First, I make sure never to write any unencrytped data to the disk Second, when I want to wipe the disk, I fill it entirely with random data

Below are the commands that I use to prepare a new usb drive for my use immediately after purchase. These commands are presented as a rough guide; they’re mostly idempotent, but you probably want to copy & paste them
. . . → Read More: New Thumb Drive Encryption Procedure

How to check the Public Key Algorithm used for a given gpg key (ie: RSA vs DSA)

Today I discovered how to validate the Public Key Algorithm that’s used for a given gpg key. Unfortunately, it’s extremely unintuitive & took quite a bit of digging to figure out how. So I’m leaving this here in hopes it helps someone in their future searches.

Michael Altfield

Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡

About Michael


. . . → Read More: How to check the Public Key Algorithm used for a given gpg key (ie: RSA vs DSA)

HPKP Best Practices for Let’s Encrypt

This post describes how to generate a few backup public key hashes to add to your HTTP Public Key Pinning (HPKP) config that might save you from bricking your domain if Let’s Encrypt ever gets untrusted like StartCom did.

If you have a healthy distrust of the X.509 PKI trust model, then you’ve probably heard of HPKP (and probably also HSTS & CAA). Website certificate pinning was a trend first started by google, who hard-coded a pin of their certificates in their Chrome browser. Eventually, google helped build a more standardized pinning method under RFC 7469. And today, it’s supported by Chrome, Firefox, and Opera.

Pinning is a great TOFU improvement to https, but–if misconfigured–you could “brick” your domain–making it so that your client’s browsers will refuse to let them access your site for months or years (interestingly, this has also caused some security experts to think of how HPKP could be abused in ransom-ware). Therefore, it’s a good idea to follow a few HPKP Best Practices.

Michael Altfield

Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡

About Michael


. . . → Read More: HPKP Best Practices for Let’s Encrypt