3 ms·

Yes, you would need a DNSSEC-validating resolver, and no, ssh(1) can't confirm if the answer was actually validated or not. There's an "ad" (Authenticated Data

Yes, you would need a DNSSEC-validating resolver, and no, ssh(1) can't confirm if the answer was actually validated or not. There's an "ad" (Authenticated Data) flag in the DNS reply header that a resolver can set to 1 to indicate that it validated the answer, but an MITM can also just set that to 1. The client would have to do its own validation, and ssh(1) doesn't. Therefore, you can only safely use this if you use a DNSSEC-validating resolver, and you trust the resolver (e.g. you administer it yourself), and you have a trusted path between you and it (e.g. it's on your LAN).

devman0 4y ago
Trusted path could also be DoH or DoT as well, but yeah, not just 53/udp in the clear over the internet.
3np 4y ago
An example to work around this would be to run a validating resolver (for example unbound) on localhost of each host and have it forward to whatever DNS server you use today. If you're on Ubuntu, you most likely have a local resolver running already.
- dgl 4y ago
  On Ubuntu the default is to use systemd-resolved, which is actually a validating stub resolver. You just need to set DNSSEC=true (see man resolved.conf) and it will work*. *: this is the definition of "work" that also means it won't resolve anything if anything is wrong with DNSSEC validation, but if you want to be secure you need it to fail closed.
  - d110af5ccf 4y ago
    Perhaps a solution such as dnscrypt-proxy and configuring it to forward requests that match certain patterns to a validating resolver on the local network would work? Requests that didn't match could be forwarded to some other resolver that wasn't configured to validate.
  - skissane 4y ago
    There should be an option for "validate but still return invalid data, just reflect validity in the AD bit". Is there? That way most things will still work even DNSSEC is broken, and apps with higher security requirements can opt-in to "fail if invalid", by passing setting the AD bit on queries, and checking if it is still there on responses.
    - yrro 4y ago
      I believe that is DNSSEC=allow-downgrade which is also the default.
      - skissane 4y ago
        I thought “allow-downgrade” meant it would return unsigned data, but not invalidly signed data? I was talking about the latter case not the former.
        yrro 4y ago
        You could be right. I guess the documentation isn't terribly clear...
skissane 4y ago
> and no, ssh(1) can't confirm if the answer was actually validated or not. Isn’t this a gap in the API? res_query/etc should provide some way to find out if the response is validated or not. That would require either (1) a validating resolver running locally, or (2) a remote validating revolver, accessed over a secure protocol (such as DoT or DoH), which the system administrator has elected to trust. But the system should be able to tell applications, via some API, whether (1) or (2) hold or not
- dgl 4y ago
  This is [was; the quote in the parent was edited] incorrect, the response includes `header.ad`, which on Linux is controlled by both what the resolver responds with and `option trust-ad` in /etc/resolv.conf, so the administrator can choose if they trust their resolver via "trust-ad".
  - skissane 4y ago
    Thanks for clarifying, that makes more sense. I was just going by what the person I was replying to was saying. The man pages on my Linux box are too old to mention the trust-ad option, although newer Linux man pages do. glibc defines a RES_TRUSTAD bit which is equivalent, so applications can choose to request and trust the AD bit even if resolv.conf isn't configured to do so. However, that doesn't appear to be documented anywhere other than the header file and the NEWS file in the glibc distribution. Both RES_TRUSTAD and trust-ad were added in glibc 2.31 (released Feb 2020).
  - aaronmdjones 4y ago
    Yes, I mentioned the AD header. However, I stand by my statement that ssh(1) cannot confirm whether the answer was actually validated because an MITM could have set that flag. EDIT: I meant for this to be a reply to my sibling comment.
    - skissane 4y ago
      If ssh is using the GNU C Library’s resolv functions, and it isn’t setting RES_TRUSTAD, then glibc will automatically clear the AD bit unless the sysadmin has configured the trustad option in resolv.conf. A competent sysadmin would only do that in cases where MITM is impossible - either a local validating resolver, or DoT/DoH to a remote validating resolver. It is true that ssh has to trust the sysadmin to be competent and not enable that option in cases where MITM is possible, but I think that’s a general assumption for security that the sysadmin is doing the right thing, otherwise there are numerous other possible insecure configurations which might break ssh’s security. To double foolproof it, ssh_config could come with its own trustad setting independent of resolv.conf, so you’d have to set both.

