Featured Articles

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

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

Ephemeral Firefox as a Site-Specific Browser (3/3)

Site-Specific Ephemeral Firefox featured image showing a firewall between the facebook and firefox icons

This article is a part 3/3 of a series describing how to setup an Ephemeral Firefox session as a Site-Specific Browser. The ultimate goal is to be able to have a self-destructing browsing session that can only access a single company’s services, such as Google or Facebook.

Part 1/3: Ephemeral Firefox in Ubuntu Part 2/3: Ephemeral Firefox with Extensions Part 3/3: Ephemeral Firefox as a Site-Specific Browser

After setting up the Site-Specific Ephemeral Firefox Browser, you can then blacklist services designated to your Site-Specific browser(s) (such as Google or Facebook) from your main browser. This significantly improves your ability to browse the internet without your activity being tracked by these companies — leaving your sensitive data vulnerable to being stolen by hackers.

Michael Altfield

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

About Michael


. . . → Read More: Ephemeral Firefox as a Site-Specific Browser (3/3)

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

Let’s Encrypt!

Finally, this website is (only) accessible over https!

Michael Altfield

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

About Michael

tech.michaelaltfield.net/