[stouset]

> Now we have SSL (do people really expose Redis on the internet??).

This is 2020. The "hard outer shell, soft chewy center" model of security is dead and it's not coming back. Modern datacenters and cloud deployments use mTLS (mutually-authenticated TLS) between every service, everywhere, all the time.

There are some massive benefits to this. For starters, you can limit what services talk to one-another entirely through distribution and signing of keys. Yes, this adds a burden of complexity if you go that route. But suddenly you don't have to care as much about (for instance) many network-exploitable vulnerabilities in your services because someone with a foothold on your network can't even get talk to your service in the first place if they don't have the right TLS cert, which is only on the handful of machines and only readable by the specific services that are legitimately allowed to connect to it.

This is a much stronger guarantee than firewalling alone (though you should also use firewalling), because multiple services can be running on a host but only the applications that are allowed to talk to your service will have read access to that key.

On the flip side, you have stronger guarantees that the service you're connecting to really is the service you're expecting it to be. If you're storing sensitive information in Redis, you can know for sure that the port you've connected to is the right Redis and not another, less-sensitive application's.

[notyourday]

I hear this in marketing presentation or company pitches all the time.

After that I as a consultant get access to the network and apart from some test that a developer stood up nothing matches the glossy talk.

Thanks god for Wireguard. It has truly been the savior deploying encrypted networks.

[cortesoft]

But of a selection bias, don't you think? Places that do it right probably don't need to hire consultants.

[notyourday]

I used to think I was special: someone who comes in and discovers these ugly pockets of pus. The kind that with a single poke and they burst creating a very ugly problem.

In talking to other people high up on the technical side I realized it is a norm. The only question is if what I call "velocity of awesomeness of the product" makes the warts less important.

[jimmcslim]

> After that I as a consultant get access to the network and apart from some test that a developer stood up nothing matches the glossy talk.

Or in my case recently... someone has generated a root certificate for the internal CA that uses an insecure crypto scheme, and Chrome still throws up a security error requiring users to click past the warnings to access the site.

"Can you generate and roll out a new cert please? This isn't really 'security'?"

"Oh we will get to it, can you just use the one you already have?"

[Aeolun]

> "Oh we will get to it, can you just use the one you already have?"

Cue 2 years going by. Same situation, except that the certificate has been regenerated with the same insecure crypto scheme.

[kelnos]

I agree that many shops don't work this way, but they absolutely should. Anyone not developing a good defense-in-depth strategy, and just assuming that their edge firewalls will take care of them... well, they're one step away from a break-in and a data breach.

Our industry needs to do better, and not brush off good security as "glossy marketing talk".

[notyourday]

The first step towards fixing a problem is to admit that most of our "best practices" are marketing talk. We do not actually do it.

[stouset]

I'll just say I work at a large SF unicorn where we do this. We're not at 100% (getting anything to 100% when you're big enough is impossible), but the vast majority of everything is behind TLS 1.2 with unique certificates per server/app pair.

We're hoping to use SPIFFE/SPIRE to bring adoption even higher.

[notyourday]

I'm very impressed. I have only seen this in one place. It was a very old school brokerage and even they were running that over IPSEC network