4 ms·
> instead of simply fixing the problem. No such thing when certificates are involved. You basically have two options to do it "correctly": 1) Walk a path of
by TeMPOraL 2y ago
> instead of simply fixing the problem.
No such thing when certificates are involved.
You basically have two options to do it "correctly":
1) Walk a path of broken glass and razorblades, on your naked knees, through the depths of hell, trying to get a complex set of ancient tools and policies that no one truly understands to work together. One misstep, the whole thing seizes up, and good luck debugging or fixing it across organizational boundaries.
2) Throw in the towel and expose the insides of your org, and everyone you come into contact with, on the public Internet, so you can leverage "Internet-standard" tools and practices.
One of the fundamental issues is that doing SSL properly breaks a basic engineering assumption of locality/isolation. That is, if I'm making a tool that talks to another tool (that may or may not be made by me too) directly, I should only care about the two tools and the link between them. Not the goddamn public Internet. Alas, setting SSL means either entangling your tool with the corporate universe, or replicating a facsimile of the entire world locally, just so nothing in the stack starts whining about CAs, or that self-signed certs smell like poop, or something.
Like seriously. You make a dumb internal tool for yourself, with a web interface. You figure you want to do HTTPS because browsers whine (o. Apparently the correct way of doing this is... to buy a domain and get a cert from LetsEncrypt. WTF.
The whole philosophy around certificates is not designed to facilitate development. And guess what, I too sometimes get requests to give ability for a tool to skip some checks to make product testing possible, and it turns out that the whole communication stack already has flags for exactly that, for exactly that reason.
EDIT:
Imagine an arm broke off your coat hanger. You figure you'll take a metal bracket and two screws and fix it right there. But as you try, your power drill refuses to work and flashes some error about "insecure environment". You go on-line, and everyone tells you you need to go to the city council and register the drill and the coat hanger on a free Let's Construct build permit.
This is how dealing with SSL "correctly" feels.
- arccy 2y agothe network is never secure, that's why there's all this stuff going on about "zero trust"
- ninkendo 2y agoPlease explain to me about how the “network” between my browser and my kubernetes dev installation on the same computer is insecure.
- TeMPOraL 2y agoNothing in life is ever secure. "All this stuff going on about ''zero trust''" is a broad and diverse mix of good practices, hot air, fear, misconceptions about reality, and power seeking. I'd dare say that in a big way, it's practical effects are, intentionally or otherwise, disenfranchising workers, screwing with their ability to do their jobs, generating huge costs and threat exposure across the board. But it's sure nice if you're a supplier in the "zero trust" market. Also, not everything is - or should be - on the Internet; there exists more than one network. Different systems have different needs and risk profiles. Failing to recognize that fact, and trying to apply the same most strict security standards to everything doesn't lead to more security - it leads to people caring less, and getting creative with workarounds.
- im3w1l 2y agoRegarding your example, it really does seem like the direction the world is moving.
- TeMPOraL 2y agoIt's not a coincidence. Same incentives are at play, same justifications given - except when it comes to computers, even tech people seem much less willing to question them than their equivalents in other areas of policy and enterprise.