tashian

Fiddling with the knobs is the fun part. https://www.youtube.com/watch?v=la2u4VlGwbQ

The notion of "zero trust" shouldn't just mean corporations not having to inherently trust users and networks. It should also mean users not having to inherently trust corporations.

VPN providers all run the same two or three VPN protocols, all with similar security guarantees and privacy limitations.

I've been playing with MASQUE relays over the last year. Apple's iCloud Private Relay is a MASQUE relay (two, actually). MASQUE can offer genuine privacy improvements via traffic separation, preventing any single party from correlating the traffic source and destination.

Some of the privacy concerns of VPN users can be mitigated with better technology. And relays are built into Apple operating systems today. I'm surprised that they aren't very widely deployed yet.

I did a little synth project recently that uses an AudioWorklet processor to morph between single-cycle waveforms, and it worked super well. When I tried to do this with the Web Audio API, the audio would stutter when I moved the controls. Switching to an AudioWorklet thread eliminated the stuttering issue. So, if you need real-time sound shaping controls, you may find that AudioWorklet is a better fit.

https://waves.tashian.com

or to hide the AI content areas

Just copy/paste from the chat window. I kept running into token limits. I came away from it wanting a much better workflow.

That's the next step for me in learning AI... playing with different integrated editor tools.

I used Claude to help me build a side project in 4 hours that I would never have built otherwise. Essentially, it's a morphing wavetable oscillator in React (https://waves.tashian.com).

Six months ago, I tried building this app with ChatGPT and got nowhere fast.

Building it with Claude required a gluing together a few things that I didn't know much about: JavaScript audio processing, drawing on a JavaScript canvas, an algorithm for bilinear interpolation.

I don't write JavaScript often. But I know how to program and I understand what I'm looking at. The project came together easily and the creative momentum of it felt great to me. The most amazing moment was when I reported a bug—I told Claude that the audio was stuttering whenever I moved the controls—and it figured out that we needed to use an AudioWorklet thread instead of trying to play the audio directly from the React component. I had never even heard of AudioWorklet. Claude refactored my code to use the AudioWorklet, and the stutter disappeared.

I wouldn't have built this without Claude, because I didn't need it to exist that badly. Claude reduced the creative inertia just enough for me to get it done.

Good point.

Primarily, the YubiKey is there to lock away the private key while making it available to the running CA. Certificate signing happens inside the YubiKey, and the CA private key is not exportable.

This uses the YubiKey PIV application, not FIDO.

As an aside, step-ca supports several approaches for key protection, but the YubiKey is relatively inexpensive.

Another fun approach is to use systemd-creds to help encrypt the CA's private key password inside a TPM 2.0 module and tie it to PCR values, similar to what LUKS or BitLocker can do for auto disk unlocking based on system integrity. The Raspberry Pi doesn't have TPM 2.0 but there are HATs available.

It's true, the defaults are quite strict.

As for the "hours" max interval, this is the result of a design decision in Go's time duration library, dealing with the quirks of our calendaring system.

I love this idea!

Hi, I'm the author of the post. Thanks for your questions here.

-Complete overkill requiring the use of a YubiKey for key storage and external RNG source - what problems does this solve? For a Yubikey to act as a poor man's HSM you have to store the PIN in plaintext on the disk. So if the device is compromised, they can just issue their own certs. If it's to protect against physical theft of the keys, they'll just put the entire Raspberry Pi in their pocket.

Yep, it's overkill. Homelabs are learning environments. People want tutorials when trying new things. It's a poor man's HSM because not many people will buy an HSM for their homelab, but almost everyone already has a YubiKey they can play with.

The project solves the problem of people wanting to learn and play with new technology.

And it's a way to kickstart a decently solid local PKI, if that's something you're interested in.

The RNG is completely unnecessary flair that just adds to the fun.

-Creates a two-tier PKI... on the same device. This completely defeats the purpose so you can't revoke anything in case of key compromise. -They're generating the private key on disk then importing into the YubiKey. Which defeats having an external key storage device because you have left traces of the key on disk.

The tutorial shows how to generate and store the private key offline on a USB stick, not on the device or the YubiKey. The key material never touches the disk of the Raspberry Pi.

Why store a copy of the CA keys offline? Because YubiKeys don't have the key-wrapped backup and restore feature of HSMs. So, if the YubiKey ever fails, you need a way to restore your CA. Storing the root on a USB stick is the backup. Put the USB stick in a safe.

If you want active revocation, you can set it up so that the intermediate is revocable—in case physical theft of the key is important to you. (We have instructions to do that in our docs.)

