| |||||||||||||
please move this stuff into DNSplease move this stuff into DNSPosted Dec 26, 2008 8:27 UTC (Fri) by weasel (subscriber, #6031)In reply to: please move this stuff into DNS by TRS-80 Parent article: SSL man-in-the-middle attacks I think the problem with putting the cert fingerprint into DNS is the application doesn't know if the response was secured by DNSSEC or not. Unfortunately the article you link to only states the same fact as you, and does not even try to give an explanation, reason or argument. At least ssh appears to be able to figure out if information it gets from DNS is secure or not. It does that by checking the AD bit in the dns response (see dns.c in its source and the VerifyHostKeDNS entry in the ssh_config manpage).
(Log in to post comments)
please move this stuff into DNS Posted Dec 28, 2008 23:40 UTC (Sun) by jamesh (guest, #1159) [Link]
Unless I am mistaken, that code is only testing that the DNS server OpenSSH uses thinks that the DNS record is secure. It doesn't actually do any verification itself (following the signature chain all the way back to the DNS root).
If I set up a public wifi network, I could easily provide a DNS server that said every record was secure and use DHCP options to get machines that connect to use that server. How would OpenSSH be able to tell the difference between this network and a secure network where the responses from the DNS server can be trusted?
So there seem to be real problems with applications trusting DNSSEC results given the types of networks people connect to these days ...
please move this stuff into DNS Posted Dec 30, 2008 14:40 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
You could provide such a DNS server, but you can't force me to trust it.
On a laptop I can choose to run a local DNS server, which implements DNSSEC and (as soon as the root is signed) get a complete end-to-end chain. Perhaps you don't know anybody who does this today, and perhaps in five years you won't know anybody who doesn't.
On a moderately secure wired LAN (or suitably protected wireless one) I can provide a local DNS server and sacrifice the last hop security for improved performance from the shared cache.
What's much nicer about using DNSSEC for this is then all I'm relying on is the immediately evident hierarchy, thus...
physics.soton.ac.uk relies on the root, then the UK government and its DNS operator Nominet, the JaNET (UK academic network) management & operator, and the University (of Southampton)'s management and systems team. This makes sense - it's almost the same hierarchy that issued the machine with an IP address.
Whereas with current CA-based SSL physics.soton.ac.uk may well rely on the integrity of a cheap reseller from Taiwan, who acts as a front for an outfit in California, which in fact subcontracts the technical work to a small business in Finland run by a 14 year old girl. But I can't tell any of that, all I get is a picture of a padlock.
DNSSEC can be leveraged to deliver secure-by-default to the web, something which I think would be more revolutionary than most people realise.
please move this stuff into DNS Posted Dec 31, 2008 5:37 UTC (Wed) by jamesh (guest, #1159) [Link]
I am sure that you are smart enough not to enable VerifyHostKeyDNS option in ssh for any machine that uses an untrusted DNS resolver. But surely you understand why the option is disabled by default, right?
Until we get to the point where people get a secure DNS resolver installed by default, it doesn't make sense for application developers to trust the DNS response by default. Relying on a pre-shared public key gives the application much better assurance (even if this assurance is weaker than what they'd get from a properly verified DNSSEC response).
Perhaps if an operating system installed a DNS resolver that performed the necessary checks by default, it would make sense for applications to trust the response flags. But until that point, applications are better off using some other trust mechanism.
|
|||||||||||||