3 ms·
I don't think ssh provides the same level of confidence as https, unfortunately. There are no root CAs that are agreed upon, so the users are too used to blindl
by barosl 5y ago
I don't think ssh provides the same level of confidence as https, unfortunately. There are no root CAs that are agreed upon, so the users are too used to blindly accepting whatever server keys they are given. This makes MITM attacks too easy.
- datanut 5y agoDNSSEC + SSHFP is a simple, scalable, accessible solution. Root CAs are just a bit of a bummer; I hope to be a part of the transition away from them.
- barosl 5y agoI didn't know about SSHFP, thanks for informing me. DNSSEC has always felt cumbersome to set up, so I've stayed away from it. Might give it another try.
- riedel 5y agocertificate pinning gives me more trust than letsencrypt as a root ca for most of my use cases . except for the agent forwarding protocol and that you cannot secure opensshs socks proxy i am actually quite happy with SSH given its applications . i do not like the plutocratic aspect behind the current www consensus on protocols. Having said that: thanks for using telnet. This is great fun.
- tptacek 5y agoSSH supports certificates (and they aren't X.509 certificates; they're simple and purpose-built for SSH) which resolves the MITM problem in both directions. It's what organizations who manage large numbers of servers use already (in particular, certificates make it easy to tie logins to SSO systems, and to keep people from holding on to long-lived SSH keys). They're great, and you should check them out. The very last thing in the world you should do is adopt something like SSHFP, a clangorous hack that ties your SSH service to a root of trust operated by a state actor.