It's that simple. Yes, throw out your old crappy routers and pay more for routers which are properly supported by the vendor.
... okay. I guess if a router is "properly supported", that means it doesn't have any bugs, so it will never need to be field-updated under any circumstances.
Also, if it's "properly supported", that means neither the manufacturer nor anyone in the supply chain will ever insert any kind of malware, so there's no reason to allow the code to be inspected for correctness.
Also, those 11 million VW diesel owners should have paid more for a properly supported car.
"Firmware" has multiple meanings. The thing you're talking about is indeed called "firmware", but it is a minuscule fraction of the firmware on a typical router, which is generally a linux/unix derivative and includes everything from device drivers to configuration UI. And which is usually riddled with security vulnerabilities and other flaws.
Even the minuscule bit you're talking about still needs to be inspectable and repairable, because devices always have bugs -- often already known by the time they're shipped and purchased -- and device manufacturers have (apparently) little to no economic interest in fixing them, and it's the owner of an RF device who is legally responsible for compliance. Unless you honestly expect everyone to throw their routers away and buy new ones every few months, or you simply don't care about security, performance, or FCC compliance, field updates are a necessity.
If an RF-controlling firmware component is nothing but the equivalent of a few jumper switches, then document them thoroughly. If it's functional software (which in fact it pretty-much always is), then publish it, and do so in a form so it can be recompiled to ensure that what's on the device is the same as what was published. Volkswagen has proved beyond any reasonable person's doubt that unverifiable software is not to be trusted.
(Disclosure: co-author/signatory to the FCC letter.)
Spoken like someone who wasn't around when Jon Katz was writing his "Voices From The Hellmouth" columns, after the LIttleton massacre when nerdy teens were suddenly public enemy #1. As an old-timer, this looks exactly like the sort of story I'd expect/. to link to and discuss.
No. DNSSEC keys are in stored in a vault and only brought out for signing ceremonies. As far as I can tell, bad guys will have gotten access to some potentially valuable identity information and passwords, and copies of TLD zone files; nothing related to DNSSEC.
A friend of mine was ticketed a few months ago for checking the map on her cell phone while she was stopped at a red light. Some things are just absurd.
Google has not correctly implemented DNSSEC. If you send them a normal DNS query and the response is not validly signed, they just pass the answer back to you without any indication that it's invalid. They only tell you that the answer failed to validate if you set the DO ("dnssec okay") or AD ("authentic data") bits in your query, which almost no DNS clients currently do.
If the answer is invalid, a validating name server is supposed to respond with SERVFAIL, so that even if the client doesn't know anything about DNS security, it will still be protected against spoofing. Google is claiming to provide protection against spoofing, and then they aren't providing *any protection at all*.
If you want DNSSEC protection, you're still going to have to run a validating name server yourself: either BIND 9 or Unbound. (Disclosure: I'm a BIND 9 author.) It is, nowadays, extremely easy to configure a validating name server using BIND 9; in any version since 9.8.0, a one-line named.conf will do it:
options { dnssec-validation auto; };
Run named with that configuration and "nameserver 127.0.0.1" in resolv.conf and you're good to go. Google public DNS is not ready to trust yet.
In fact, you don't need a dynamic DNS provider at all. My home router (a Netgear WNDR3700, costs about $85) is running CeroWRT, which includes BIND 9, which takes care of dynamic DNS by itself. It also does DNSSEC validation, and serves a dozen or so DNSSEC-signed domains. It's also my web server, IPv6 tunnel endpoint, shell server, and a passel of other things. Current uptime 224 days. Consumer router hardware can do a lot these days.
(Full disclosure: I'm a BIND 9 author and helped with the CeroWRT port.)
I totally recognize that this is a stupid reaction, but if service #1 costs X dollars and service #2 costs Y dollars, I want a little lagniappe if I purchase both--the bundle of services #1 and #2 should cost an amount less than X+Y.
If they'd announced that streaming was $9 and DVD's were $9 and the combination would be discounted to only $16, I would have been sad about the price increase but a lot less irked, even though it still would've been $16. At least it isn't $18, I'd think, and I'd pay up. But they made each service $8, and didn't discount the bundle at all, and so it grates on me.
Marketing fail on their part. Rationality fail on mine.
That's because the latest BIND was released specifically to patch this vulnerability. They just didn't really tell anybody about the vulnerability until after 9.7.3 was released.
That's not correct. The locking bug had already been fixed in 9.7.3b1, a month before it was found to be exploitable as a DoS. When we did find that out, we consulted with vendors and decided to continue with the releases in progress.
Those of us who are a certain age and were geeky enough to read Danny Dunn books know exactly where the CIA got this idea.
(Luckily Danny was able to destroy Professor Bullfinch's notes so the CIA wouldn't be able to replicate the much better dragonfly he'd invented, so they had to fall back on tiny, impractical gasoline engines instead.)
Sounds like its time to find a new social media website.
A friend of mine said to me a while back: "I've decided I'm going to skip Facebook, and then skip the thing that comes after Facebook, and join the one that comes after that."
Actually, the Falcon 9, unlike most reusable boosters, was designed in advance to carry humans. It meets all of NASA's requirements for a human-rated vehicle except for an escape system. SpaceX has stated their intention to dot that final i within a couple of years. The Dragon spacecraft they're designing for the Falcon 9 will support a crew of 7.
DNSSEC and DNSCurve solve two different (though overlapping) problems. DNSSEC is about end-to-end authentication and validation: It strives to ensure that the data you received is the data the actual owner of a name server intended to send, unaltered by anyone along the way. DNSCurve is about ensuring a trustworthy connection between the authoritative name server and the resolver (and incidentally about encrypting queries, which is nice), but it doesn't do a thing to keep the resolver from lying to you. Man in the middle is a problem with DNS, as anyone who stays in hotels frequently can attest.
As for set-it-and-forget-it, if you use BIND 9.7 (on which, full disclosure, I was the lead engineer), it comes pretty close. If you don't roll keys, it can maintain itself forever, and you can roll ZSK's with a cron job. Rolling KSK's still requires operator intervention in most cases. (But rolling keys is optional; people with higher security needs will want to do it often, but low-value targets can get away with doing it infrequently or never.)
Thank you very much for looking at the code. If you could send critiques like that to the developer list instead of posting them to slashdot, it'd have a better chance of getting attention from the other developers.
I suppose it's their definition of "extensibility" -- a framework where everything is accessed through wrapped pimpls, so that anybody could change the implementation without changing binary compatibility with... oh, wait, it's an executable, so WTF?
Actually the bit you're looking at is libdns, which we're trying to design in such a way that it can be used by other DNS-aware applications, not just BIND. (I happen to agree with several of your other points, though, and there are places outside libdns where the pimpl thing was used and maybe shouldn't have been.)
We wrote lots of tests. (How else would we know it has bugs in it?) This is a somewhat fair criticism of BIND 9, but read the link before you assume we didn't learn any lessons from the past. The unit tests are included in the tarball and coverage results are viewable online.
Why would they even release it if their ground-up rewrite is so pathetic?
'Cause it's open source software, emphasis on "open". It won't be done for another couple of years, but you can look at the work in progress. You can even help write it if you want.
But what do you mean when you say "difficult to work with"? A code that is difficult to understand/maintain/evolve?
I sure hope not, as those are all specific design goals for the project (and they're among the failings of BIND 9 that made us want to redesign it in the first place). I meant "difficult to use" -- the user interface basically doesn't exist yet.
...is that only the one person is allowed to write sequels. The first story set in that world was written in 1940; under the copyright terms in effect at the time, it should've been in the public domain in 1996. There should be lots and lots of derivative works out there competing in the marketplace, instead of only one "authorized" one making the Asimov estate a pile of money that none of them actually earned.
Slashdot Mirror
It's that simple. Yes, throw out your old crappy routers and pay more for routers which are properly supported by the vendor.
... okay. I guess if a router is "properly supported", that means it doesn't have any bugs, so it will never need to be field-updated under any circumstances.
Also, if it's "properly supported", that means neither the manufacturer nor anyone in the supply chain will ever insert any kind of malware, so there's no reason to allow the code to be inspected for correctness.
Also, those 11 million VW diesel owners should have paid more for a properly supported car.
"Firmware" has multiple meanings. The thing you're talking about is indeed called "firmware", but it is a minuscule fraction of the firmware on a typical router, which is generally a linux/unix derivative and includes everything from device drivers to configuration UI. And which is usually riddled with security vulnerabilities and other flaws.
Even the minuscule bit you're talking about still needs to be inspectable and repairable, because devices always have bugs -- often already known by the time they're shipped and purchased -- and device manufacturers have (apparently) little to no economic interest in fixing them, and it's the owner of an RF device who is legally responsible for compliance. Unless you honestly expect everyone to throw their routers away and buy new ones every few months, or you simply don't care about security, performance, or FCC compliance, field updates are a necessity.
If an RF-controlling firmware component is nothing but the equivalent of a few jumper switches, then document them thoroughly. If it's functional software (which in fact it pretty-much always is), then publish it, and do so in a form so it can be recompiled to ensure that what's on the device is the same as what was published. Volkswagen has proved beyond any reasonable person's doubt that unverifiable software is not to be trusted.
(Disclosure: co-author/signatory to the FCC letter.)
Spoken like someone who wasn't around when Jon Katz was writing his "Voices From The Hellmouth" columns, after the LIttleton massacre when nerdy teens were suddenly public enemy #1. As an old-timer, this looks exactly like the sort of story I'd expect /. to link to and discuss.
I've been to Beijing, and I didn't look anywhere near as cool as a two-pack-a-day smoker.
All three of them.
Hey, 248 days is five dog-years.
No. DNSSEC keys are in stored in a vault and only brought out for signing ceremonies. As far as I can tell, bad guys will have gotten access to some potentially valuable identity information and passwords, and copies of TLD zone files; nothing related to DNSSEC.
A friend of mine was ticketed a few months ago for checking the map on her cell phone while she was stopped at a red light. Some things are just absurd.
This whole thread is really kind of hurting my feelings.
Google has not correctly implemented DNSSEC. If you send them a normal DNS query and the response is not validly signed, they just pass the answer back to you without any indication that it's invalid. They only tell you that the answer failed to validate if you set the DO ("dnssec okay") or AD ("authentic data") bits in your query, which almost no DNS clients currently do.
If the answer is invalid, a validating name server is supposed to respond with SERVFAIL, so that even if the client doesn't know anything about DNS security, it will still be protected against spoofing. Google is claiming to provide protection against spoofing, and then they aren't providing *any protection at all*.
If you want DNSSEC protection, you're still going to have to run a validating name server yourself: either BIND 9 or Unbound. (Disclosure: I'm a BIND 9 author.) It is, nowadays, extremely easy to configure a validating name server using BIND 9; in any version since 9.8.0, a one-line named.conf will do it:
options { dnssec-validation auto; };
Run named with that configuration and "nameserver 127.0.0.1" in resolv.conf and you're good to go. Google public DNS is not ready to trust yet.
In fact, you don't need a dynamic DNS provider at all. My home router (a Netgear WNDR3700, costs about $85) is running CeroWRT, which includes BIND 9, which takes care of dynamic DNS by itself. It also does DNSSEC validation, and serves a dozen or so DNSSEC-signed domains. It's also my web server, IPv6 tunnel endpoint, shell server, and a passel of other things. Current uptime 224 days. Consumer router hardware can do a lot these days.
(Full disclosure: I'm a BIND 9 author and helped with the CeroWRT port.)
'Cause I wouldn't have been able to resist the temptation to name it "Amazon Prime".
I totally recognize that this is a stupid reaction, but if service #1 costs X dollars and service #2 costs Y dollars, I want a little lagniappe if I purchase both--the bundle of services #1 and #2 should cost an amount less than X+Y.
If they'd announced that streaming was $9 and DVD's were $9 and the combination would be discounted to only $16, I would have been sad about the price increase but a lot less irked, even though it still would've been $16. At least it isn't $18, I'd think, and I'd pay up. But they made each service $8, and didn't discount the bundle at all, and so it grates on me.
Marketing fail on their part. Rationality fail on mine.
That's because the latest BIND was released specifically to patch this vulnerability. They just didn't really tell anybody about the vulnerability until after 9.7.3 was released.
That's not correct. The locking bug had already been fixed in 9.7.3b1, a month before it was found to be exploitable as a DoS. When we did find that out, we consulted with vendors and decided to continue with the releases in progress.
Those of us who are a certain age and were geeky enough to read Danny Dunn books know exactly where the CIA got this idea.
(Luckily Danny was able to destroy Professor Bullfinch's notes so the CIA wouldn't be able to replicate the much better dragonfly he'd invented, so they had to fall back on tiny, impractical gasoline engines instead.)
Sounds like its time to find a new social media website.
A friend of mine said to me a while back: "I've decided I'm going to skip Facebook, and then skip the thing that comes after Facebook, and join the one that comes after that."
There is much wisdom in her plan.
Whoops, I meant "nonreusable", sorry. (Though I believe they're also planning to make the Falcon recoverable and reusable eventually.)
Actually, the Falcon 9, unlike most reusable boosters, was designed in advance to carry humans. It meets all of NASA's requirements for a human-rated vehicle except for an escape system. SpaceX has stated their intention to dot that final i within a couple of years. The Dragon spacecraft they're designing for the Falcon 9 will support a crew of 7.
DNSSEC and DNSCurve solve two different (though overlapping) problems. DNSSEC is about end-to-end authentication and validation: It strives to ensure that the data you received is the data the actual owner of a name server intended to send, unaltered by anyone along the way. DNSCurve is about ensuring a trustworthy connection between the authoritative name server and the resolver (and incidentally about encrypting queries, which is nice), but it doesn't do a thing to keep the resolver from lying to you. Man in the middle is a problem with DNS, as anyone who stays in hotels frequently can attest.
As for set-it-and-forget-it, if you use BIND 9.7 (on which, full disclosure, I was the lead engineer), it comes pretty close. If you don't roll keys, it can maintain itself forever, and you can roll ZSK's with a cron job. Rolling KSK's still requires operator intervention in most cases. (But rolling keys is optional; people with higher security needs will want to do it often, but low-value targets can get away with doing it infrequently or never.)
Thank you very much for looking at the code. If you could send critiques like that to the developer list instead of posting them to slashdot, it'd have a better chance of getting attention from the other developers.
I suppose it's their definition of "extensibility" -- a framework where everything is accessed through wrapped pimpls, so that anybody could change the implementation without changing binary compatibility with... oh, wait, it's an executable, so WTF?
Actually the bit you're looking at is libdns, which we're trying to design in such a way that it can be used by other DNS-aware applications, not just BIND. (I happen to agree with several of your other points, though, and there are places outside libdns where the pimpl thing was used and maybe shouldn't have been.)
surely writing a DNS server can't be that hard?
Try it some time! It's fun! I can even refer you to an ongoing open-source project that you can contribute to, if you like! :)
To give a rough idea of scale, BIND 9 has about half a million lines of C code, and the first release took a couple of years to write.
(BIND 10, in its current minimal and unfinished state, is about 40,000 lines of C++, and 10,000 lines of python.)
Is that pronounced? Does it rhyme with sinned or blind ?
Wined and dined.
We wrote lots of tests. (How else would we know it has bugs in it?) This is a somewhat fair criticism of BIND 9, but read the link before you assume we didn't learn any lessons from the past. The unit tests are included in the tarball and coverage results are viewable online.
Why would they even release it if their ground-up rewrite is so pathetic?
'Cause it's open source software, emphasis on "open". It won't be done for another couple of years, but you can look at the work in progress. You can even help write it if you want.
But what do you mean when you say "difficult to work with"? A code that is difficult to understand/maintain/evolve?
I sure hope not, as those are all specific design goals for the project (and they're among the failings of BIND 9 that made us want to redesign it in the first place). I meant "difficult to use" -- the user interface basically doesn't exist yet.
...is that only the one person is allowed to write sequels. The first story set in that world was written in 1940; under the copyright terms in effect at the time, it should've been in the public domain in 1996. There should be lots and lots of derivative works out there competing in the marketplace, instead of only one "authorized" one making the Asimov estate a pile of money that none of them actually earned.