-All this digital duct taping the windows and doors yet the article instructs you to download and run random binaries off GitHub with no verification whatsoever.

It's open source software downloaded from GitHub. The only non-smallstep code is the RNG driver (GitHub is the distribution point for that project). Was there a kind of verification that you expected to see?

-Why do you need ACME in a homelab and can't just hand issue long lived certificates? -OpenSC and the crypto libraries are notoriously difficult to set up and working properly. A tiny CA this is not.

Most people don't need ACME in their homelab, they just want to learn stuff. That said, we have homelabbers in our community issuing certs to dozens of endpoints in their homelab.

Whether you issue long-lived or short-lived certs is a philosophical issue. If a short-lived cert is compromised, it's simply less valuable to the attacker. Short-lived certs encourage automation. Long-lived certs can be easier to manage and you can just manually renew them. But unplanned expiry of long-lived certs has caused a lot of multi-million dollar outages.

I hope this helps clarify things.

How should a company figure out what to charge for something in the first place? Especially a startup that doesn't have much market data to go on, and may be making something entirely new that no one quite knows the value of. When this is the case, one option is to do price discovery. And the way to do that is to remove prices from the website, take calls, learn about customers and their needs, and experiment.

AI agents run in isolated VMs, but PDFs have been out here running in the open for 30 years!

Reminds me of the Hamming distance texture: https://chalkdustmagazine.com/features/the-hidden-harmonies-...

I learned C by running a MUD — a DikuMUD derivative. I was in high school, in the 90s, and I didn't know any programmers in my town who could teach me how to really code. My high school computer science teacher didn't know.

What I loved about the MUD as a learning environment was the players. On a busy night we'd have over a hundred people playing. So, I got to cut my teeth on a real, live production system with actual users. That motivated me. There were mild consequences if I broke things. And, if I made things better for the players, it felt good.

For me, this environment was so much better than doing programming problem sets by myself, writing code that no one would ever use.

https://tashian.com/articles/how-i-learned-to-program/

I tried learning to make sourdough bread by reading the Tartine Bread book.

The problem is, baking bread is such a sensual activity.

You need to understand what it feels like when the texture of the dough is right. You need to learn how to fold and stretch the dough and shape it in ways that are very difficult to describe. None of this translates well into English, no matter how good of a writer you are. And photos are of limited utility.

Learning in person from a knowledgeable teacher is ideal. Just as with a board game.

But, since we are talking about media here, what helped me the most with bread baking was Instagram. I watched videos of bakers doing each stage of the process and talking me through it. I saw the texture of the dough they were using, and how they worked it.

I learned by example.

And I wonder if board games are similar to bread.

Would I rather read a 70-page rule book, or watch someone play the game for a while or teach it to me in a video?

I'd prefer the video content, and then I'd want rulebook as a reference guide rather than a tutorial.

Hi, I'm one of the authors of CLI Guidelines.

See my post https://smallstep.com/blog/command-line-secrets/ for a bit more of a deep dive about using secrets on the command line.

Credential files are a good, simple, portable option. Files have permissions already. They don't depend on an external service or a proprietary API.

And, if your program accepts a credential file, it will be compatible with systemd credentials. systemd credentials offer more security than an unencrypted credential file. They are encrypted and can be TPM-bound, but they don't require the software using the credential to have native TPM support.

Cruise certainly knows.

I ran one in the 90s for a couple years. I was 15. I had two lines at 16.8kbps. 100 megabyte HD, which was enough to hold a giant archive of Amiga downloads. It was fun, lots of local folks on there and we'd meet up in person sometimes too. Felt like I knew everyone in town who was into computers as much as I was. Especially the Amiga people.

Not every day, but I appreciate the global tech perspective of https://restofworld.org

https://tashian.com

I write about various tech topics. Writing is thinking. It helps me learn.

I loved this podcast episode on the same topic: https://www.reboot.io/episode/wisdom-for-work-13-accountabil...

Ah, this was a grammar error on my part. Sorry about that, let me clarify.

TPMs do offer up their endorsement key (or an endorsement key certificate) to third parties.

And, TPMs can share attestations in a way that doesn't reveal the endorsement key. They use attestation keys for this. Attestation keys can sign TPM attestations, and these keys do not identify the TPM.

This approach requires a trusted CA. The CA confirms the TPM's identity (using an endorsement certificate issued by the TPM vendor), it confirms that the attestation key and endorsement key reside on the same TPM, and it issues a certificate for an attestation key.

