Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There’s no separate signing in use here except for the ssh connection, which can be trivially mitm’d in common targeted scenarios because of the lack of webpki and the lack of other preparations. SSHFP would help, but only if configured both in dns, and if the client is both configured to look for it, using secure dns, and the user understands the failure UX and doesn’t just bypass it. On DNS: DoH would help but it is only in widespread use in browsers. DoT would help but it is only in widespread use on android.

In addition to this a further scan of the code reveals it’s also using a btree index lookup for code comparison and no limitation on attempts, so it is likely that this is relatively trivial to attack with timing as well.

Trivialize mitm all you want, you say concerns of mitm are hyperbolic, I gave a practical example of a target rich environment and there are plenty more folks could come up with. SSH may have long been skirting the lack of a better host key distribution system, but this is largely a matter of luck, access and bespoke usage. These new deployments demonstrate a change on two of these factors, increasing risk substantially if this grows.



I agree there is an issue here -- btw, you would notice when eventually the server key changes.

User friendly and secure-by-default clients will leverage the domain HTTPS CA to solve this (fetching the server key using https). The downside is that it will require d/l and install




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: