[std disclaimer: i am not speaking on behalf of the Tor project nor any developers or employees of it. i know Roger likes to avoid even the appearance of such relationships with rogue third parties so i'll void such notions up front *g* ]
--- Dan Egerstad published some more details about the source of his embassy password list: http://www.derangedsecurity.com/time-to-reveal%e2%80%a6/ anonymouse pointed this out back on sep. 1st and also seems to imply that some kind of active MITM against SSL/TLS was used: http://blog.wired.com/27bstroke6/2007/08/embassy-e-mail-.html#comment-81318789 (ok, mea culpa. if i'm going to use a pseudonym to post i should really use Tor to do it *grin*. the reason i claimed he was also performing an active MITM is that i've seen this done from at least a few exit nodes against encrypted mail protocols with forged certificate CN and other elements. i assumed at the time the list was published it was Dan running these exits, but it may well be others and he was solely sniffing plain-text credentials. perhaps he will clarify with a bit more detail :) some additional comments at end of this msg [0]. Dan correctly states in bold that "ToR (sic) isn't the problem, just use it for what it's made for.". this highlights the complexities and subtleties of implementing Tor properly at both an application layer and network layer; the details are complicated and carelessness will get you into trouble, sometimes a lot of it... (more to come on this subject later this month) --- one thing i don't agree with is the concern about some of the node operators. "Criminals, hackers and Governments are running nodes, why?" there is really no reason you should trust an apparently honest looking node more than one hosted by a government or a hacker group. the strength of Tor's privacy comes from the decentralized nature of node contributors; restricting the ability to contribute only diminishes the scope of this decentralization, thus weakening your privacy. (not to mention suspicions fabricated against other nodes in such an environment are useful methods to further weaken it against a determined adversary. recall the damage of just "some guy in IRC" as Nick outlined so succinctly :) expecting privacy of your traffic exiting a given node is an entirely different matter however, and hopefully this incident and the others like it that have occurred before (and no doubt will occur again) show that private information (authentication credentials, personally identifying details, etc) must never be sent in plain-text, no exceptions. public wireless networks are in a very similar situation and the majority of users there are just as careless. this will be a painful lesson, again and again, for those who continue to ignore the risks. --- one last interesting tidbit posted on the 6th: """ Our site got shut down and we stood there not knowing why, couldn't get any information from anyone. You aren't going to like the answer we just dug up. * American law enforcement officials requested DEranged Security to be taken down * Woho, we pissed the US of! But why? Millions of people have already read the story and tens of thousands have those passwords. """ this is indeed interesting as Dan stated that the list of passwords, even those not disclosed, did not involve any US Gov embassies or state side facilities. i don't remember where this comment was made, perhaps in the comments now lost. Dan, if you're reading this, please correct me as needed :) best regards, 0. more tangential commentary 0.a. the active MITM fun: i won't say how exactly i was sure Tor was involved in the password disclosures, but suffice it to say that just the destinations themselves are indicative to someone paying attention, even without watching exit traffic. (and maybe origins too :) as for the SSL/TLS MITM, i've seen this from some exits, and this is a well known issue. (even at defcon 13 one of the feds "spotted" was exposed because his blackberry or other email client was not handling forged certificates correctly and failed back to an insecure mode of operation during an active MITM over the wireless there. he was assured by his tech staff that he would be safe because "SSL is being used". oops!) refer to active protocol-version rollback attacks and social engineering tricks used to break SSL/TLS privacy for more details. so Dan, if this wasn't you after all, my apologies. 0.b. node reputation and automated detection of malicious activity: it would be nice to extend torflow and/or snakes on a Tor to perform SSL/TLS certificate checks for various protocols like https, imap-ssl, etc. these tools (and the scanner running on peertech) can detect malicious DNS and web page hi jinx fairly quickly. the remaining protocols, however, are probably not getting looked at by anyone. likewise, such tools once available would be a great fit for the voting / node reputation proposals in the works. marking these nodes as bad exits quickly would help contain the impact of such rogue nodes, even if strong privacy is implemented (since an active SSL/TLS MITM would at least produce a denial of service in a good implementation). 0.c. pissing off 'The Powers That Be' (tm) and "not winning any friends", etc Dan writes: "Directly to the people in the security industry out there to clarify some stuff. There is no exploit to publish, no vendor to contact. This have been told about before with no reactions. Publishing it yet one more time wouldn't have changed crap. Even after publishing a full disclosure list like we did, it was first thought of like BS and done nothing about." you have to cede some credit to this argument, despite the fact that such a method undoubtedly pisses people off in the process. a favorite comparison of security and dentistry is useful to put this into context; it may be uncomfortable and painful, but just like those vegetables mom makes you eat it's good for you in the long run: http://securosis.com/2006/08/30/security-is-like-dentistry/ the proof-of-concept Tor attack this summer is a similar learning experience, even if not the wisest idea to implement. the Tor developers had a patched version ready within HOURS (not days, and certainly not weeks/months like many vendors) after it hit. this highlights the ability of the Tor team to react swiftly and effectively to counter even the most malicious 0day that drops out of no where. (hopefully a very rare event not to been seen again for a long while :) additionally, the nature of the flaw associated with this event was known years ago (though we weren't aware of the research at the time either :), and a question about the security of the Tor control port specifically was posted to this list about a year ago without much consideration. full disclosure can be useful to "encourage" prompt attention to weaknesses that expose clients/users to risks that may otherwise be deemed insignificant, not exploitable, or simply "too much trouble/cost/time/bad-pr to fix". 0.d. on security in general: or, "it's the attackers who determine the effectiveness of security in a system" Peter Gutmann made an excellent point about the nature of assessing the effectiveness of security mechanisms implemented in a given system in a thread about the economics of security: http://www.mail-archive.com/[EMAIL PROTECTED]/msg07940.html """ Florian Weimer <[EMAIL PROTECTED]> writes: >The tests I've seen are mostly worthless because they do not weigh their >results based on the actual threats a typical user faces. ... We already have really, really good metrics for this. It's called the commercial malware industry (blatant ad: see my Defcon talk from last week for examples of exploit sales and pricing models). To find out how secure something is, look at how much exploits for it are selling for on the black market. ... it could be argued that the best real-world metric that we have for security comes from the attackers, not the defenders. (Incidentally, this powerful real-world metric is telling us that the existing browser security model is indistinguishable from placebo :-). """ this is exactly the reason why the janusvm developers are always trying to attack our own software and implementation to probe for weaknesses that may have been overlooked and verify the assumptions of our threat model and capability of attackers against it. this is called "red teaming" and the government and industry have found it indispensable for decades. (we're failing in some other important areas though, particularly documentation to clearly define our threat model and implementation in detailed specifications, as well as sources and processes related to development of it. I promise Roger, this is being worked on, it is just a lot of work and we're very distracted with day to day responsibilities like onerous day jobs, meat-space drama, and the various other time sinks that slow our progress toward this goal. many thanks to those who have donated to janusvm; we appreciate it, it has helped us directly, and will make good on getting it documented and more transparently developed.) 0.FF. "PS: Data and hard drive on each node is destroyed and I forgot everything somehow" lol ! ... i understand this sentiment completely. :P best regards,
