3 ms·

There is a DNS SSHFP record type that the history can publish the host keys. I wrote about them some time back: https://ayesh.me/sshfp-verification https://aye

by Ayesh 8y ago

There is a DNS SSHFP record type that the history can publish the host keys. I wrote about them some time back: https://ayesh.me/sshfp-verification https://ayesh.me/sshfp-verification For servers without a domain pointed to it, I suppose you can still verify them by comparing the history key fingerprint by logging into said server with the console provided by server vendor.

gruez 8y ago
And how do you trust that the dns record hasn’t been tampered with? DNSSEC?
- xoa 8y ago
  The article mentions DNSSEC, but is that a limiting factor in this case? If you are connecting to a server you specifically have out of band access to then just use pre-shared keys like normal and none of this is relevant. If you don't and DNS is compromised then you're depending on DNS anyway right? At that point getting the host pubkey from DNS too doesn't seem like it hurts anything and it could still defend against MITM if the chain from you to DNS is different then you to the server (not uncommon I'd think, since a lot of people are either using their local resolver, using their ISP's at 1 hop, or using someone distributed like Cloudflare who are also minimal hops). Of course authentic secure DNS is really important anyway, and worth working on. Beyond DNSSEC there is also DNS over HTTPS. And just using shared keys and nothing else, no option to even accept if it changes, is best of all. But if that doesn't work for whatever reason having it in DNS doesn't seem like an awful idea, anymore then Let's Encrypt depending on DNS does right?
  - tptacek 8y ago
    Authentic secure DNS is in fact not important, and is not worth working on. I think the lengths you had to go to just now to establish some kind of marginal value for SSHFP is a good illustration of why. And that's because we've designed protocols for the past 20 years to assume the DNS is insecure. SSH, in particular, has "don't trust DNS" baked into its DNA; it's a response to the old Unix r-commands, which did trust DNS.
  - gruez 8y ago
    The threat model SSHFP protects against from is some adversary that's in the middle of you and the server (not close to you or the server). It does nothing against an evil ISP or evil AP, which FTPS (with CA signed certificates) does protect you against.

by Ayesh 8y ago

gruez 8y ago

And how do you trust that the dns record hasn’t been tampered with? DNSSEC?

xoa 8y ago
The article mentions DNSSEC, but is that a limiting factor in this case? If you are connecting to a server you specifically have out of band access to then just use pre-shared keys like normal and none of this is relevant. If you don't and DNS is compromised then you're depending on DNS anyway right? At that point getting the host pubkey from DNS too doesn't seem like it hurts anything and it could still defend against MITM if the chain from you to DNS is different then you to the server (not uncommon I'd think, since a lot of people are either using their local resolver, using their ISP's at 1 hop, or using someone distributed like Cloudflare who are also minimal hops). Of course authentic secure DNS is really important anyway, and worth working on. Beyond DNSSEC there is also DNS over HTTPS. And just using shared keys and nothing else, no option to even accept if it changes, is best of all. But if that doesn't work for whatever reason having it in DNS doesn't seem like an awful idea, anymore then Let's Encrypt depending on DNS does right?
- tptacek 8y ago
  Authentic secure DNS is in fact not important, and is not worth working on. I think the lengths you had to go to just now to establish some kind of marginal value for SSHFP is a good illustration of why. And that's because we've designed protocols for the past 20 years to assume the DNS is insecure. SSH, in particular, has "don't trust DNS" baked into its DNA; it's a response to the old Unix r-commands, which did trust DNS.
- gruez 8y ago
  The threat model SSHFP protects against from is some adversary that's in the middle of you and the server (not close to you or the server). It does nothing against an evil ISP or evil AP, which FTPS (with CA signed certificates) does protect you against.