The author lists all the advantes of CA certificates, yet doesn't list the disadvantages. OTOH, all the many steps required to set it up make the disadvantages rather obvious. Also, I've never had a security issue due to TOFU, have you?
[flagged]
SSH certificates: the better SSH experience
61–70 of 137 posts
Re: SSH certificates: the better SSH experience
#62I work in a corporate setting and the money and time we wasted because of Zscaler and its SSL inspection [1] is beyond your wildest imagination. Whenever I see a "SSL certificate problem: self-signed certificate in certificate chain" error, I know I'm in trouble. [1] https://www.zscaler.com/resources/security-terms-glossary/wh...
Zscaler was deployed on a Windows 11 machine at a place that a friend worked at. When I assessed the software, its behavior was downright evil like malware. As we all know, it injects its own root certificate into the operating system in order to conduct man-in-the-middle attacks on TLS/HTTPS connections to monitor the user's web activity.
Furthermore, it locks down the web browser's settings so that you cannot use a proxy server to bypass Zscaler's MITM. I saw this behavior in Mozilla Firefox, where the proxy option is set to "No proxy" and all other options are disabled and grayed out; I imagine that it does the same to Google Chrome. If you try to modify the browser's .ini(?) file for proxy settings, Zscaler immediately overwrites it against your will. Zscaler worked very hard to enforce its settings in order to spy on the computer user.
And as you'd expect, if you open up the Zscaler GUI in the system tray, you are presented with the option to disable the software if you have the IT password. Which of course, you don't have. Then again, that might be an epsilon better than the Cybereason antivirus software, which just has a system tray icon with no exit option, and cannot be killed in Task Manager even if you are a local administrator, and imposes a heavy slowdown if you're open hundreds of small text files per second.
Re: SSH certificates: the better SSH experience
#63I work in a corporate setting and the money and time we wasted because of Zscaler and its SSL inspection [1] is beyond your wildest imagination. Whenever I see a "SSL certificate problem: self-signed certificate in certificate chain" error, I know I'm in trouble. [1] https://www.zscaler.com/resources/security-terms-glossary/wh...
I feel the same way about Cisco Umbrella where I work.
The worst breakage by far is protocol breakage; basically anything that uses HTTP as a basis for building some other protocol gets broken all the time. None of the people implementing it seem aware. They buy the vendor's claim that it's "transparent", when in fact even "inspect/trace-only" modes often break all kinds of shit.
I've seen Umbrella break:
- Git
- RubyGems
- `go mod`
- OrbStack
- Matrix
- Cargo
- all JDKs
- Nix
- Pkgsrc
- all VMs
Often it takes hours to even fully diagnose the breakage with enough confidence to point the finger at that tool and not some other endpoint security tool.
I'm not sure if the people buying and deploying tools in this category don't know how much stuff it breaks or just don't care. But the breakage is everywhere and nobody seems prepared for it.
Re: SSH certificates: the better SSH experience
#64Life is easier if you can use Kerberos SSO, i.e. GSSAPIAuthentication in OpenSSH. (If we're talking certificates, presumably it is OpenSSH, or does anything else implement them?)
Re: SSH certificates: the better SSH experience
#65One constant source of amazement for me is people not using ssh keys / using passwords with ssh.
Especially at a BigCo, where there are different environments, with different passwords, and password expiry/rotation/complexity rules.
Like, when asking for help, or working together... you say to them "ok, lets ssh to devfoo1234", and they do it, and then type in their password, and maybe get it wrong, then need to reset it, or whatever... and it takes half a minute or more for them to just ssh to some host. Maybe there are several hosts involved, and it all multiplies out.
I mention to them "you know... i never use ssh passwords, i don't actually know my devfoo1234 password... maybe you should google for ssh-keygen, set it up, let me know if you have any problems?" and they're like "oh yeah, thats cool. i should do that sometime later!".... and then they never do, and they are forever messing with passwords.
I just don't get it.
Re: SSH certificates: the better SSH experience
#66I work in a corporate setting and the money and time we wasted because of Zscaler and its SSL inspection [1] is beyond your wildest imagination. Whenever I see a "SSL certificate problem: self-signed certificate in certificate chain" error, I know I'm in trouble. [1] https://www.zscaler.com/resources/security-terms-glossary/wh...
SSH certificates aren't X.509 certificates.
Re: SSH certificates: the better SSH experience
#67Earlier quoted context omitted.
I've known SSH certs for a while but never went through the effort of migrating away from keys. I'm very frustrated about manually managing my SSH keys across my different servers and devices though. I assume you gathered a lot of thoughts over these 15 years. Should I invest in making the switch?
I am keeping an eye on the new (and alpha) Authentik agent which will allow idp based ssh logins. There's also SSSD already supported but it requires glibc (due to needing NSS) meaning it's not available on Alpine.
If you mean using OIDC, in that space there's at least https://github.com/EOSC-synergy/ssh-oidc, https://dianagudu.github.io/mccli/ and OpenPubkey-ssh discussed in https://news.ycombinator.com/item?id=43470906 (which might mention more).
How does SSSD support help with SSH authN? I know you can now get Kerberos tickets from FreeIPA using OIDC(?), but I forget if SSSD is involved.
Re: SSH certificates: the better SSH experience
#68Life is easier if you can use Kerberos SSO, i.e. GSSAPIAuthentication in OpenSSH. (If we're talking certificates, presumably it is OpenSSH, or does anything else implement them?)
Why would you do that rather than just hooking SSH up to a real IdP with certificates?
Re: SSH certificates: the better SSH experience
#69This discussion is full of schizo solutions to "secure" SSH, most of which make no practical sense or have no technical basis. There really needs to be a definitive best practices guide published by a trusted authority.
In my view it is more important to stop using software keys so probably use sk (fido) for both host and user.. From there CAs would be a next step.. The level of documentation and example setups is astoundingly poor if you even look at step 2 for any feature. I.e. SK keys are reasonably understood for user keys but the setup as host keys is vague and needs testing to see if it really works.
Re: SSH certificates: the better SSH experience
#70Earlier quoted context omitted.
That works for authn in the happy path: short-lived cert, grab it, connect, done. Except for everything around that: * user lifecycle (create/remove/rename accounts) * authz (who gets sudo, what groups, per-host differences) * cleanup (what happens when someone leaves) * visibility (what state is this box actually in right now?) SSH certs don’t really touch any of that. They answer can this key log in right now, not…
Well, yes, pick your poison. But for just getting access to role accounts then I find it a lot nicer than distributing public keys around. And for everything else, a periodic Ansible :-)
Public keys (for OpenSSH) can be in DNS (VerifyHostKeyDNS) or in, say, LDAP via KnownHostsCommand and AuthorizedKeysCommand.