Quoting Bill Broadley (b...@broadley.org): What you said.
> * Authoritative only servers don't cache Well, yeah, authoritative-ONLY servers would have no use for caching by definition, as they aren't accepting data from elsewhere. DNSSEC is definitely quite worthwhile. I just am mostly wary of people treating it as if it were magic crypto sauce and the solution to Internet site authentication and key managment -- when attention to a few fundamentals elsewhere gets you a lot further. > * DNS based Amplification attacks are a major issue these days A lot of this results directly from the widespread reliance on open recursive servers. So, Don't Do That, Then -- thus my polite disagreement with Tony on that key point. The more I've pondered this problem space, the more attractive 'split split' DNS (where authoritative and recursive service are completely decoupled) seems. http://www.ida.liu.se/~TDDC03/literature/dnscache.pdf https://www.sans.org/reading-room/whitepapers/dns/current-issues-dns-32988 If nothing else, having a highly protected recursive-only server that's as local as possible is a really good idea. I like having a localhost-only recursive server, actually, e.g., on laptops -- the last word in 'can't flood _this_ with spoofed responses'. > SSH prevents this by using public keys to exchange > a secret key, which is used for that session. However, the keypair (and passphrase) can be stolen on the usage end if that host has been compromised, and this is how public-key SSH credentials get stolen and abused all the time. Example: http://linuxmafia.com/faq/Security/breakin-without-remote-vulnerability.html The firm where this happened, which I didn't care to identify at the time, was VA Linux Systems, which was h4x0red by a kiddie in South Lake Tahoe who'd compromised a university shared computer, used that host to collect outgoing public-key SSH credentials a developer used to ssh into shell.sourceforge.net, escalated to root on that shared host and installed trojaned /usr/bin/ssh there, then last collected the public-key credentials of a VA Linux Systems IT Dept. employee (not me!) who made the error of then sshing or scping inbound into corporate servers from the shared Sourceforge host. > * DNSSEC can protect against local ISP Just to clarify: If you use the 'forwarders' keyword in BIND9 to offload traffic to the ISP recursive server, the DNSSEC capabilities of your local nameserver are going to be undermined. Even BIND10 is not yet aimining to fully validate forwarding: http://www.isc.org/blogs/dns-forwarders/ So, Tony, that's yet another reason not to keep using your forwarding scheme. > Additionally even if the government did do that, you could immediately > notice the change in signing key and if you knew me you could enquire > why such a change happened. This is key point, and bringing the 'temper-evident' quality back into HTTPS is one of my _other_ current measures, as see below: > Similar applies to SSL certificates. If you are worried about secure > communications with someone you can store their public key. While a > government can publish a new public key, they can't magically produce > the missing private key. > > So even the NSA has to be careful, faking a public key on any kinda of > wide scale is lightly to draw significant attention. Word. And one step towards making SSL tamper-evident (on the Web) is to change Web browsers' happy-go-lucky default of saying absolutely nothing about changes in SSL certs or their CA attestations as long as they continue to be attested by some CA or other that's in the browser's keyring. Those keyrings have proven to be a joke. Even the Turkish government has been able to use a captive CA to promulgate forgeries. One tool for alerting browser users to cert or attestation changes is Firefox extension CertWatch (Certificate Watch). It's not very clever; it just tells you when an SSL cert or its attestation has changed since last encounter, leaving entirely up to you how to interpret that change and what to do about it. That is not a comprehensive solution, but I find knowing about the fact of a change a great deal better than not knowing. For my own self-signed Web site SSL cert, I carry around its hash value in my PDA for comparison, same as with my SSH host and personal keys. > Sadly certificate authorities are anything but trustworthy. So I prefer > the ssh model. There are some projects to build an alternative to the laughably broken CA attestation scheme. http://web.monkeysphere.info/ http://convergence.io/ > * Pick good passwords, never use them for more than one site/service, > preferably generated by a machine. I susggest an open source password > database like keepass (It works on windows, linux, android, and IOS). I consider an online password safe program suboptimal because it is exposed to attack and compromise if your machine is -- albeit it's hugely better than no password safe at all. My own chosen alternative is a completely offline password safe program called Keyring for PalmOS (http://gnukeyring.sourceforge.net/) that runs on my deliberately simple and detached-operating PalmOS PDA. I back up the program's 3DES database onto my various network-connected computers, but access its contents only live on the PDA itself. Thus, unless someone finds a way to compromise my PDA (unlikely given that I've disabled even its Bluetooth peering and install almost no third-party software on it), the only way attackers can grab its password is to shoulder-surf me as I use the PDA -- or crack 3DES or its software implementation. Anyway, otherwise I totally concur: Users need a password safe program of some sort because the human wetware isn't otherwise capable of remembering a sufficient diversity of sufficiently complex access credentials. So, people who don't use password safes inevitably adopt one or more dumb compromise just to get by in life. Don't be that guy. > * Do not use ssh passwords, use certificates. You mean keypairs? A private key and passphrase can be stolen, too,, just like a password. See cautionary tale about VA Linux Systems. > * Don't click on PDFs from untrusted sources, doubly so in IE. This is a risk only if your computer invokes vulnerable PDF-handling software, primarily Acroread. Friends don't let friends use Acroread (or at least expose it to files from public networks). _______________________________________________ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech