
Bruce Schneier on the recent DNS vulnerability - soundsop
http://www.schneier.com/blog/archives/2008/07/the_dns_vulnera.html
======
jsn
It's good old "worse is better" all over again. Of course we should design our
protocols and our software as The Right Thing. Of course, it will take much
longer to design and implement; or, worse, it might just fail because it's
hard to find all the necessary smart people (like qualified security experts
and whatnot).

Meanwhile, someone not so scrupulous just ships some ugly ad-hoc bug-ridden
80% solution _now_ , and gets 80% market penetration. That's how we get MTA
landscape dominated by sendmail, DNS landscape dominated by bind, etc, etc.
Heck, that's how we get unix boxes instead of lisp machines, and windows pcs
instead of unix boxes.

~~~
ars
The rest of what you wrote might be right, but lisp machines failed because
they were impossible to create efficiently in hardware.

~~~
jsn
Not really impossible, just much harder, much more expensive, took much
longer, etc. The usual story with The Right Thing.

And that's exactly the point i was trying to make. The Right Thing is hard,
that's why it fails. What Schneier suggests won't work.

~~~
michaelneale
Also the The Right Thing is always at a disadvantage - the other products out
there are more then aware that they are Not The Right Thing hence work harder
at marketing (if applicable) or user penetration to make up for the fact that
they are not perfect.

------
andreyf
_We need more of this, not just on the internet but in voting machines, ID
cards, transportation payment cards ... everywhere._

I'm afraid insecurity in voting machines is a feature, not a bug.

------
cperciva
_That's what a good design looks like. It's not just secure against known
attacks; it's also secure against unknown attacks._

This is why I tell people to not use SSL unless they have a reason for needing
it: there have been enough bugs in SSL stacks in the past that you don't need
a crystal ball to tell you that there will probably be others in the future.

~~~
ars
That's about the same as saying that since plenty of people know how to pick
locks don't bother locking your door.

Actually it's worse: there aren't any known ssl issues, so you're leaving your
door unlocked just in case someone learns how to pick it in the future.

~~~
cperciva
_That's about the same as saying that since plenty of people know how to pick
locks don't bother locking your door._

Did you read the second half of the sentence I wrote? You know, where I said
"unless they have a reason for needing it"?

I have a reason for locking the front door whenever I leave home, and I do so.
Putting a lock onto the back gate would be utterly pointless -- that gate is
in the middle of a fence which would be easy for anyone to climb over -- so I
don't do that.

 _Actually it's worse: there aren't any known ssl issues, so you're leaving
your door unlocked just in case someone learns how to pick it in the future._

Replace "door" with "back gate in the middle of a pointless fence", and you'd
almost be correct. But security vulnerabilities in SSL stacks are not limited
to breaking SSL; a buffer overflow could give an attacker far greater access.
A closer analogy to blindly using SSL everywhere would involve a special type
of lock which, if picked, magically unlocks everything else on the property,
including things like wall safes which are much harder to pick.

~~~
ars
Yes, I read the second half and I still didn't see how adding SSL could make
things worse.

Your magic lock example makes sense, except for the fact that your analogy is
broken: ssl doesn't actually work that way.

I suppose I could see that adding even a single line of code that you don't
need increases your risk of a hack. But that's quite extreme, in reality it's
not anywhere near that bad.

I just don't agree with your risk/reward ratio of not using ssl.

It's: possibility of a bug in ssl that allows remote access to a machine, and
is not expolitable without ssl (you have to agree that that a pretty remote
possibility), vs the known problems of not having ssl especially in a wifi
environment + the possibility someone will not understand you and not enable
it even when he should.

~~~
cperciva
_possibility of a bug in ssl that allows remote access to a machine, and is
not expolitable without ssl (you have to agree that that a pretty remote
possibility)_

I don't think that's remote at all. The version of OpenSSL on my system is
over 200 kLOC. Do you really think that it's a "pretty remote possibility"
that one of those 200k lines contains an exploitable buffer overflow?

~~~
jrockway
It's more likely that the application you're "protecting" by not using SSL has
an exploitable security bug. OpenSSL is a lot of code, but it also has a lot
of users who have uncovered subtle-yet-horrible security problems in the past.
So it is somewhat trustworthy.

Your app has only been seen by you and perhaps a small team. My money says
that if someone breaks your system, it's going to be through that vector, not
the SSL stack.

~~~
cperciva
_OpenSSL is a lot of code, but it also has a lot of users who have uncovered
subtle-yet-horrible security problems in the past. So it is somewhat
trustworthy._

OpenSSL has a lot of users. But many eyes only makes bugs shallow if the eyes
are open -- and 99.999% of people who use OpenSSL have never looked at the
code.

One of the dirty secrets of open source is that there are a lot of projects
which almost everybody uses by very few people actually develop.

 _Your app has only been seen by you and perhaps a small team. My money says
that if someone breaks your system, it's going to be through that vector, not
the SSL stack._

Even if you believe that OpenSSL has had lots of people looking at the code,
which is more likely to have bugs -- 20k LOC or 200k LOC?

~~~
thwarted
The claim that many eyes makes bugs shallow is based on the number of eyes
looking at the code, not the users.

It's not a dirty secret that there are relatively few developers for an open
source project vs the number of users. This is well known, and documented in
CREDITS and Changelog files. The "low" number of people working on open source
is often trotted out during a FUD campaign, as if to imply that large software
companies have millions of "experts" looking at and developing the code.

Give me a handful of guys who _publicly_ worked on a set of code and know it
inside and out any day, over a hundred thousand developers who hide behind
some corporate name and spin department and who only ever touched one part of
it.

The chance of code having bugs is more likely directly correlated to the
complexity of the code, not its size. The change of finding the bugs in the
code to fix them (not finding that they exist) is more likely directly
correlated to the amount of code.

------
soundsop
_The real lesson is that the patch treadmill doesn't work, and it hasn't for
years._

I haven't yet heard of any major fallout from this DNS vulnerability, so it
may be going too far to say that patching doesn't work. Maybe other methods
work better, but I don't know if the current method is as broken as Schneier
says.

~~~
cconstantine
Patching has some serious flaws. The main problem is that the vast majority of
people don't apply their patches, even when applications auto-check for
updates. When a patch is released, that patch directs the bad guys to exactly
where the security flaw is.

------
jodrellblank
This is (another) reason why Biometric ID cards are not a good idea.

As a government official who wants to roll out ID cards, would you rather one
that's available now, or one that's going to be out in 3-5 years and be more
expensive, but which the vendor alleges will be an unquantifiable amount "more
secure"?