devman0 4y ago

Trusted path could also be DoH or DoT as well, but yeah, not just 53/udp in the clear over the internet.

3np 4y ago

An example to work around this would be to run a validating resolver (for example unbound) on localhost of each host and have it forward to whatever DNS server you use today. If you're on Ubuntu, you most likely have a local resolver running already.

dgl 4y ago
On Ubuntu the default is to use systemd-resolved, which is actually a validating stub resolver. You just need to set DNSSEC=true (see man resolved.conf) and it will work*. *: this is the definition of "work" that also means it won't resolve anything if anything is wrong with DNSSEC validation, but if you want to be secure you need it to fail closed.
- d110af5ccf 4y ago
  Perhaps a solution such as dnscrypt-proxy and configuring it to forward requests that match certain patterns to a validating resolver on the local network would work? Requests that didn't match could be forwarded to some other resolver that wasn't configured to validate.
- skissane 4y ago
  There should be an option for "validate but still return invalid data, just reflect validity in the AD bit". Is there? That way most things will still work even DNSSEC is broken, and apps with higher security requirements can opt-in to "fail if invalid", by passing setting the AD bit on queries, and checking if it is still there on responses.
  - yrro 4y ago
    I believe that is DNSSEC=allow-downgrade which is also the default.
    - skissane 4y ago
      I thought “allow-downgrade” meant it would return unsigned data, but not invalidly signed data? I was talking about the latter case not the former.
      - yrro 4y ago
        You could be right. I guess the documentation isn't terribly clear...

skissane 4y ago

> and no, ssh(1) can't confirm if the answer was actually validated or not. Isn’t this a gap in the API? res_query/etc should provide some way to find out if the response is validated or not. That would require either (1) a validating resolver running locally, or (2) a remote validating revolver, accessed over a secure protocol (such as DoT or DoH), which the system administrator has elected to trust. But the system should be able to tell applications, via some API, whether (1) or (2) hold or not

dgl 4y ago
This is [was; the quote in the parent was edited] incorrect, the response includes `header.ad`, which on Linux is controlled by both what the resolver responds with and `option trust-ad` in /etc/resolv.conf, so the administrator can choose if they trust their resolver via "trust-ad".
- skissane 4y ago
  Thanks for clarifying, that makes more sense. I was just going by what the person I was replying to was saying. The man pages on my Linux box are too old to mention the trust-ad option, although newer Linux man pages do. glibc defines a RES_TRUSTAD bit which is equivalent, so applications can choose to request and trust the AD bit even if resolv.conf isn't configured to do so. However, that doesn't appear to be documented anywhere other than the header file and the NEWS file in the glibc distribution. Both RES_TRUSTAD and trust-ad were added in glibc 2.31 (released Feb 2020).
- aaronmdjones 4y ago
  Yes, I mentioned the AD header. However, I stand by my statement that ssh(1) cannot confirm whether the answer was actually validated because an MITM could have set that flag. EDIT: I meant for this to be a reply to my sibling comment.
  - skissane 4y ago
    If ssh is using the GNU C Library’s resolv functions, and it isn’t setting RES_TRUSTAD, then glibc will automatically clear the AD bit unless the sysadmin has configured the trustad option in resolv.conf. A competent sysadmin would only do that in cases where MITM is impossible - either a local validating resolver, or DoT/DoH to a remote validating resolver. It is true that ssh has to trust the sysadmin to be competent and not enable that option in cases where MITM is possible, but I think that’s a general assumption for security that the sysadmin is doing the right thing, otherwise there are numerous other possible insecure configurations which might break ssh’s security. To double foolproof it, ssh_config could come with its own trustad setting independent of resolv.conf, so you’d have to set both.