Hacker News Reader

Comment by higherpurpose | Hacker News Reader

I read somewhere that SSH can be MITM'ed by a global adversary on the first visit (before it establishes the secure connection). Is that true?

View on HN

Yes. It does not have any centralized certificate system like HTTPS so unless you can manually verify the host's public key, you will not know whether your first visit is being proxied. Of course, if the first one is proxied, so may subsequent ones, and you would only get a warning if the proxy was removed or if it's key changed.

SSH supports CA-style key signing, and it also supports server fingerprint validation over DNSSEC (search for SSHFP DNS).

Unfortunately neither of these things are commonly used yet. Cloudflare is adding DNSSEC support soon, so hopefully that will change.

It's going to take a lot more than Cloudflare adding DNSSEC support to make SSHFP records viable. Every system running an SSH client will need to run its own validating resolver. If you leave validation to an upstream server you lose a significant amount of security.

Not to mention that if your adversary is the Global Adversary, DNSSEC is mostly useless.

You get shown a key fingerprint at first connection. If you verify that with a secure source you can confirm the host you are communicating with.

Actually bothering and having a secure way to verify the fingerprint are exercises left to the reader.

If you don't actually check the fingerprint of the key matches the fingerprint you were given (in some other secure way, such as walking over to the server), then yes, a first-visit MITM is possible.

Yes. SSH can be silently mitm'd on the first connection due to not having the host key cached.

On the other hand, every web browser that visits a site for the first time (unless it was pinned in the browser you downloaded) attempts HTTP before HTTPS, and is thus vulnerable to all sorts of attacks. All non-pinned HTTPS connections at any time can be mitm'd by a global adversary that generates a cert using a CA your browser trusts.

So technically SSL is much easier to catch being mitm'd, since you only need to worry about the first visit.

Yes, but only on the first visit. In comparison, TLS could be MITM'ed in each individual visit by a localized adversary as long as their location includes a CA you trust - which appears to be the case for every intelligence agency out there.

Which threat model you prefer to deal with is up to you.

It can be MITM-ed on any connection. Whether you approve the host fingerprint is, and has always been, entirely up to you.

Default configuration on all of the system's I have used (mostly Ubuntu) is that you cannot just approve it. You have to actually remove it from the known hosts table, in effect starting a new "first session". You can set it to allow override without deleting the entry though and some system may have this as the default.

Which is still irrelevant: in the default configuration the server I'm connecting to is probably not compromised, I've probably just done something to change keys or routes or names or whatever.

The problem is further back: the default configuration doesn't make it easy to avoid these problems in the first place. If I'm logged in and do something which will change SSH host keys or the like, then the default needs to provide a way for me to make that information easily available globally to other clients which might be aware of this system.

I don't even know of a client that implements this, but SSFP DNS records are the way to do this. http://www.openssh.com/txt/rfc4255.txt

A security conscious client can manually verify a host's SSHFP with a dig record. You'll also want DNSSEC in place to ensure the dns hasn't been spoofed either.

You can fix this with SSHFP records and DNSSEC.

Reply on news.ycombinator.com