The attestation certificate might contain TPM vendor info, firmware version number, and proof that the attestation private key is hardware-bound. But it need not contain any permanent identifier. The TPM can now use its attestation key and certificate to sign attestations for a third party.

I agree with the sentiment of the piece, but I disagree with the idea that TPMs don't add much value for end users.

TPMs were originally designed in the early days of ecommerce, when it became clear that home computers would need better security if they were going to be used for financial transactions.

Today's TPMs don't have a lot of compute power, but they have a lot of features. It's just that we don't have that much software taking the best advantage of those features yet, probably because they have only just become ubiquitous in the last couple years.

TPMs lay the groundwork for unphishable credentials, using hardware-bound asymmetric keys.

TPMs add a user-friendly option for full-disk encryption, in a way that's resistant to physical attacks.

TPMs can be used to protect symmetric credentials too, instead of storing them on disk (see systemd-creds TPM2 support).

And, TPMs do have actual privacy mechanisms. End-user TPMs do not offer up their endorsement key to any third party. Attestation workflows shield third parties from the endorsement key.

I'm excited for more widespread use of TPMs in Linux especially. Lately systemd has been making some good progress here.

Philip Greenspun's blog posts about web development got me into building web applications in college and sold me on the design principles behind ArsDigita Community System (ACS), which ran on AOLServer and Oracle. When I joined Zipcar in 2001, I advocated for building our new web app on that stack. I still think it was a good fit, given our options at the time.

SSH CAs would make the challenge a lot easier. It sounds like they are using RSA keys here for the widest possible compatibility, and while OpenSSH's certificate support is not at all new, it still may be too new for this application.

It's easy to say "should have used an HSM" (or, in truth, many HSMs), but I can appreciate the technical challenges of acutually doing that at their scale. It would not be a trivial project. There's a ton of operational concerns here, including figuring out how you would go about rotating the key on all those HSMs in an emergency.

Hi! For this post I developed a smooth and secure mutual TLS workflow for authenticating to a homelab.

It combines:

- a TLS client certificate and hardware-bound private key stored on a YubiKey (using the YubiKey PIV application)

- ACME device attestation (using the new device-attest-01 ACME challenge type, added in 2022 and introduced in iOS 16)

- Recent improvements in browser support for client certificates and smart cards

The result: You can plug the YubiKey into a laptop or mobile device anywhere in the world, pop open a browser, and go directly to your homelab. Most browsers will pick up the client certificate from the YubiKey and you'll authenticate with one click.

I work at Smallstep and this project uses our open source step-ca Certificate Authority, plus a Caddy server as a reverse proxy for homelab apps.

Full disclosure: I work for Smallstep.

The recent trend toward "Zero Trust" security has come about in the wake of attacks on internal infrastructure, where having a firewall wasn't enough. There can be lots of ways into internal networks. And attacks can come from the inside. Of course, every environment is different and every threat model is different. Internal CAs are not for everyone. But, a lot of orgs have a threat model that demands authenticated encryption for internal traffic. And at that point, you may want an internal CA.

As for validity periods... as with many things, there are tradeoffs. We advocate for short-lived certs (a few minutes to a few days). Short-lived certs can greatly simplify the revocation process, in the case where an attacker steals a private key. You often don't need the complexity of CRL or OCSP, because you can just let the cert expire and tell the CA to disallow renewal.

And, if you have a policy where certs last for 7 days and is renewed every day, it forces the organization to use good hygiene around automated renewals and monitoring.

However, there are scenarios where long-lived certs make a lot of sense. For example, if the private key is hardware-bound and is non-exportable, then it makes sense to use longer validity periods. In this case, a successful attacker might be able to use the key, but they cannot steal it. So, you can get away with a longer-lived cert here. But, all certs do eventually expire and you still have to have some answer to that.

If I'm understanding correctly, I think they're referring to a case like this:

https://www.experian.com/ is the primary domain of the company.

https://www.experianidworks.com/ is a "decorated" domain for a service offered by the same company.

Anyone could register experian*.com. So, if I want to determine whether the decorated domain is actually part of Experian or not, I'd have to go to Experian's website and dig around for a link to it. What makes it even worse in this case is that Experian is an incredibly high value target.

Full disclosure: I work for Smallstep.

I love your point about being able to limit trust on hardened systems to your own CA. For servers, in many cases you don't need any CAs in the trust store, because a lot of services will only trust the roots you've explicitly configured (if you're using client authentication).

I've also noticed that Linux container distros generally ship with empty trust stores. So, a container distro can be a nice starting point for this.