From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: Openssh-4 has a new feature that allows verifying ssh fingerprints from DNS(SEC). This function can be enabled by setting VerifyHostKeyDNS to yes in the client configuration (/etc/ssh/ssh_client). this will produce: $ host -t sshfp tla.openswan.org tla.openswan.org has SSHFP record 1 1 023B462A48078FEDE5328D9BD9E7F1896CEF75A7 tla.openswan.org has SSHFP record 2 1 176851637907BFFD41D7E161A06D8F2EE14EF35D $ ssh tla.openswan.org The authenticity of host 'tla.openswan.org (193.110.157.130)' can't be established. RSA key fingerprint is 3d:d1:34:ac:f6:ac:8f:eb:ca:1e:e7:02:8c:10:26:53. Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)? yes Version-Release number of selected component (if applicable): openssh-4.2p1-fc4.1 How reproducible: Always Steps to Reproduce: It is a feature request. It should not impact any situation, since if the key is also in the known_hosts file, the DNS lookup is not used. Additional info:
This is definitely not something I'd like to enable by default. Sorry.
Can you please explain why. As I explained: This option does NOT blindly accept fingerprints from DNS. It only gives you an EXTRA line of information about the fingerprint, that is whether or not it exists in DNS and whether it matches. Thus if a MITM attack is happening and you are connecting to a new site, the results will be MORE warnings about the attack. I assume that soon it will also provide DNSSEC hooks for extra verification, now that DNSSEC has been adopted as RFC, and the first two toplevel domains (.se and the RIPE reverse zone) have been secured by DNSSEC and are fully in production now. I have no idea what the possible negative impact could be for disabling this. Could you describe a scenario where enabling this feature would lessen the security of the ssh client?
It at least means that there is one more dns lookup done. And I'd like to keep as close as possible to upstream defaults. You can change your configuration yourself. There is no need to force that on everyone.
Okay. if extra security is not worth a DNS lookup, then I guess I have no more arguments left to argue why to enable it. No wonder endusers don't use strong security and encryption tools. We don't make it easy and transparent for them though :( Guess you can close off this bug and I'll wait for openssh to change their default.
You don't even have to only wait. You can open a bug report in http://bugzilla.mindrot.org/ - openssh upstream bugzilla.
Obviously getting upstream to turn this on by default is the Right Answer, but since it has been over a year and that hasn't happened, perhaps we should reconsider enabling it in our default config?
> This option does NOT blindly accept fingerprints from DNS. This is true only if VerifyHostKeyDNS is "ask". If it is "yes", as you requested, and DNSSEC is used, the DNS admin can capture user's passwords when logging in to a host for the first time. In general, the "Matching host key fingerprint found in DNS." message may provide false sense of security because the host administrator and DNS administrator are often not the same person - especially if DNS is spoofed. > Obviously getting upstream to turn this on by default is the Right Answer, but > since it has been over a year and that hasn't happened Was it ever requested upstream? I can't find anything on bugzilla.mindrot.org.
> This is true only if VerifyHostKeyDNS is "ask". If it is "yes", as you > requested, and DNSSEC is used, the DNS admin can capture user's passwords when > logging in to a host for the first time. That is incorrect. Please test this yourself with a host like 'tla.openswan.org'. If you login to a host for the first time, you are presented with the prompt as above: [paul@bofh ~]$ grep Verify /etc/ssh/ssh_config VerifyHostKeyDNS yes [paul@bofh ~]$ grep Verify ~/.ssh/config [paul@bofh ~]$ ssh tla.openswan.org The authenticity of host 'tla.openswan.org (193.110.157.130)' can't be established. RSA key fingerprint is 3d:d1:34:ac:f6:ac:8f:eb:ca:1e:e7:02:8c:10:26:53. Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)? yes If you have connected to this host in the past, and the DNS admin is redirecting the host, then you will get a warning that the host key changed from your copy in .ssh/known_hosts. If you have connected to this host in the past, and its a hacker that is redirecting you, you will get awrning that the jost key changed from your copy in .ssh/known_hosts AND that the dns key is wrong. If you have never connected to this host in the past, you are ALWAYS prompted, so you are no worse of then without DNS records if you choose to be.
Paul, do you have DNSSEC setup correctly? Otherwise it always asks.
AFAICS the glibc resolver doesn't support DNSSEC at all - see e.g. http://sources.redhat.com/ml/libc-alpha/2006-09/msg00006.html .
the ssh client is not aware of DNSSEC, so whether the resolver used is DNSSEC aware is irrelevant for the "problem" of prompting for new host connects, which as described above, is not a problem at all. With a secure resolver, applications can be protected against receiving spoofed names, even if not in a nice way. IETF is working on an API for this. Until then, applications might need to do some things themselves. This can be via BIND's lwres interface, or via libraries like libldns (ldns is a fedora package) or via plugins, such as the firefox ldns plugin. But all this discussion is really out of scope for this bug. The discussion here is "should or should we not enable VerifyHostKeyDNS". The only two arguments I've heard against it are: 1) the incorrect assumption that it would allow malicious DNS admins to steal passwords. 2) if upstream isnt doing it, we shouldn't either. 3) it takes an extra DNS packet to connect to a server 1) is wrong, and I find the reasoning of 2) rather weak. If upstream didn't believe in such a feature, it would not have the feature to begin with. 3) isn't adding that much overhead to a crypto protocol in times of delay. I thought Fedora was about using the community for testing and then creating stable RHEL's. I'd say this is a good example of a feature that's been out there for over a year, is starting to see good use, will get even better with DNSSEC, and Fedora is ideal for testing this so that when markets actually move in on DNSSEC later in the year, RHEL people know if this feature is desirable or not. Again. there is see no harm, only potential benefits.
(In reply to comment #10) > AFAICS the glibc resolver doesn't support DNSSEC at all - see e.g. > http://sources.redhat.com/ml/libc-alpha/2006-09/msg00006.html . I didn't know that. But that may change in future. So I think that putting 'ask' there is more appropriate so the behaviour doesn't change silently with a glibc upgrade. Thus it will be giving just a hint to the user - which he can accept but doesn't have to. I think we can reconsider this bug for Fedora 8 giving Fedora 7 is in feature freeze so we shouldn't be making feature changes. BTW 1) is wrong only because DNSSEC is not supported in glibc. Otherwise it would be very true.
You are saying 1) would be WORSE with DNSSEC support? First of all, DNSSEC does not have to be present in glibc. Running a caching only bind 9.3 nameserver on localhost with resolv.conf pointing to it will do fine to obtain secure dnssec protected answers without low level glibc dnssec support. Second, I have no idea how ADDING dnssec support will cause malicious DNS admins to steal passwords. As I have stated numerous times now, the ssh client will ALWAYS prompt when connecting to a brand new ssh public key to any dns name, whether or not there are sshfp records, with: The authenticity of host XXX can't be established. The only additional text displayed will be: Matching host key fingerprint found in DNS. Or a big warning if the fingerprint does NOT match. Please describe the attack you are seeing, so I can try to reproduce it, and file a bug against openssh-client if I can reproduce it.
(In reply to comment #13) > You are saying 1) would be WORSE with DNSSEC support? > > First of all, DNSSEC does not have to be present in glibc. Running a caching > only bind 9.3 nameserver on localhost with resolv.conf pointing to it will do > fine to obtain secure dnssec protected answers without low level glibc dnssec > support. > > Second, I have no idea how ADDING dnssec support will cause malicious DNS admins > to steal passwords. As I have stated numerous times now, the ssh client will > ALWAYS prompt when connecting to a brand new ssh public key to any dns name, > whether or not there are sshfp records, with: > > The authenticity of host XXX can't be established. > > The only additional text displayed will be: > > Matching host key fingerprint found in DNS. > > Or a big warning if the fingerprint does NOT match. > > Please describe the attack you are seeing, so I can try to reproduce it, and > file a bug against openssh-client if I can reproduce it. If VerifyHostKeyDNS is yes and the glibc would support DNSSEC - that is set proper flags on the DNSSEC validated replies - the openssh would not ask if the reply was validated properly. Look at the source. How DNS admin could steal passwords? With DNSSEC at least for domains for which his DNS server is the authoritative server very easily. And when DNSSEC is not used - if the user doesn't verify the ssh key fingerprint manually anyway also very easily. That's my final word on it. The configuration file is there - you can easily enable this for you and it won't be overwritten on upgrades.