6 ms·

Bruce Schneier on the recent DNS vulnerability

30 points by soundsop 18y ago

andreyf 18y ago
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 18y ago
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.
- emmett 18y ago
  What do you suggest we use instead?
  - cperciva 18y ago
    It depends on what you're doing -- and I'm not saying that there aren't places where SSL is appropriate (there certainly are). But to take a simple example: If you can securely distribute the hash of a file out-of-band, you're better off distributing the file over HTTP, and verifying its hash after it is downloaded, rather than distributing the file over HTTPS.
    - jrockway 18y ago
      Ah, great idea. Instead of using time-tested crypto, invent your own! That never goes wrong!
      - cperciva 18y ago
        Instead of using time-tested crypto, invent your own! That never goes wrong! The only cryptography I'm talking about using here is "if the file I download has the right SHA256 hash, it's the right file" -- and that's far more "time-tested" than SSL is. (And in any case, the rule against inventing ones' own cryptosystems is usually stated as "until you've shown that you can break other peoples' cryptography" -- so it doesn't apply to me.)
        jodrellblank 18y ago
        Thinking that you can design your own crypto system is the flaw. If you can say "I did X so now that doesn't apply to me", then you're back to thinking it's OK for you to do it - in that case, it's not OK for you to do it again. Yes, that leaves nobody who can invent new cryptosystems. That's fine. I guess we'll have to get some smart person who doesn't think they can invent a good crypto system to do it, and who thus spends many years of careful, skillful analysis doing the best job they can instead. Oh well. ;)
        cperciva 18y ago
        Even people who think they can invent good crypto spend years of careful, skillful analysis. :-)
- ars 18y ago
  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 18y ago
    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 18y ago
      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.
- tptacek 18y ago
  You could say the same thing about HTTP. And Telnet; you don't even have to work your way to SSH.
jsn 18y ago
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 18y ago
  The rest of what you wrote might be right, but lisp machines failed because they were impossible to create efficiently in hardware.
  - jsn 18y ago
    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 18y ago
      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.
- YuriNiyazov 18y ago
  There are a couple of problems at play here really. I don't think ALL your protocols and software need to be designed as The Right Thing, for the reasons that you already outline - time to implement, brains required, market penetration, etc. What needs to be designed as The Right Thing are protocols that implement important infrastructure for the society as a whole. Sure, SMTP and DNS are important infrastructure for everyone now, but at the time of design they were far from it, and I don't think the original RFC writers can be blamed with going the "Worse Is Better" route.
soundsop 18y ago
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 18y ago
  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 18y ago
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"?

30 points by soundsop 18y ago

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 18y ago

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.

emmett 18y ago
What do you suggest we use instead?
- cperciva 18y ago
  It depends on what you're doing -- and I'm not saying that there aren't places where SSL is appropriate (there certainly are). But to take a simple example: If you can securely distribute the hash of a file out-of-band, you're better off distributing the file over HTTP, and verifying its hash after it is downloaded, rather than distributing the file over HTTPS.
  - jrockway 18y ago
    Ah, great idea. Instead of using time-tested crypto, invent your own! That never goes wrong!
    - cperciva 18y ago
      Instead of using time-tested crypto, invent your own! That never goes wrong! The only cryptography I'm talking about using here is "if the file I download has the right SHA256 hash, it's the right file" -- and that's far more "time-tested" than SSL is. (And in any case, the rule against inventing ones' own cryptosystems is usually stated as "until you've shown that you can break other peoples' cryptography" -- so it doesn't apply to me.)
      - jodrellblank 18y ago
        Thinking that you can design your own crypto system is the flaw. If you can say "I did X so now that doesn't apply to me", then you're back to thinking it's OK for you to do it - in that case, it's not OK for you to do it again. Yes, that leaves nobody who can invent new cryptosystems. That's fine. I guess we'll have to get some smart person who doesn't think they can invent a good crypto system to do it, and who thus spends many years of careful, skillful analysis doing the best job they can instead. Oh well. ;)
        cperciva 18y ago
        Even people who think they can invent good crypto spend years of careful, skillful analysis. :-)
ars 18y ago
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 18y ago
  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 18y ago
    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.
tptacek 18y ago
You could say the same thing about HTTP. And Telnet; you don't even have to work your way to SSH.

jsn 18y ago

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 18y ago
The rest of what you wrote might be right, but lisp machines failed because they were impossible to create efficiently in hardware.
- jsn 18y ago
  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 18y ago
    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.
YuriNiyazov 18y ago
There are a couple of problems at play here really. I don't think ALL your protocols and software need to be designed as The Right Thing, for the reasons that you already outline - time to implement, brains required, market penetration, etc. What needs to be designed as The Right Thing are protocols that implement important infrastructure for the society as a whole. Sure, SMTP and DNS are important infrastructure for everyone now, but at the time of design they were far from it, and I don't think the original RFC writers can be blamed with going the "Worse Is Better" route.

soundsop 18y ago

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 18y ago
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 18y ago

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"?