HN user

mac-chaffee

480 karma
Posts2
Comments132
View on HN

That's really cool! I actually did download an archive of aol-sucks while researching this, but the software I was using to look through the mbox file was kinda buggy so I gave up. I'm literally the meme of the miner guy giving up right before hitting diamonds.

I'd generally confirm that suspicion: https://www.macchaffee.com/blog/2023/wafs/

WAFs have a few valid uses in my opinion: "virtual patching" and the ability to create custom rules such as blocking/challenging/rate limiting obviously bad traffic. But the giant rulesets are actively harmful IMO. "Defense in depth" is not a valid justification for doing something actively harmful to both your users and the time budget of your security team.

I welcome a k8s replacement! Just how there are better compilers and better databases than we had 10-20 years ago, we need better deployment methods. I just believe those better methods came from really understanding the compilers and databases that came before, rather than dismissing them out of hand.

Author here. Yes there were many times while writing this that I wanted to insert nuance, but couldn't without breaking the format too much.

I appreciate the wide range of interpretations! I don't necessarily think you should always move to k8s in those situations. I just want people to not dismiss k8s outright for being overly-complex without thinking too hard about it. "You will evolve towards analogues of those design ideas" is a good way to put it.

That's also how I interpreted the original post about compilers. The reader is stubbornly refusing to acknowledge that compilers have irreducible complexity. They think they can build something simpler, but end up rediscovering the same path that lead to the creation of compilers in the first place.

The use-case seems to be intentionally narrow:

The Secrets Manager Agent provides compatibility for legacy applications that access secrets through an existing agent or that need caching for languages not supported through other solutions.

It's especially frustrating that I firmly believe operations is a solved problem, but good luck getting a company to adopt the practices that every other mature tech company has already figured out.

Build-related fixes are only treating the symptoms, not the disease. The real fix would be better sandboxing and capability-based security[1] built into major OSes which make backdoors a lot less useful. Why does a compression library have the ability to "install an audit hook into the dynamic linker" or anything else that isn't compressing data? No amount of SBOMs, reproducible builds, code signing, or banning binaries will change the fact that one mistake anywhere in the stack has a huge blast radius.

[1] https://en.wikipedia.org/wiki/Capability-based_security

I personally consider the ArgoCD UI an anti-feature. Attaching some hulking mass of Javascript dependencies to the thing that has cluster-admin rights to my production cluster is unnecessary attack surface for me.

ArgoCD also has its own auth system and permissions. You give ArgoCD cluster-admin rights, then it uses impersonation to pretend like it has lower permissions. One little bug there and you can trick ArgoCD into escalating your permissions, which happens a lot: https://github.com/argoproj/argo-cd/security/advisories/GHSA...

While not officially supported, you can technically deploy Flux with limited permissions, but ArgoCD's dependence on impersonation means it cannot run with lower permissions.

The encryption Chrome uses isn't just some key on disk that can be scooped up. On macOS at least, it's stored in the secure enclave which only signed Chrome binaries can access.

Now all this is pointless due to Chrome allowing remote debugging, but Firefox could come along and do it right and it would actually be an increase in security. A random unsandboxed binary trying to access the key would be blocked by the kernel.

I actually wrote this post in preparation for a fight about WAFs with a SOC2 auditor, wish me luck! :)

The specific control says "Boundary protection systems (for example, firewalls, DMZs, IDS/IPS, and EDR systems) are configured, implemented, and monitored to protect external access points", which seems to leave room for doing stuff other than WAFs.

Unfortunately, differentiating good behavior from malicious behavior is a central pillar of security, and the existence of this feature undermines that pillar.

* The fact that it's in a popular signed binary means it bypasses app allow-lists.

* The fact that it flows through Microsoft's servers bypasses firewall allow-lists.

* The fact that no stage2 is required bypasses antivirus scanning.

I say "unfortunately" because I personally think attempting to differentiate good behavior from malicious behavior is losing battle. Design-based or resilience-based security controls are the way to go IMO: https://kellyshortridge.com/blog/posts/control-vs-resilience...

DevOps still must draw the line somewhere. DevOps people typically don't physically plug cables into switches, for instance. With the ever-growing complexity of infra, I see that line having to shift more and more, with either PaaS products or platform engineering teams filling the space by providing something like Kubernetes as a service to the DevOps folks.

That looks closer to the right solution, but...

Remember, your private key is your identity in Nostr, so if it is compromised you'll lose your followers and will have to start from scratch rebuilding your identity.

This is the same gripe I have with home servers on the fediverse: home servers come and go, and private keys sometimes need rotating. Making you lose all your friends and content when that happens is not an acceptable tradeoff.

I think the solution is entirely separating "identity" from every single other concern such as security (private keys), hosting (home servers), and public identity ("display name").