[mystraline]

And thats a huge downside when people howl about "Encryption everywhere! ".

Try debugging that shit. Thats right, debugging interfaces aren't safe, by some wellakshually security goon.

You want a real fun one to debug, is a SAML login to a webapp, with internal Oauth passthrough between multiple servers. Sure, I can decrypt client-server stuff with tools, but server-server is damn near impossible. The tools that work break SSL, and invalidate validation of the ssl.

Yes, Esri products suck. Bad.

[reincarnate0x14]

I used to share that opinion but after decades in industrial automation I find myself coming down much more on the "yeah, encryption everywhere" because while many vendors do not provide good tools for debugging, that's really the problem, and we've been covering for them by being able to snoop the traffic.

Having to MITM a connection to snoop it is annoying, but the alternative appears to be still using unencrypted protocols from the 1970s within the limitations of a 6502 to operate life-safety equipment.

[TeMPOraL]

Problem is, security people don't want you to MITM connections, because it's insecure (mostly to business interests). Hence stuff like certificate pinning, HSTS, DoH...

[reincarnate0x14]

If you're debugging your own equipment you should have the certificates or keys to make it work. I'm not saying that's easy in a lot of scenarios, in fact it's frequently tedious as hell. But for example there are debug tools for like DNP3 or RPC over TLS, etc that can watch the whole exchange if provided the keys and parse the SCADA traffic or JSON objects as if it was plaintext.

But this goes back to the vendors not providing better tools in the first place. We shouldn't NEED to be picking apart packet streams to prove to some jackass tech support ticket that their code is FUBAR. They're basically outsourcing support to their customer or userbase and we tolerated it because it was more expedient.

[Nauxuron]

This really does not need to be that hard. For TLS, many tools support setting the SSLKEYLOGFILE environment variable to log the session keys used in connections. Wireshark can import those to decrypt everything. [1]

Unfortunately, nothing exists for SSH (yet?). [2]

I do agree that if you design a protocol that enforces encryption, you should include some debugging interface. It is much more straightforward to do this by logging the session secrets on the endpoints rather than trying to break it through a man-in-the-middle, the main thing the protocol is protecting you against.

[1]: https://wiki.wireshark.org/TLS

[2]: https://gitlab.com/wireshark/wireshark/-/issues/16054

[supern0va]

It seems like a leap to suggest we shouldn't have widely deployed encryption...rather than just fix the debugging tools.

Particularly in today's political climate, encryption has only become more necessary.

[jabwd]

Sounds like blaming a tool on a problem it did not cause. Either way, solvable and encryption is important. Badly designed systems and or lack of tooling isn't really an encryption problem.

Anyway, VMs should not have authentication, it makes access sooo much easier. Also drop your IPs while you're at it. Might be useful for debugging later.