Oh shit, I just broke the Internet
December 1, 2008 7:43 PM Subscribe
"There is no saving the internet. There is only postponing the inevitable." Wired Magazine looks at the history of DNS and the Kaminsky attack.
Kaminsky, previously
Open DNS, previously
Kaminsky, previously
Open DNS, previously
The internet is a construct based on lots of code. Code is never bug free, its just full of bugs that haven't found yet. So the internet will never be completely safe and secure. And since its always evolving new potential internet killers are always being added...That being said its a bit doom and gloom to think that the internet is going to explode. Exploits become know, exploits get patched. It would be the same in potential replacement of the internet. You can never engineer a perfect solution, just fix your current solution until it becomes more trouble than its worth.
Build(internet){
Find(bug)
if bugTolerance=meh then
Fix(bug)
bugTolerance++
else if bugTolerance=wtf then
Build(internet2)
end if
}
posted by wavering at 8:01 PM on December 1, 2008 [5 favorites]
Build(internet){
Find(bug)
if bugTolerance=meh then
Fix(bug)
bugTolerance++
else if bugTolerance=wtf then
Build(internet2)
end if
}
posted by wavering at 8:01 PM on December 1, 2008 [5 favorites]
This seems like a pretty trivial problem that, while perhaps being a minor annoyance to fix, is nowhere near being the O NOES EVERYBODY PANIC end of the internet (obviously unless it goes unpatched). Kaminsky seems like kind of a dick for giving the peeps an ultimatum and trying to go for 1337 h4Xx0r glory .
posted by mullingitover at 8:03 PM on December 1, 2008
posted by mullingitover at 8:03 PM on December 1, 2008
That's a great Wired article. I'm sure someone will expand it into a book eventually, has all the makings for a great narrative thriller. Sort of like foiling a plot to blow up the world, with the clock ticking.
posted by stbalbach at 8:12 PM on December 1, 2008
posted by stbalbach at 8:12 PM on December 1, 2008
Kaminsky seems like kind of a dick for giving the peeps an ultimatum and trying to go for 1337 h4Xx0r glory .
Nah.. think about it, once he told someone, he knew it was only a matter of months.. weeks.. before word got out. And he was right, someone did leak it. As far as he knew, someone else already was exploiting the bug - the sooner the world knew about it the better. He did the right thing going to the majors first and then releasing it to the world. White hat.
posted by stbalbach at 8:16 PM on December 1, 2008 [11 favorites]
Nah.. think about it, once he told someone, he knew it was only a matter of months.. weeks.. before word got out. And he was right, someone did leak it. As far as he knew, someone else already was exploiting the bug - the sooner the world knew about it the better. He did the right thing going to the majors first and then releasing it to the world. White hat.
posted by stbalbach at 8:16 PM on December 1, 2008 [11 favorites]
Torrents will kill it.
Since the internet is dead, can we self-link on metafilter now?
And if the internet is dead, will this mean people will have to actually work for a living? Or at least work while at work?
posted by cjorgensen at 8:29 PM on December 1, 2008 [4 favorites]
Since the internet is dead, can we self-link on metafilter now?
And if the internet is dead, will this mean people will have to actually work for a living? Or at least work while at work?
posted by cjorgensen at 8:29 PM on December 1, 2008 [4 favorites]
mullingitover: This seems like a pretty trivial problem
Except for the whole "rerouting any internet traffic, whether it be serving you a different website or sending some random person your bank password" thing, yeah.
posted by flatluigi at 8:30 PM on December 1, 2008 [2 favorites]
Except for the whole "rerouting any internet traffic, whether it be serving you a different website or sending some random person your bank password" thing, yeah.
posted by flatluigi at 8:30 PM on December 1, 2008 [2 favorites]
The server didn't know that the Web page didn't exist—it was listening to Kaminsky now, as if it had been hypnotized.
They could really do to lose the crap analogies. Hey! Wired people! We're reading an article about DNS. You don't need to anthropomorphise the servers*.
*They really hate that.
posted by pompomtom at 8:30 PM on December 1, 2008 [31 favorites]
They could really do to lose the crap analogies. Hey! Wired people! We're reading an article about DNS. You don't need to anthropomorphise the servers*.
*They really hate that.
posted by pompomtom at 8:30 PM on December 1, 2008 [31 favorites]
cjorgensen
facebook is work, metafilter is research, and crackberries are a business expense.
posted by Glibpaxman at 8:51 PM on December 1, 2008
facebook is work, metafilter is research, and crackberries are a business expense.
posted by Glibpaxman at 8:51 PM on December 1, 2008
Welp, guys. It was a good run. Next time you guys are in SECURITY ZONE 7, stop by my communications-isolated, self-sufficient bunker. It's just to the east of the glowing green lake that used to be Little Rock.
*sips synthetic sweet tea*
posted by sonic meat machine at 9:03 PM on December 1, 2008 [1 favorite]
*sips synthetic sweet tea*
posted by sonic meat machine at 9:03 PM on December 1, 2008 [1 favorite]
I wonder what Kaminsky thinks of that article, as it's not terribly flattering.
posted by Pope Guilty at 9:11 PM on December 1, 2008 [2 favorites]
posted by Pope Guilty at 9:11 PM on December 1, 2008 [2 favorites]
That's pretty clever. You wonder if anyone ever did exploit it -- the victims might never figure it out, they'd just know they'd been compromised in some way. (I'm thinking MILSEC stuff as well as commerce.) It's really stunning that it was never even considered a concern for 25 years, considering the million monkeys -- er, script kiddies -- trying anything and everything they run across.
posted by dhartung at 9:14 PM on December 1, 2008
posted by dhartung at 9:14 PM on December 1, 2008
The third link shows a pretty promising solution, though. Fairly obvious in retrospect, too, but Kaminsky's discovery is really fascinating.
posted by Marisa Stole the Precious Thing at 9:21 PM on December 1, 2008
posted by Marisa Stole the Precious Thing at 9:21 PM on December 1, 2008
DNS != "Internet", we can always go back to Hosts files, man.
But seriously, we need to bite the bullet and cryptographically sign domain name information. There's a big computational cost, but that's probably better then this goofball system.
posted by delmoi at 9:27 PM on December 1, 2008 [1 favorite]
But seriously, we need to bite the bullet and cryptographically sign domain name information. There's a big computational cost, but that's probably better then this goofball system.
posted by delmoi at 9:27 PM on December 1, 2008 [1 favorite]
Eventually it's going to go all Maelstrom anyway.
posted by gottabefunky at 9:32 PM on December 1, 2008
posted by gottabefunky at 9:32 PM on December 1, 2008
IMO, all highly complex systems are (or should be) vulnerable to one human being with the right tools.
Keeps us humble.
posted by cenoxo at 9:53 PM on December 1, 2008 [1 favorite]
Keeps us humble.
posted by cenoxo at 9:53 PM on December 1, 2008 [1 favorite]
I wonder what Kaminsky thinks of that article, as it's not terribly flattering.
Good question, maybe he'll chime in with some knowledge.
posted by empyrean at 10:03 PM on December 1, 2008 [4 favorites]
Good question, maybe he'll chime in with some knowledge.
posted by empyrean at 10:03 PM on December 1, 2008 [4 favorites]
Is it just me, or is the most disturbing part the one where an influential security expert managed to leak this information in two weeks?
posted by Saydur at 10:36 PM on December 1, 2008 [4 favorites]
posted by Saydur at 10:36 PM on December 1, 2008 [4 favorites]
I predict the internet outlasting Wired.
posted by Artw at 10:57 PM on December 1, 2008 [5 favorites]
posted by Artw at 10:57 PM on December 1, 2008 [5 favorites]
IMO, all highly complex systems are (or should be) vulnerable to one human being with the right tools.
Or else Skynet wins.
posted by chudmonkey at 10:59 PM on December 1, 2008
Or else Skynet wins.
posted by chudmonkey at 10:59 PM on December 1, 2008
Well, I wasn't going to self-link it :)
Dan Kaminsky here. Metafilter's been a long time haunt of mine, but it never gets any less weird to see stories about me show up here :) To go over a couple of things:
Regarding the postponing the inevitable: Nobody should be depending on DNS, or unencrypted and (more importantly) unauthenticated communications nearly as much as they are. When I found the bug, I knew it was bad, but...damn. Autoupdates? Forgot My Password systems? Even the SSL infrastructure, the very thing that should have been protecting us, was falling to the chicken/egg construct of Domain Validation, which depended on DNS to make sure DNS wasn't broken. My slides are here, they go into more depth.
The inevitable I was referring to wasn't actually the collapse of the Internet. It was the need to start building infrastructure in a stable and correct manner, to actually achieve the security independence from DNS that people have just sort of assumed we've had. I eventually actually sat down and looked at all the major bugs we've had this year, and came to the following conclusion:
Weaknesses in authentication and encryption, some which have been known to at least some degree for quite some time and many of which are sourced in the core design of the system, continue to pose a threat to the Internet infrastructure at large, both by corrupting routing, and making those corrupted routes problematic.
The reasoning behind that claim is here. A reasonable summary might be -- it's 2008, where's secure email? Seriously, where is it? PGP ain't scalin'.
Ah, but what if you could put PGP keys in DNS, and have it actually be secure? Welcome to why I've been cautiously interested in DNSSEC.
So honestly, I'm hopeful. Amazingly hopeful. I mean, seriously, this actually worked. I didn't think it'd work this well, I just had to try. Yeah, we've got some pretty serious systemic issues with the Internet, but we've also got a lot of people who will expend some serious energy addressing them. If there's one thing to take away from this article, it's that, yes, people are actually out there, and they're not going to let this Internet thing melt down. We've got some ugly bugs we're going to have to eventually address, and it's going to be painful to address them, but it was painful to fix DNS and we did a pretty decent job of it.
Couple other things -- clock *was* ticking. Go check out the Forgery Resilience RFC that was about to be released. That RFC was like a how-to guide on what was needed to implement my attack.
Mullingitover -- don't underestimate what a ridiculous pain in the ass it was to address this design bug. We had some pretty serious constraints, including no changes to the authoritative servers, no changes to DNS semantics, uniform coverage on all domain names, scalability, and all sorts of other things that if we screwed them up, would lead to people just not patching. We went with DJB's suggestion from 1999, but go check out the next-generation proposals coming out. They're all inelegant and frankly messy patchworks, because of all the other corner cases. Even with all we did, we missed just how many name servers would be affected by the firewalls in front of them -- meaning, even with our fix, people had to shift their network topologies or set up DNS forwarders.
Someday I'll document how the tester on www.doxpara.com "works". Messy.
Pope Guilty -- Heh, could be worse :)
posted by effugas at 12:08 AM on December 2, 2008 [186 favorites]
Dan Kaminsky here. Metafilter's been a long time haunt of mine, but it never gets any less weird to see stories about me show up here :) To go over a couple of things:
Regarding the postponing the inevitable: Nobody should be depending on DNS, or unencrypted and (more importantly) unauthenticated communications nearly as much as they are. When I found the bug, I knew it was bad, but...damn. Autoupdates? Forgot My Password systems? Even the SSL infrastructure, the very thing that should have been protecting us, was falling to the chicken/egg construct of Domain Validation, which depended on DNS to make sure DNS wasn't broken. My slides are here, they go into more depth.
The inevitable I was referring to wasn't actually the collapse of the Internet. It was the need to start building infrastructure in a stable and correct manner, to actually achieve the security independence from DNS that people have just sort of assumed we've had. I eventually actually sat down and looked at all the major bugs we've had this year, and came to the following conclusion:
Weaknesses in authentication and encryption, some which have been known to at least some degree for quite some time and many of which are sourced in the core design of the system, continue to pose a threat to the Internet infrastructure at large, both by corrupting routing, and making those corrupted routes problematic.
The reasoning behind that claim is here. A reasonable summary might be -- it's 2008, where's secure email? Seriously, where is it? PGP ain't scalin'.
Ah, but what if you could put PGP keys in DNS, and have it actually be secure? Welcome to why I've been cautiously interested in DNSSEC.
So honestly, I'm hopeful. Amazingly hopeful. I mean, seriously, this actually worked. I didn't think it'd work this well, I just had to try. Yeah, we've got some pretty serious systemic issues with the Internet, but we've also got a lot of people who will expend some serious energy addressing them. If there's one thing to take away from this article, it's that, yes, people are actually out there, and they're not going to let this Internet thing melt down. We've got some ugly bugs we're going to have to eventually address, and it's going to be painful to address them, but it was painful to fix DNS and we did a pretty decent job of it.
Couple other things -- clock *was* ticking. Go check out the Forgery Resilience RFC that was about to be released. That RFC was like a how-to guide on what was needed to implement my attack.
Mullingitover -- don't underestimate what a ridiculous pain in the ass it was to address this design bug. We had some pretty serious constraints, including no changes to the authoritative servers, no changes to DNS semantics, uniform coverage on all domain names, scalability, and all sorts of other things that if we screwed them up, would lead to people just not patching. We went with DJB's suggestion from 1999, but go check out the next-generation proposals coming out. They're all inelegant and frankly messy patchworks, because of all the other corner cases. Even with all we did, we missed just how many name servers would be affected by the firewalls in front of them -- meaning, even with our fix, people had to shift their network topologies or set up DNS forwarders.
Someday I'll document how the tester on www.doxpara.com "works". Messy.
Pope Guilty -- Heh, could be worse :)
posted by effugas at 12:08 AM on December 2, 2008 [186 favorites]
Knowledge dropped. I nominate for sidebar.
posted by empyrean at 12:24 AM on December 2, 2008 [1 favorite]
posted by empyrean at 12:24 AM on December 2, 2008 [1 favorite]
i think as the internet grows more and more holes will be discovered and we will have to become more and more vigilant. Its sort of like how humanity deals with the discovery of the nuclear bomb. There's no going back but going forward feels like we just postpone the inevitable. just like the bomb we haven't blown ourselves up yet - im hopeful we never will.
posted by Glibpaxman at 12:31 AM on December 2, 2008
posted by Glibpaxman at 12:31 AM on December 2, 2008
Seconding sidebar nomination. Not only was this a fairly important thing to happen to the Internet we all love and use, we got a post from someone who helped keep it safe for another day, rather than use it for his own means, then let the secret out so that hackers could have their way with the internet as a whole until companies could think of a fix and scramble to implement it.
You thought the economy was bad now, imagine how it would have been if this got out and banks were robbed as the article suggested.
posted by Chan at 12:59 AM on December 2, 2008
You thought the economy was bad now, imagine how it would have been if this got out and banks were robbed as the article suggested.
posted by Chan at 12:59 AM on December 2, 2008
effugas: I was wondering when someone was going to mention djb. I noticed that he pubdom'd his work earlier this year. Did that have a major bearing on the decision?
posted by electronslave at 1:06 AM on December 2, 2008
posted by electronslave at 1:06 AM on December 2, 2008
Kaminsky seems like kind of a dick
If that's true, then the world needs more dicks.
posted by DreamerFi at 1:09 AM on December 2, 2008 [12 favorites]
If that's true, then the world needs more dicks.
posted by DreamerFi at 1:09 AM on December 2, 2008 [12 favorites]
electronslave--
No bearing whatsoever. People didn't go with DJB's suggestion back in 1999 because it had really awful performance characteristics, and people thought they didn't need to because of the TTL defense. Well, perf is better now, and the TTL defense was destroyed pretty thoroughly by my attack.
Now, did the licensing slow things down? Everyone can speculate, but we'll never really know.
posted by effugas at 1:39 AM on December 2, 2008
No bearing whatsoever. People didn't go with DJB's suggestion back in 1999 because it had really awful performance characteristics, and people thought they didn't need to because of the TTL defense. Well, perf is better now, and the TTL defense was destroyed pretty thoroughly by my attack.
Now, did the licensing slow things down? Everyone can speculate, but we'll never really know.
posted by effugas at 1:39 AM on December 2, 2008
So, where's the tool to test my ISP's DNS servers to see if they've been patched YET?
(They can't even keep their DNS servers up half the time, so I am dubious...)
posted by rokusan at 2:43 AM on December 2, 2008
(They can't even keep their DNS servers up half the time, so I am dubious...)
posted by rokusan at 2:43 AM on December 2, 2008
Even with all we did, we missed just how many name servers would be affected by the firewalls in front of them -- meaning, even with our fix, people had to shift their network topologies or set up DNS forwarders.
Amen. Props to you for the doxpara tester, which revealed the flaw when I was bolting down things. Of course, it turned out my upstream's DNS servers had the firewall issue. Fine, fine, I'll cache my own answers, dammit, but that's that much more traffic on the wire that didn't need to be there.
Not being able to trust upstream caches *at all* is another capacity limitation, and the idea of teaching your mom to run her own caching DNS server is enough to make me wince. "Mom, you forgot to update your root hints again, L changed last week!"
Next time, DK, call in a couple of network guys into the pow-wow. I suspect you missed this aspect because everyone was software oriented, in particular, DNS oriented. Query Source-Port made life much easier on the network gang, right up to the moment when you borked the net.
(You should put that on your business cards.)
And here's the hard part. You can't have a flag day anymore.
You want to change DNS? Fine. You'd better make sure the old version still works as you migrate to the new version, because you are *not* going to get every DNS client on the internet fixed on any given day.
If you say "Well, you have to update or you can't use the Internet," you get IPv6, etc. You'll be on the new, fixed net -- and everyone else will be on the old net, wondering what the hell you're doing.
DNSSEC sucks, because we have to trust One Guy -- that it, whomever signs ".". However, like surgery for appendicitis, it sucks less than any alternative I've seen.
I feel for Vixie and the other DNS gang. They've just been told to rebuild the entire US Highway System, without closing a single lane at any time.
Also -- I think the slam on the security folks is important. The DNS software gang -- crossing multiple vendors -- kept this secret for months. The security community leaked it in days. I'm all for full disclosure, but you give the vendors time to patch. It's when they don't patch that you release. I'm all for what Kaminsky did here -- stood in front of the vendors and said "You're fucked, this is exactly how you're fucked, and you have until Aug. 6th to become unfucked, or the fucking fuck will be truly fucked."
posted by eriko at 3:01 AM on December 2, 2008 [6 favorites]
Amen. Props to you for the doxpara tester, which revealed the flaw when I was bolting down things. Of course, it turned out my upstream's DNS servers had the firewall issue. Fine, fine, I'll cache my own answers, dammit, but that's that much more traffic on the wire that didn't need to be there.
Not being able to trust upstream caches *at all* is another capacity limitation, and the idea of teaching your mom to run her own caching DNS server is enough to make me wince. "Mom, you forgot to update your root hints again, L changed last week!"
Next time, DK, call in a couple of network guys into the pow-wow. I suspect you missed this aspect because everyone was software oriented, in particular, DNS oriented. Query Source-Port made life much easier on the network gang, right up to the moment when you borked the net.
(You should put that on your business cards.)
And here's the hard part. You can't have a flag day anymore.
You want to change DNS? Fine. You'd better make sure the old version still works as you migrate to the new version, because you are *not* going to get every DNS client on the internet fixed on any given day.
If you say "Well, you have to update or you can't use the Internet," you get IPv6, etc. You'll be on the new, fixed net -- and everyone else will be on the old net, wondering what the hell you're doing.
DNSSEC sucks, because we have to trust One Guy -- that it, whomever signs ".". However, like surgery for appendicitis, it sucks less than any alternative I've seen.
I feel for Vixie and the other DNS gang. They've just been told to rebuild the entire US Highway System, without closing a single lane at any time.
Also -- I think the slam on the security folks is important. The DNS software gang -- crossing multiple vendors -- kept this secret for months. The security community leaked it in days. I'm all for full disclosure, but you give the vendors time to patch. It's when they don't patch that you release. I'm all for what Kaminsky did here -- stood in front of the vendors and said "You're fucked, this is exactly how you're fucked, and you have until Aug. 6th to become unfucked, or the fucking fuck will be truly fucked."
posted by eriko at 3:01 AM on December 2, 2008 [6 favorites]
Goddamn, is that one terrible Wired feature! Please do try to avoid becoming the egotistical pundit that they've typecast you as.
posted by blasdelf at 3:11 AM on December 2, 2008 [1 favorite]
posted by blasdelf at 3:11 AM on December 2, 2008 [1 favorite]
I thought the wired piece was flattering in a big-swinging-dick kind of way (for a geek). They should embed some AC/DC when you load it. Also, it needed more explosions and car chases.
posted by i_am_a_Jedi at 4:44 AM on December 2, 2008 [4 favorites]
posted by i_am_a_Jedi at 4:44 AM on December 2, 2008 [4 favorites]
The real story is he broke his arm while running and typing on his laptop and dodging an exploding car that was being chased.
They changed it to maintain realism.
posted by mannequito at 4:55 AM on December 2, 2008 [2 favorites]
They changed it to maintain realism.
posted by mannequito at 4:55 AM on December 2, 2008 [2 favorites]
Couple other things -- clock *was* ticking. Go check out the Forgery Resilience RFC that was about to be released. That RFC was like a how-to guide on what was needed to implement my attack.
What I don't understand is: if this is a bug that had been in DNS for 25 years, why was fixing it so time critical? Did more than one person simultaneously discover it?
posted by salmacis at 5:00 AM on December 2, 2008
What I don't understand is: if this is a bug that had been in DNS for 25 years, why was fixing it so time critical? Did more than one person simultaneously discover it?
posted by salmacis at 5:00 AM on December 2, 2008
Thanks for the information Dan, but my internet is still broken. I rebooted three times like you told me to but I still can't find the website...could you restart it? Nancy says that's what you did last time. Thanks.
posted by Potomac Avenue at 5:01 AM on December 2, 2008
posted by Potomac Avenue at 5:01 AM on December 2, 2008
Rich Mogull, founder of Securosis
Reality, or sci-fi? Sometimes it is hard to tell.
posted by asok at 5:01 AM on December 2, 2008 [6 favorites]
Reality, or sci-fi? Sometimes it is hard to tell.
posted by asok at 5:01 AM on December 2, 2008 [6 favorites]
gotta love wired's infographics. they keep hitting those out of the park issue after issue.
PGP ain't scalin'.
you are right.
PGP's main problem is that it's neither effortless nor fully secure. you're not getting the office crowd using it because it isn't as simple to use as hitting that bold or italic button in your outlook express or whatever the masses are using (lotus notes, anyone? I know seriously massive companies that still use that Dreck piece of software). you're not getting the really serious people because they're afraid of government backdoor keys and potential ability thereof. I love the idea of PGP but it's a concept that requires some serious Ui design first.
Nobody should be depending on DNS, or unencrypted and (more importantly) unauthenticated communications nearly as much as they are.
I see some pretty funny stunts there. who says it's just the printed new york times one could spoof? do this once or twice and a fix will come around quicker than you think.
posted by krautland at 5:42 AM on December 2, 2008
PGP ain't scalin'.
you are right.
PGP's main problem is that it's neither effortless nor fully secure. you're not getting the office crowd using it because it isn't as simple to use as hitting that bold or italic button in your outlook express or whatever the masses are using (lotus notes, anyone? I know seriously massive companies that still use that Dreck piece of software). you're not getting the really serious people because they're afraid of government backdoor keys and potential ability thereof. I love the idea of PGP but it's a concept that requires some serious Ui design first.
Nobody should be depending on DNS, or unencrypted and (more importantly) unauthenticated communications nearly as much as they are.
I see some pretty funny stunts there. who says it's just the printed new york times one could spoof? do this once or twice and a fix will come around quicker than you think.
posted by krautland at 5:42 AM on December 2, 2008
"Maybe the painkillers loosened something in his mind, because as Kaminsky began to think more deeply about DNS he became convinced that something wasn't right. He couldn't quite figure it out, but the feeling stuck with him even after he stopped taking the pain pills."
posted by tybeet at 5:57 AM on December 2, 2008 [1 favorite]
posted by tybeet at 5:57 AM on December 2, 2008 [1 favorite]
I don't see what the problem is here. Can't we just get bigger tubes or something?
More seriously, my hope is that fully addressing this issue will be used as an opportunity to also finally slam the door on spam by finding a concurrent fix for mail relay. Wouldn't some sort of global authentication and verification method help eliminate garbage like this?
posted by caution live frogs at 6:05 AM on December 2, 2008
More seriously, my hope is that fully addressing this issue will be used as an opportunity to also finally slam the door on spam by finding a concurrent fix for mail relay. Wouldn't some sort of global authentication and verification method help eliminate garbage like this?
posted by caution live frogs at 6:05 AM on December 2, 2008
They could really do to lose the crap analogies. Hey! Wired people! We're reading an article about DNS. You don't need to anthropomorphise the servers
Do mail servers still respond to a jaunty Helo with a "250 Hello your.self.com pleased to meet you"? Then don't come it.
posted by bonaldi at 6:23 AM on December 2, 2008
Do mail servers still respond to a jaunty Helo with a "250 Hello your.self.com pleased to meet you"? Then don't come it.
posted by bonaldi at 6:23 AM on December 2, 2008
rokusan--
www.doxpara.com has a checker on the right hand side.
eriko--
There are interesting models of DNSSEC that put all the hard work in the client -- a "fat stub resolver" -- but still take advantage of the intermediate tier for caching. There's actually a chance this will scale far, far better.
We actually had some network guys at our meeting -- we just all overestimated how many name servers were behind NATs. We figured it was much rarer than it really was.
The "oh no you have to trust one person" thing is totally overblown. First off, would you prefer the x.509 model, where you have to totally trust 40 people? Secondly, what do you think you have now, with relatively few operating system vendors holding sway -- with automatic update -- over the world's systems? Finally, nothing says you can't easily forcably set trust anchors within the heirarchy -- think of a sort of "infinite TTL" on certain names. In this scenario, DNSSEC is just a bootstrapper, allowing for single leaps of faith that scale as opposed to our present hurdles of faih that, you know, don't.
Most of the security community kept the secret just fine, long after they'd figured out the vuln. I mean, people had popped this without a hint in 53 hours.
blasdelf--
Amen.
salmacis--
Actually, yeah. Florian Weimer figured this out independently, but didn't recognize the sheer scope of his discovery. It was only last year that Amit Klein finally noticed that the random TXID's weren't even random at all. The Forgery Resilience RFC was the big problem -- the best part was suppressing it by telling people its author couldn't work on it because his wife was about to have a baby.
This had the happy coincidence of being true :)
caution--
I think so. I think the friction of even exploring better fixes is so high, that nothing's working. That being said, SPAM is a very tricky problem, with profit levels high enough to motivate quite a bit of counter-engineering.
posted by effugas at 7:45 AM on December 2, 2008
www.doxpara.com has a checker on the right hand side.
eriko--
There are interesting models of DNSSEC that put all the hard work in the client -- a "fat stub resolver" -- but still take advantage of the intermediate tier for caching. There's actually a chance this will scale far, far better.
We actually had some network guys at our meeting -- we just all overestimated how many name servers were behind NATs. We figured it was much rarer than it really was.
The "oh no you have to trust one person" thing is totally overblown. First off, would you prefer the x.509 model, where you have to totally trust 40 people? Secondly, what do you think you have now, with relatively few operating system vendors holding sway -- with automatic update -- over the world's systems? Finally, nothing says you can't easily forcably set trust anchors within the heirarchy -- think of a sort of "infinite TTL" on certain names. In this scenario, DNSSEC is just a bootstrapper, allowing for single leaps of faith that scale as opposed to our present hurdles of faih that, you know, don't.
Most of the security community kept the secret just fine, long after they'd figured out the vuln. I mean, people had popped this without a hint in 53 hours.
blasdelf--
Amen.
salmacis--
Actually, yeah. Florian Weimer figured this out independently, but didn't recognize the sheer scope of his discovery. It was only last year that Amit Klein finally noticed that the random TXID's weren't even random at all. The Forgery Resilience RFC was the big problem -- the best part was suppressing it by telling people its author couldn't work on it because his wife was about to have a baby.
This had the happy coincidence of being true :)
caution--
I think so. I think the friction of even exploring better fixes is so high, that nothing's working. That being said, SPAM is a very tricky problem, with profit levels high enough to motivate quite a bit of counter-engineering.
posted by effugas at 7:45 AM on December 2, 2008
Dan: Good on you for what you did. Out of morbid curiosity, what's the absolute worst you could have done? If your goal was to maximize damage? (And how did you resist the temptation to at least enrich yourself just a tiny little bit...)
posted by Ljubljana at 9:04 AM on December 2, 2008 [2 favorites]
posted by Ljubljana at 9:04 AM on December 2, 2008 [2 favorites]
the internet is too big to fail.
posted by the painkiller at 9:06 AM on December 2, 2008
posted by the painkiller at 9:06 AM on December 2, 2008
www.doxpara.com has a checker on the right hand side.
And my name server is safe! Hee~
*hugs router*
Let's never fight again.
posted by Marisa Stole the Precious Thing at 9:13 AM on December 2, 2008 [3 favorites]
And my name server is safe! Hee~
*hugs router*
Let's never fight again.
posted by Marisa Stole the Precious Thing at 9:13 AM on December 2, 2008 [3 favorites]
salmacis : What I don't understand is: if this is a bug that had been in DNS for 25 years, why was fixing it so time critical? Did more than one person simultaneously discover it?
I would guess that it's one of those things where now that it is known, it's an invitation to anyone without a conscience to exploit it. Kind of like how Kryptonite bike locks were long considered one of the best you could get, until it was discovered that you could pop one open with a ballpoint pen, and nearly overnight everyone learned how to do it, totally negating any security value they provided.
posted by quin at 9:23 AM on December 2, 2008 [1 favorite]
I would guess that it's one of those things where now that it is known, it's an invitation to anyone without a conscience to exploit it. Kind of like how Kryptonite bike locks were long considered one of the best you could get, until it was discovered that you could pop one open with a ballpoint pen, and nearly overnight everyone learned how to do it, totally negating any security value they provided.
posted by quin at 9:23 AM on December 2, 2008 [1 favorite]
Huh. I thought the internet was supposed to collapse back in the mid to late 90s, from being overloaded with traffic. I was actually a little disappointed when that didn't happen, because it would have gotten rid of all the "permanent September" people that were infesting Usenet. Ah nostalgia...
posted by happyroach at 9:28 AM on December 2, 2008
posted by happyroach at 9:28 AM on December 2, 2008
I've been hit by this. Someone poisoned my upstream DNS to return their IP for one of my machines, so that when I try to SSH to www.mymachine.com it went to their IP. Fortunately SSH complained about the IP not matching what I had in my "known hosts" so I aborted and figured it out.
I also got tasked with fixing our software product to keep it from being exploited by this bug (Kaminsky actually called out our product by name in his slides!) and found a class of this bug which was actually *far* more severe than what he lays out in those slides - fortunately no other DNS resolver I tried had that bug. You could actually poison our DNS cache WITHOUT the multiple tries and indirection required for most DNS servers.
There are many parts of the internet that have been around for a very long time (hello, email) that need to probably be totally re-thought, insteaad of endlessly hacked onto. These days, that's a pretty hard thing to do.
posted by RustyBrooks at 10:45 AM on December 2, 2008
I also got tasked with fixing our software product to keep it from being exploited by this bug (Kaminsky actually called out our product by name in his slides!) and found a class of this bug which was actually *far* more severe than what he lays out in those slides - fortunately no other DNS resolver I tried had that bug. You could actually poison our DNS cache WITHOUT the multiple tries and indirection required for most DNS servers.
There are many parts of the internet that have been around for a very long time (hello, email) that need to probably be totally re-thought, insteaad of endlessly hacked onto. These days, that's a pretty hard thing to do.
posted by RustyBrooks at 10:45 AM on December 2, 2008
the internet is too big to fail
Yeah, the Roman Empire too.
posted by CaseyB at 12:28 PM on December 2, 2008
Yeah, the Roman Empire too.
posted by CaseyB at 12:28 PM on December 2, 2008
I happen to know that Dan's handle is a Latin subjunctive. So there.
posted by languagehat at 2:22 PM on December 2, 2008 [6 favorites]
posted by languagehat at 2:22 PM on December 2, 2008 [6 favorites]
I remember reading about this in the previous thread, and really scratching my head about the scope.. Wired's explanation:
I dunno, I must be misunderstanding something, because what I've gleaned wouldn't allow for this scope:
- The attacker tries to hijack anybank.com by sending thousands of requests for fake Web pages (1.anybank.com, 2.anybank.com).
- The ISP gives each query a transaction ID (unknown to the attacker) and attempts to locate the pages.
- At the same time, the attacker sends hundreds of responses for each malicious request. Every answer includes a randomly generated ID number.
- Eventually one of the answers carries an ID that matches, tricking the ISP into accepting and caching the information. The now-legitimized answer contains false details about anybank.com, such as the location of its servers. Legitimate answers from anybank.com ("No such page exists") will now be rejected.
- Users looking for anybank.com get sent to the fake location already in the ISP's cache.
- Anybank.com customers are now using a look-alike site built by the hacker.
I dunno, I must be misunderstanding something, because what I've gleaned wouldn't allow for this scope:
This would allow him to [...] reroute anyone's email,posted by Chuckles at 2:26 PM on December 2, 2008
Chuckles--
Yeah, you're missing that it's ridiculously easy to get random name servers, even those behind firewalls, to look *something* up from a name you control. Once they come, you send them to an out-of-bailiwick name (11111A.GTLD-SERVERS.NET for example) and feed them false replies that redirect all of A.GTLD-SERVERS.NET, and thus com.
It's actually a bigger problem that it's so easy to surgically strike with this vuln.
posted by effugas at 4:24 PM on December 2, 2008
Yeah, you're missing that it's ridiculously easy to get random name servers, even those behind firewalls, to look *something* up from a name you control. Once they come, you send them to an out-of-bailiwick name (11111A.GTLD-SERVERS.NET for example) and feed them false replies that redirect all of A.GTLD-SERVERS.NET, and thus com.
It's actually a bigger problem that it's so easy to surgically strike with this vuln.
posted by effugas at 4:24 PM on December 2, 2008
Eriko wrote "the idea of teaching your mom to run her own caching DNS server is enough to make me wince. 'Mom, you forgot to update your root hints again, L changed last week!'"
So true eriko, most of the mom's I know who are over 40 years old would call their hairdresser to fix their roots.
Thanks for vigilance, effugas.
posted by Cranberry at 4:49 PM on December 2, 2008
So true eriko, most of the mom's I know who are over 40 years old would call their hairdresser to fix their roots.
Thanks for vigilance, effugas.
posted by Cranberry at 4:49 PM on December 2, 2008
Chuckles, also, you literally only have to say hello to a mail server for it to force an attacker-controlled DNS lookup (or eight -- it's not subtle).
posted by effugas at 5:09 PM on December 2, 2008
posted by effugas at 5:09 PM on December 2, 2008
Kaminsky seems like kind of a dick. -- mullingitover
Geeks often appear rude and socially tone-deaf to outsiders. Don't be a cunt about it, okay?
(What?)
posted by rokusan at 5:32 PM on December 2, 2008
Geeks often appear rude and socially tone-deaf to outsiders. Don't be a cunt about it, okay?
(What?)
posted by rokusan at 5:32 PM on December 2, 2008
rokusan writes "Geeks often appear rude and socially tone-deaf to outsiders. Don't be a cunt about it, okay?"
What do you mean, appear? :P
effugas writes "Mullingitover -- don't underestimate what a ridiculous pain in the ass it was to address this design bug."
Yeah, I totally retract my inane comment. I've had a taste of the rage-inducing madness of wrangling bugs, and I feel your pain.
posted by mullingitover at 6:17 PM on December 2, 2008
What do you mean, appear? :P
effugas writes "Mullingitover -- don't underestimate what a ridiculous pain in the ass it was to address this design bug."
Yeah, I totally retract my inane comment. I've had a taste of the rage-inducing madness of wrangling bugs, and I feel your pain.
posted by mullingitover at 6:17 PM on December 2, 2008
There are many parts of the internet that have been around for a very long time (hello, email) that need to probably be totally re-thought, insteaad of endlessly hacked onto. These days, that's a pretty hard thing to do.
I disagree -- for your consideration a backwards-compatible solution that can be implemented in less than 1000 lines of Lisp code.
posted by spiderwire at 7:51 PM on December 2, 2008 [1 favorite]
I disagree -- for your consideration a backwards-compatible solution that can be implemented in less than 1000 lines of Lisp code.
posted by spiderwire at 7:51 PM on December 2, 2008 [1 favorite]
*** To clarify: a mechanism for reliable user-end email management that requires only a standard-config port 25 SMTP server.
posted by spiderwire at 8:01 PM on December 2, 2008
posted by spiderwire at 8:01 PM on December 2, 2008
eff: I'm not sure I understand the question or the issue -- a CC would get munged through the encoder/decoder (I was assuming implementing it as a postfix address-rewriter) going one way, and de-munged going the other way, just like any other address; could you be more specific?
Or are you talking about exposing the generated email address to unintended recipients via a CC? If that was a problem, it seems like it'd be trivial to use some sort of greylisting, with a hashcash option that senders could use to regenerate new unique keys; it would be clumsy to do without breaking full backward-compatibility, but possible.
posted by spiderwire at 10:49 PM on December 2, 2008
Or are you talking about exposing the generated email address to unintended recipients via a CC? If that was a problem, it seems like it'd be trivial to use some sort of greylisting, with a hashcash option that senders could use to regenerate new unique keys; it would be clumsy to do without breaking full backward-compatibility, but possible.
posted by spiderwire at 10:49 PM on December 2, 2008
I have to admit that I'm curious to hear any criticisms of the above mechanism.
posted by spiderwire at 11:16 PM on December 2, 2008
posted by spiderwire at 11:16 PM on December 2, 2008
I curious as to why folks think Kaminsky came out looking bad(ish) in the article. I'm not a security wonk; is it considered really bad form to puff up the announcement of an exploit or brag about it even if disaster was averted? By the time of the conference, he'd spent weeks and weeks cooperating with the DNS software architects and being really responsible. Right?
posted by cowbellemoo at 7:40 AM on December 3, 2008
posted by cowbellemoo at 7:40 AM on December 3, 2008
This would make a great film. Like all films, it would be even better if there were zombies involved. Are you sure there were no zombies involved, Dan?
posted by chill at 8:35 AM on December 3, 2008
posted by chill at 8:35 AM on December 3, 2008
spiderwire--
It fails to what all magic email systems fail to -- it's unreliable for anything but the canonical case. How do you put an address on a business card? How do two people mail eachother who only have business cards? How are people added and removed from CC's and BCC's? What about address books in mail clients?
There's a reason this is an ugly problem.
cowbellmoo--
Independent of the article, it's been an enormous amount of noise for quite some time. Especially during July, there was a huge amount of press with no technical details and no peer review. 99 times out of 100, that means someone's lying, or trying to sell something, or both. I was that 1 time -- I was just trying to give people time to deploy an out-of-cycle patch.
Regarding the article itself, as my (omitted from the article) girlfriend described it -- "Awkward guy saves Internet!" :)
posted by effugas at 11:14 AM on December 3, 2008
It fails to what all magic email systems fail to -- it's unreliable for anything but the canonical case. How do you put an address on a business card? How do two people mail eachother who only have business cards? How are people added and removed from CC's and BCC's? What about address books in mail clients?
There's a reason this is an ugly problem.
cowbellmoo--
Independent of the article, it's been an enormous amount of noise for quite some time. Especially during July, there was a huge amount of press with no technical details and no peer review. 99 times out of 100, that means someone's lying, or trying to sell something, or both. I was that 1 time -- I was just trying to give people time to deploy an out-of-cycle patch.
Regarding the article itself, as my (omitted from the article) girlfriend described it -- "Awkward guy saves Internet!" :)
posted by effugas at 11:14 AM on December 3, 2008
Regarding the article itself, as my (omitted from the article) girlfriend described it -- "Awkward guy saves Internet!" :)
Having heard her describe it that way, it was difficult not to chime in when the question was asked.
But I figured you were going to chime in, and even if you weren't I wasn't going to speak for you. I'm glad you did!
posted by flaterik at 11:27 AM on December 3, 2008
Having heard her describe it that way, it was difficult not to chime in when the question was asked.
But I figured you were going to chime in, and even if you weren't I wasn't going to speak for you. I'm glad you did!
posted by flaterik at 11:27 AM on December 3, 2008
How do you put an address on a business card? How do two people mail eachother who only have business cards? How are people added and removed from CC's and BCC's? What about address books in mail clients?
Well, you just write it on the card; if it gets greylisted, subject unknown senders to vanilla SMTP-AUTH, then generate a new unique address and substitute it into the Reply-To: header.
posted by spiderwire at 1:33 PM on December 3, 2008
Well, you just write it on the card; if it gets greylisted, subject unknown senders to vanilla SMTP-AUTH, then generate a new unique address and substitute it into the Reply-To: header.
posted by spiderwire at 1:33 PM on December 3, 2008
"DNS Buster?"
"DNS Buster-Buster!"
"DNS Buster-Buster-BUSTER!"
posted by artof.mulata at 2:17 PM on December 3, 2008
"DNS Buster-Buster!"
"DNS Buster-Buster-BUSTER!"
posted by artof.mulata at 2:17 PM on December 3, 2008
spiderwire--
You assume reply-to is handled in any consistent way, especially with address books.
Look, if there were 1000 line fixes to the problem, we'd have done them by now.
posted by effugas at 11:13 AM on December 4, 2008
You assume reply-to is handled in any consistent way, especially with address books.
Look, if there were 1000 line fixes to the problem, we'd have done them by now.
posted by effugas at 11:13 AM on December 4, 2008
effugas: Thanks. If it makes you feel any better, I saw the article as "unassuming software drone ditches work to spur techno-intelligentsia to shore up the crumbling foundations of the internet economy. internet demands moar." :P
posted by cowbellemoo at 11:59 AM on December 4, 2008
posted by cowbellemoo at 11:59 AM on December 4, 2008
effugas: You assume reply-to is handled in any consistent way, especially with address books.
I suppose you could just use the straight TO: headers, but in any event I don't see why that's relevant. The problem you describe is addressed in RFC5321 Section 3.4, so if that's a special-case issue, it's not "email" that's broken, it's the non-conforming client.
Regardless, it's anterior to the question of how the "tokenized" email address could be communicated on a business card without compromising its security, which is how I understood your initial objection.
posted by spiderwire at 9:29 AM on December 5, 2008
I suppose you could just use the straight TO: headers, but in any event I don't see why that's relevant. The problem you describe is addressed in RFC5321 Section 3.4, so if that's a special-case issue, it's not "email" that's broken, it's the non-conforming client.
Regardless, it's anterior to the question of how the "tokenized" email address could be communicated on a business card without compromising its security, which is how I understood your initial objection.
posted by spiderwire at 9:29 AM on December 5, 2008
Look, if there were 1000 line fixes to the problem, we'd have done them by now.
This, too, is an interesting response. It seems to me that the issues you confronted -- as described in the linked article -- represent a very straightforward example of a "broken" system that could have been repaired with (relatively) trivial modifications, but for one reason or another, wasn't.
The moral, one would think, is that in a technical system of sufficient scope, there are no fixes that are so easy as to be inevitable.
posted by spiderwire at 9:39 AM on December 5, 2008
This, too, is an interesting response. It seems to me that the issues you confronted -- as described in the linked article -- represent a very straightforward example of a "broken" system that could have been repaired with (relatively) trivial modifications, but for one reason or another, wasn't.
The moral, one would think, is that in a technical system of sufficient scope, there are no fixes that are so easy as to be inevitable.
posted by spiderwire at 9:39 AM on December 5, 2008
Spiderwire, spend some time on these pages to understand why your idea doesn't work. To start with, it has these prerequisites:
posted by anildash at 6:49 PM on December 5, 2008
- Change the email behavior of over a billion users on the web.
- Install processor-heavy hashing software on tens of thousands of servers around the web.
- Install parsing application, complete with database storage requirement, on all of those tens of thousands of servers.
- Update all kinds of routing, filtering, antispam, forwarding, and storage devices, appliances and software to handle this new message addressing.
- Require mandatory updates for the 90% of email clients that don't implement every single part of every dependent RFC in your spec correctly.
posted by anildash at 6:49 PM on December 5, 2008
Oh, good lord. My comment got eaten.
With all due respect, anil, I don't think that those somewhat anodyne objections make sense. The proposal is, technically speaking, backwards-compatible with external SMTP clients, and could be implemented as a postfix address-rewriter plugin with a few bytes overhead per message at most. I'm not sure what "hashing software" means, since CRAM-MD5 is already part of the ESMTP implementation that's probably already installed on your computer right now, and it's not particularly processor-intensive.
The scheme is, implementation-wise, no different from gmail's address+suffix@gmail.com implementation -- which is likewise perfectly transparent to external servers -- but without the notable disadvantage of being easy to defeat by stripping everything after the '+'.
For example, if 'anil' and 'dash' are registered to the same user, a message can be forwarded reliably via mefi.anil@dash.mail.com without revealing 'mefi' as the nonce phrase, even if 'mefi' is registered to a different user, with 'mefi' otherwise functioning like the suffix phrase in the gmail '+' system. No server upgrades nor external compliance with specs is necessary.
posted by spiderwire at 7:39 PM on December 5, 2008
With all due respect, anil, I don't think that those somewhat anodyne objections make sense. The proposal is, technically speaking, backwards-compatible with external SMTP clients, and could be implemented as a postfix address-rewriter plugin with a few bytes overhead per message at most. I'm not sure what "hashing software" means, since CRAM-MD5 is already part of the ESMTP implementation that's probably already installed on your computer right now, and it's not particularly processor-intensive.
The scheme is, implementation-wise, no different from gmail's address+suffix@gmail.com implementation -- which is likewise perfectly transparent to external servers -- but without the notable disadvantage of being easy to defeat by stripping everything after the '+'.
For example, if 'anil' and 'dash' are registered to the same user, a message can be forwarded reliably via mefi.anil@dash.mail.com without revealing 'mefi' as the nonce phrase, even if 'mefi' is registered to a different user, with 'mefi' otherwise functioning like the suffix phrase in the gmail '+' system. No server upgrades nor external compliance with specs is necessary.
posted by spiderwire at 7:39 PM on December 5, 2008
Spiderwire: I took a look at it. It's not gonna matter a bit, will have a tiny impact for the work involved and only solves a minor problem in the spam fight.
1. The key bit seems to be "neither sender nor receiver is exposed to the other's email address".
Well, uh, no. The sender is protected, sure, but the receiver has had to expose an email address. For all useful purposes, billthecat.forprez@meadowparty.pony.com is an email address. If it doesn't send on all mail received to it, it's useless. (ie, what would you put on a business card?)
If you mean it protects the user's "real" email address, well sure, you've just re-invented sneakemail. Congratulations.
2. As specified, the user doesn't get to see the real address of the people sending him email. So firstly your database intermediary better be up all the time, secondly you're giving spammers protection behind an impenetrable cloak of anonymity, thirdly you're destroying all sorts of useful mail client functionality (lotsa filters gonna break if everything comes from pony.com)
3. If this makes email "safe", someone hasn't understood why it's "dangerous". The problem it appears to be solving is that you can't spread about your email address in public without spam arriving at it. But everyone's already solved that at the social level. Who doesn't have two accounts these days (one for humans, one for the web)?
4. Disposable or quasi-disposable addresses don't solve shit. You either use a unique one for every conceivable sender (which is a pain in the fucking tits with sites that use email as logins), or you run the risk of never being able to disable the address without losing mail from certain senders.
posted by bonaldi at 8:24 PM on December 5, 2008
1. The key bit seems to be "neither sender nor receiver is exposed to the other's email address".
Well, uh, no. The sender is protected, sure, but the receiver has had to expose an email address. For all useful purposes, billthecat.forprez@meadowparty.pony.com is an email address. If it doesn't send on all mail received to it, it's useless. (ie, what would you put on a business card?)
If you mean it protects the user's "real" email address, well sure, you've just re-invented sneakemail. Congratulations.
2. As specified, the user doesn't get to see the real address of the people sending him email. So firstly your database intermediary better be up all the time, secondly you're giving spammers protection behind an impenetrable cloak of anonymity, thirdly you're destroying all sorts of useful mail client functionality (lotsa filters gonna break if everything comes from pony.com)
3. If this makes email "safe", someone hasn't understood why it's "dangerous". The problem it appears to be solving is that you can't spread about your email address in public without spam arriving at it. But everyone's already solved that at the social level. Who doesn't have two accounts these days (one for humans, one for the web)?
4. Disposable or quasi-disposable addresses don't solve shit. You either use a unique one for every conceivable sender (which is a pain in the fucking tits with sites that use email as logins), or you run the risk of never being able to disable the address without losing mail from certain senders.
posted by bonaldi at 8:24 PM on December 5, 2008
bonaldi, I actually think those are good critiques, the attitude notwithstanding.
1. The key bit seems to be "neither sender nor receiver is exposed to the other's email address".
Well, uh, no. The sender is protected, sure, but the receiver has had to expose an email address. For all useful purposes, billthecat.forprez@meadowparty.pony.com is an email address. If it doesn't send on all mail received to it, it's useless. (ie, what would you put on a business card?)
I wouldn't call that the "key bit." That simply means that the email address isn't in the text of the email -- otherwise you run the risk of hitting "reply" and getting the actual address quoted in the plaintext or an attachment where it can be stripped out. Non-exposure isn't an inherent feature, simply a default setting that prevents backdoor scraping.
If you mean it protects the user's "real" email address, well sure, you've just re-invented sneakemail. Congratulations.
Yuck, lord no, mostly for the reasons you isolate below, which I'll get to.
2. As specified, the user doesn't get to see the real address of the people sending him email.
And as specified, that's optional. Certainly not a "cloak of anonymity."
So firstly your database intermediary better be up all the time,
As much time as my specified postfix mail server is up? The one the addy rewriter plugs into? OK, done.
thirdly you're destroying all sorts of useful mail client functionality (lotsa filters gonna break if everything comes from pony.com)
This would be implemented at the edge of the network (users and local clients), so I don't see how you get your doomsday scenario -- as with gmail's addy+suffix@gmail.com, it's just another backwards-compatible format that can't be spoofed or stripped.
3. If this makes email "safe", someone hasn't understood why it's "dangerous". The problem it appears to be solving is that you can't spread about your email address in public without spam arriving at it. But everyone's already solved that at the social level. Who doesn't have two accounts these days (one for humans, one for the web)?
I think it should be better than it is. And not just for antispam -- we're getting better at that. I want to control my own lists -- this junk mail I get from my Honda dealer or Amazon -- and I think we're falling into the same sort of complacency that we adopted about our physical mailboxes long ago -- that needs to stop. That's not "solving" the problem, that's throwing in the towel. Please, send me all the "legitimate" advertising for iPods and books and cars and blah blah blah...No thanks.
4. Disposable or quasi-disposable addresses don't solve shit. You either use a unique one for every conceivable sender (which is a pain in the fucking tits with sites that use email as logins), or you run the risk of never being able to disable the address without losing mail from certain senders.
I agree completely -- and it's here that this proposal is most effective, in fact. You can come up with a "disposable" address on the spot without having to generate some arcane jumble of letters and numbers for a login -- instead just use [sitename].bonaldi@curmudgeon.pony.com when you sign up ('curmudgeon' being the token I invented for you) and you're done!
posted by spiderwire at 8:50 PM on December 5, 2008
1. The key bit seems to be "neither sender nor receiver is exposed to the other's email address".
Well, uh, no. The sender is protected, sure, but the receiver has had to expose an email address. For all useful purposes, billthecat.forprez@meadowparty.pony.com is an email address. If it doesn't send on all mail received to it, it's useless. (ie, what would you put on a business card?)
I wouldn't call that the "key bit." That simply means that the email address isn't in the text of the email -- otherwise you run the risk of hitting "reply" and getting the actual address quoted in the plaintext or an attachment where it can be stripped out. Non-exposure isn't an inherent feature, simply a default setting that prevents backdoor scraping.
If you mean it protects the user's "real" email address, well sure, you've just re-invented sneakemail. Congratulations.
Yuck, lord no, mostly for the reasons you isolate below, which I'll get to.
2. As specified, the user doesn't get to see the real address of the people sending him email.
And as specified, that's optional. Certainly not a "cloak of anonymity."
So firstly your database intermediary better be up all the time,
As much time as my specified postfix mail server is up? The one the addy rewriter plugs into? OK, done.
thirdly you're destroying all sorts of useful mail client functionality (lotsa filters gonna break if everything comes from pony.com)
This would be implemented at the edge of the network (users and local clients), so I don't see how you get your doomsday scenario -- as with gmail's addy+suffix@gmail.com, it's just another backwards-compatible format that can't be spoofed or stripped.
3. If this makes email "safe", someone hasn't understood why it's "dangerous". The problem it appears to be solving is that you can't spread about your email address in public without spam arriving at it. But everyone's already solved that at the social level. Who doesn't have two accounts these days (one for humans, one for the web)?
I think it should be better than it is. And not just for antispam -- we're getting better at that. I want to control my own lists -- this junk mail I get from my Honda dealer or Amazon -- and I think we're falling into the same sort of complacency that we adopted about our physical mailboxes long ago -- that needs to stop. That's not "solving" the problem, that's throwing in the towel. Please, send me all the "legitimate" advertising for iPods and books and cars and blah blah blah...No thanks.
4. Disposable or quasi-disposable addresses don't solve shit. You either use a unique one for every conceivable sender (which is a pain in the fucking tits with sites that use email as logins), or you run the risk of never being able to disable the address without losing mail from certain senders.
I agree completely -- and it's here that this proposal is most effective, in fact. You can come up with a "disposable" address on the spot without having to generate some arcane jumble of letters and numbers for a login -- instead just use [sitename].bonaldi@curmudgeon.pony.com when you sign up ('curmudgeon' being the token I invented for you) and you're done!
posted by spiderwire at 8:50 PM on December 5, 2008
Sorry if the attitude comes off wrongly, I'm just responding to the perceived attitude I'm getting that "hey this is simple, why don't we do this?" when it really isn't simple.
I wouldn't call that the "key bit."
OK, so what is, then? How does it solve the problem of spam: I have to publish my address, and I only want to receive correspondence at itfrom certain unknown addresses? There must be something I'm missing, and the graphic's how-it-happens doesn't explain how-it-works or why-it's-good.
And as specified, that's optional. Certainly not a "cloak of anonymity."
It's not optional in your graphic, and also in the graphic there's no way for me to see who the sender is.
As much time as my specified postfix mail server is up? The one the addy rewriter plugs into? OK, done.
Really? Because I'm about to quadruple its load: if [hash1]@[hash2]s.pony.com is my only way to get in touch with people, then virtually all of my outgoing mail is going to be going through you, regardless of my SMTP server. So a) I'm gonna need to really trust pony.com, b) whoah load-tastic.
It also brings to mind another problem: I have more than one email account. But all you've given me for people's address is x@y.pony.com. So I get an email at my work from some dude looking for a file. I want to send it to him. It's in my gmail. I go to gmail and forward to x@y.pony.com. Does it send? What does it put as a reply-to on that email?
This would be implemented at the edge of the network (users and local clients), so I don't see how you get your doomsday scenario -- as with gmail's addy+suffix@gmail.com, it's just another backwards-compatible format that can't be spoofed or stripped.
In the graphic, all my email comes to me from [hash1]@[hash2]s.pony.com, right? So how do I filter out emails from my work's domain to label them?
You can come up with a "disposable" address on the spot without having to generate some arcane jumble of letters and numbers for a login -- instead just use [sitename].bonaldi@curmudgeon.pony.com when you sign up ... and you're done!
... except I'm not. Here I am, signing up for Mefi. I make my MeFi address mefi.bonaldi@grump.pony.com. It's in my profile. I get some nice emails from nice MeFites (this is all pre MeMail). One day, pb gets drunk and mistypes something -- The profile pages are public. It's a week before anyone notices. mefi.bonaldi@grump.pony.com is scraped. Spam begins arriving.
What now? I can't drop all mail to mefi.bonaldi, because that's what some nice people use to get in touch with me. I don't want to only allow people who've replied to me, because I didn't reply to everyone. I have to filter it. So now the problem has been pushed back a level -- I've got an email address that spam is arriving at. It's not my "real" address, but it might as well be.
What if I'd printed that address on a business card?
posted by bonaldi at 9:13 PM on December 5, 2008
I wouldn't call that the "key bit."
OK, so what is, then? How does it solve the problem of spam: I have to publish my address, and I only want to receive correspondence at itfrom certain unknown addresses? There must be something I'm missing, and the graphic's how-it-happens doesn't explain how-it-works or why-it's-good.
And as specified, that's optional. Certainly not a "cloak of anonymity."
It's not optional in your graphic, and also in the graphic there's no way for me to see who the sender is.
As much time as my specified postfix mail server is up? The one the addy rewriter plugs into? OK, done.
Really? Because I'm about to quadruple its load: if [hash1]@[hash2]s.pony.com is my only way to get in touch with people, then virtually all of my outgoing mail is going to be going through you, regardless of my SMTP server. So a) I'm gonna need to really trust pony.com, b) whoah load-tastic.
It also brings to mind another problem: I have more than one email account. But all you've given me for people's address is x@y.pony.com. So I get an email at my work from some dude looking for a file. I want to send it to him. It's in my gmail. I go to gmail and forward to x@y.pony.com. Does it send? What does it put as a reply-to on that email?
This would be implemented at the edge of the network (users and local clients), so I don't see how you get your doomsday scenario -- as with gmail's addy+suffix@gmail.com, it's just another backwards-compatible format that can't be spoofed or stripped.
In the graphic, all my email comes to me from [hash1]@[hash2]s.pony.com, right? So how do I filter out emails from my work's domain to label them?
You can come up with a "disposable" address on the spot without having to generate some arcane jumble of letters and numbers for a login -- instead just use [sitename].bonaldi@curmudgeon.pony.com when you sign up ... and you're done!
... except I'm not. Here I am, signing up for Mefi. I make my MeFi address mefi.bonaldi@grump.pony.com. It's in my profile. I get some nice emails from nice MeFites (this is all pre MeMail). One day, pb gets drunk and mistypes something -- The profile pages are public. It's a week before anyone notices. mefi.bonaldi@grump.pony.com is scraped. Spam begins arriving.
What now? I can't drop all mail to mefi.bonaldi, because that's what some nice people use to get in touch with me. I don't want to only allow people who've replied to me, because I didn't reply to everyone. I have to filter it. So now the problem has been pushed back a level -- I've got an email address that spam is arriving at. It's not my "real" address, but it might as well be.
What if I'd printed that address on a business card?
posted by bonaldi at 9:13 PM on December 5, 2008
Sorry if the attitude comes off wrongly, I'm just responding to the perceived attitude I'm getting that "hey this is simple, why don't we do this?" when it really isn't simple.
It is pretty simple, it's just obviously a little counterintuitive, because the implementation is not that different from vanilla disposable addresses. The graphic was intended as a how-to, not a why-this, and I'm obviously not explaining the distinction very well (if you know how to set up a Lisp REPL I could just send the code...)
What now? I can't drop all mail to mefi.bonaldi, because that's what some nice people use to get in touch with me. I don't want to only allow people who've replied to me, because I didn't reply to everyone. I have to filter it. So now the problem has been pushed back a level -- I've got an email address that spam is arriving at. It's not my "real" address, but it might as well be.
This is a good point, and I'll admit that this is no cure-all solution, but it allows you to create a greylist that's 100% reliable from the receiving end, which is an important first step that isn't possible under other schemes because of the scraping problem.
So, yes, the logical question then (which efflugas pointed out above) is: what if the address gets compromised? The initial answer is that once an address is greylisted, you do a one-time hash check and reply with a newly generated address to that sender. If the new address gets greylisted, you may have to increase the hash difficulty by an order of magnitude or so.
So, next, how is that different than systems that already exist? Two reasons: (1) mefi.bonaldi can be isolated as the point-of-compromise (which isn't feasible with the suffix method), but (2) you can still post the address without having to generate a new address (which for business cards prevents the disposable-address method).
Generally it's not possible to reliably detect scraping of a public address nor to salvage that address if it ever happens -- being able to do both under one backwards-compatible system allows you to reliably whitelist and blacklist without the risk of false positives, and isolate detailed analysis to the greylisted addresses without the necessity of hard-bouncing (500 error-ing) failures.
I think that's the best explanation I can give without a boring amount of technical detail. Hopefully that makes some amount of sense.
posted by spiderwire at 8:23 PM on December 6, 2008
It is pretty simple, it's just obviously a little counterintuitive, because the implementation is not that different from vanilla disposable addresses. The graphic was intended as a how-to, not a why-this, and I'm obviously not explaining the distinction very well (if you know how to set up a Lisp REPL I could just send the code...)
What now? I can't drop all mail to mefi.bonaldi, because that's what some nice people use to get in touch with me. I don't want to only allow people who've replied to me, because I didn't reply to everyone. I have to filter it. So now the problem has been pushed back a level -- I've got an email address that spam is arriving at. It's not my "real" address, but it might as well be.
This is a good point, and I'll admit that this is no cure-all solution, but it allows you to create a greylist that's 100% reliable from the receiving end, which is an important first step that isn't possible under other schemes because of the scraping problem.
So, yes, the logical question then (which efflugas pointed out above) is: what if the address gets compromised? The initial answer is that once an address is greylisted, you do a one-time hash check and reply with a newly generated address to that sender. If the new address gets greylisted, you may have to increase the hash difficulty by an order of magnitude or so.
So, next, how is that different than systems that already exist? Two reasons: (1) mefi.bonaldi can be isolated as the point-of-compromise (which isn't feasible with the suffix method), but (2) you can still post the address without having to generate a new address (which for business cards prevents the disposable-address method).
Generally it's not possible to reliably detect scraping of a public address nor to salvage that address if it ever happens -- being able to do both under one backwards-compatible system allows you to reliably whitelist and blacklist without the risk of false positives, and isolate detailed analysis to the greylisted addresses without the necessity of hard-bouncing (500 error-ing) failures.
I think that's the best explanation I can give without a boring amount of technical detail. Hopefully that makes some amount of sense.
posted by spiderwire at 8:23 PM on December 6, 2008
« Older This is a thing that's happening very fast, in... | Synthetic CDO's: tsunami event when major... Newer »
This thread has been archived and is closed to new comments
posted by Glibpaxman at 7:45 PM on December 1, 2008 [2 favorites]