[vox-tech] inject false information into dns

[Rick Moen]

Quoting Bill Broadley (bill at 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).