All this drama spawns a few interesting questions:
* How should Open Source Projects deal with internal drama?
* Should people who have a history of working with governments be shunned by the infosec community?
While I have no input on the first one, I can't help but notice that the connection between tor and the US government is already so strong (funding, the lead developer "arma" being a former NSA intern) that "undermining tor" would be pointless.
If "the infosec community" is a small subculture that has chosen to co-opt the term "infosec" to describe its own idiosyncratic politics, sure. The remaining plurality of software and network security people who have worked at some point with governments can, I suppose, pick a new name for themselves. I never did like "infosec community" as a descriptor.
What gets me is once we know who the ex-government people are, they sure as hell become huge targets for people still working for the gov.
I wonder how many times arma has been approached.
I hate saying it, but I do feel like ex-gov is fruit of the poisonous tree.. at the same time I think these people specifically would understand the need for tor.
The ridiculous thing about this, if accurate, is that Tor was (is?) primarily funded by an organization connected to State and CIA propaganda efforts. Most of them receive money from US governmemt in sone way. CIA itself uses Tor for same reason Navy created it. While FBI and NSA hate it, the CIA and State love it as a tool for protecting foreign operators or dissenters. Makes it funny they're so worried about bringing CIA in.
Anyway, the right way go do security against nation-states is creating deliverables and processes that are verified by mutually-suspicious parties. As in, with high-assurance security, you assume the people are largely malicious while focusing on vetting thd product and process throughout lifecycle. Not sure what this CIA person's role is supposed to be but it's bad INFOSEC and OPSEC if he can unilaterally do lots of damage. Shouldn't be possible.
Far as image, just like my subversion-resistant build scheme, having helpful CIA rep onboard as a check American government can trust is beneficial at least for review and testing. Have one from each major government or institution using the service acting as checks against inserted or ignored subversions. Plus non-government groups of course. That one CIA guy can compromise either service or image again makes process or trust assessment look weak.
I say let them come onboard but with non-critical access and any actions reviewed. Even if failure, it would teach important lessons.
> Makes it funny they're so worried about bringing CIA in.
Except for the fact that the USG actually buys into the concept of NOBUS, as evidenced not only in the classification system - but also foreign policy (the proliferation of AA and AT weapons comes to mind). So the USG's use of TOR provides me with zero confidence that they wouldn't actively weaken it. That said, I agree on the issue of trust - secure software shouldn't need any. They need to decide between two very distinct paths: accept the insecurity and try to control it socially (no CIA guys), or mathematically demonstrate infallibility. Because one is so hard, and the inevitable failure of the other can be ignored for now - I'm guessing that we'll see no push for formal verification :)
Was looking forward to see what you'd say here. :)
"Except for the fact that the USG actually buys into the concept of NOBUS"
This is true. I considered it given a subverted, but otherwise working, Tor network would be a win-win if CIA was subjected to pressure or wanted to de-anonymize opponents. Yet, the Tor project themselves answer this one: it's vulnerable to a global, passive adversary. NSA has painstakingly built partnerships with all kinds of countries that collectively do a giant SIGINT operation. Most of them probably don't like Tor. CIA or partners can get info from NSA on these things. So, CIA can already defeat Tor for some fraction of users since their partner is outside its probability of success. On top of whatever CIA might pull.
"accept the insecurity and try to control it socially (no CIA guys), or mathematically demonstrate infallibility. "
Well, remember that there's always the path of just clearly specifying the functionality plus implementing it in the safest way possible. We used to call this medium assurance. OpenBSD is the code-only version of that. Praxis w/ Ada/SPARK is the spec + code version. Only around 30-50% premium in labor/cost added doing these things despite immunity to all kinds of shit. They aren't going to do it, though. They never do. Leading to...
"I'm guessing that we'll see no push for formal verification :)"
...no push for that or even system-oriented languages and techniques that make the service immune to memory- or interface-level attacks that make up 80-90% of vulnerabilities. Not even that.
> Yet, the Tor project themselves answer this one: it's vulnerable to a global, passive adversary.
Vulnerable to traffic analysis, I'm sure certain organizations wouldn't mind seeing that vulnerability include cleartext.
> ...plus implementing it in the safest way possible.
I've never seen an Underhanded Ada Contest, but I'm pretty confident that a bad actor could still introduce vulnerabilities that would pass a reasonable code review and be deniable. It would be an improvement for sure, but you'd still have a trust requirement. I think a good half measure would be: fully spec'd pure functions don't need human code review - just feed patches to the theorem prover and regression tester, all the trusted human labor can then focus on things that touch global state. At the risk of incentivizing spaghetti code, you'd incentivize the production of code that really lends itself to static analysis.
> ...memory- or interface-level attacks that make up 80-90% of vulnerabilities.
I look forward to us getting past the memory vulnerabilities, but the next battle will be one hell of a fight - timing attacks. Thought getting people to trade C performance was tough? Try getting them to intentionally delay all comparison operations... in the entire software stack :)
"Vulnerable to traffic analysis, I'm sure certain organizations wouldn't mind seeing that vulnerability include cleartext."
Well, certainly. Depends on what this guy's role is supposed to be in the organization. One can always relegate the riskier people to stuff that can't harm them much. In any case, NSA can already do what you mentioned given leaks mention active targeting. Catalog includes regular malware, 0-days on stuff, and implants. Tor is the LTD they aim at themselves with optional LGB's following from QUANTUM and such. So, it would be a matter of already-vulnerable people or services getting more so.
"I've never seen an Underhanded Ada Contest, but I'm pretty confident that a bad actor could still introduce vulnerabilities that would pass a reasonable code review and be deniable"
Well, sure. Just remember, though, that what you're saying already applies to the Tor project. Any of the contributors, maintainers, relay hosts, and so on might be malicious. That's why A1 class called for protection throughout whole lifecycle which my framework below expanded on. SAP security guides showed most areas requiring protection. Examples below:
Now, from here, we have to ask what can be done to mitigate potential exploits. Well, we know the protocol itself is subject to strong, peer review by parties more than willing to publish problems and organization that corrects them. The main problems occur in crypto libraries, protocol engines, interfaces, type checks, memory errors, parsing, handling time, and error handling. A type-safe, memory-safe, low-level language along lines of Ada/SPARK, Go, Rust, or Modula-3 plus specific libraries and guidance on aforementioned can knock out vast majority of the risk. Well, that along with parser/protocol generators already available in academia with hand-checked code and design-by-contract to encode constraints. OpenBSD people probably do considerably more work on their code than what would be necessary to take care of this in safer language while focusing on areas most likely to be hit.
So, I think we can get plenty mileage without full, formal verification. There will be flaws just as there are in protocol itself. Yet, it will work most of the time with people finding problems so long as plenty are on it motivated to do so.
" I think a good half measure would be: fully spec'd pure functions don't need human code review - just feed patches to the theorem prover and regression tester, all the trusted human labor can then focus on things that touch global state."
They still need review. You have to specify what you're going to do, what security properties it maintains, how it maintains that, and the implementation correspondence. Usually also show compiler didn't screw it up. That's tricky. Pure functions are fine but covert channel analysis means it's going to be an imperative language for final implementation. Old model was basically decomposing functional components into state machines representing every permissible state. Can check by eye that they either should work securely or fail-safe. Still keeping my eye out for CompSci tech that can derive imperative from simple, functional languages in human-readable form.
"Thought getting people to trade C performance was tough? Try getting them to intentionally delay all comparison operations... in the entire software stack :)"
Oh my god, I've been there. Mainstream INFOSEC totally ignored that problem saying it was unnecessary until recently rediscovering it under "side channel" label. Running wild with it. I called out Freenet on Schneier's blog as probably having plenty du...
> In any case, NSA can already do what you mentioned given leaks mention active targeting.
I see it as a massive difference: dragnet scope, loss of forward security due to precomputed magic numbers, etc. While the threat is hypothetical, unlike traffic analysis and active targeting, the consequences elevate it to a point where it deserves its own consideration.
> ...on aforementioned can knock out vast majority of the risk.
I'm usually a one bite at a time sort of guy when it comes to eating elephants, but I think a language switch should bring a little bit more benefit - especially considering the unsolved compiler optimizing security away problem (outside of language subsets enforced by self discipline). It is dangerous, and it has led to the slow death of many projects, but I'd recommend some time spent on custom tooling. The furthest I'd suggest would be language extensions, likely implemented as external llvm modules, nothing crazy - retaining array size metadata in function arguments instead of throwing the information away. ACSL for contract specification would be nice, or at least fix frama-c so that it isn't so awful.
> They still need review. You have to specify...
I was speaking of implementation changes to already specd functions, but after further consideration I want to double down. Any changes to code further down stream of well specified functions shouldn't need code review. That wouldn't be a very good way to go about it, one massive function specification instead of a composition, but it would still be secure.
> ...covert channel analysis means it's going to be an imperative language for final implementation.
Yeah I didn't mean a functional language like haskell, as I've yet to write any production quality code in it after several years of trying... I was thinking more along the lines of the function __attribute__((const)). This might make my no review suggestion not work, but that custom tooling might be able to help with detecting information leaks through variable loop iteration counts. Lots of ways to tackle the problem.
> Mainstream INFOSEC totally ignored that problem...
I can sympathize, I recognize it as a problem - and I try not to think about it because it makes me very sad.
"the consequences elevate it to a point where it deserves its own consideration."
Well, it does but maybe not here. Let's remember the situation. The consideration is only applying because a person openly said they're ex-CIA. So, we apply these considerations when people say that. Result? Instead of risk going away, they just stop saying they're ex-CIA. Maybe start talking about privacy, crypto, Anonymous, blockchains, and so on. Infiltration 101 applied to Tor project. Filtering out anyone claiming to be ex-government doesn't filter out ex-government except for those specific cases. This level of consideration, if infiltration risk is high, has to be all or nothing.
"The furthest I'd suggest would be language extensions, likely implemented as external llvm modules, nothing crazy"
It's a reasonable proposition. I considered something like Cyclone, a security-aware scheme for managing heap, and with JIF-style labels for information flow. Might knock out a lot of problems while keeping code mostly the same and able for C programmers to handle.
" Any changes to code further down stream of well specified functions shouldn't need code review. "
This is ambiguous. Are you saying that, with how they all interface, that any changes to lower-level functions should preserve interface invariants enough that higher-level stuff shouldn't have to be re-reviewed? If so, that would be reasonable. If not, please elaborate.
It was my understanding that he first misrepresented himself as a State Department employee, then for some reason came clean several years later. I think filtering that sort of behavior out has a lot more pros than cons.
> I considered something like Cyclone...
A lot of that can be done with compiler annotations, the disadvantage of course being that it isn't default behavior... which is consistent with the rest of the C universe - things are no more secure than you design them to be.
> If not, please elaborate.
That is what I'd say if I was an OO programmer, yes. But I'll elaborate anyway because... have you ever just been in the mood to write gibberish C?
/* New unreviewed code from untrusted source */
__attribute__((const)) /* More pure than "pure" */
static int newfunc(char* src, int len){ return src ? 0 : len; }
/* Imagine an incredibly comprehensive spec for this public function, right here */
__attribute__((nonnull(1,2))) /* No Cyclone needed for null safety here */
int pubfunc(char* a, char* b) {
/* ... */
if (a[0] == '4')
return newfunc(b, 4); /* Untrusted function covered under that amazing spec you imagined */
/* ... */
}
> a tool for protecting foreign operators or dissenters.
More like an edge beacon ("Hi there! I'm using tor, fyi!!"). Based on a false narrative of security to the clueless dissidents, they get their desired result (info/propaganda dissemination) and no doubt later can horse trade with their sister spooks when burning the no-longer-useful-idiots.
Oh I agree. My own recommendations are use of proxies tgat blend into crowd. One old trick was embedding stuff in HTTPS connections that looked like innocent web sites. WiFi w/ cantennas, burst radio, courier networks, and so on are also effective. Whatever it is has to blend into crowd.
Tor stands out too much. Also obscures what you're doing, though. So, a double edge sword whose benefit depends on situation. Gotta think catefully. I predicted NSA would auto-target Tor users for further surveillance given uptake demographics. We saw that in the leaks. Double-edged sword. ;)
I honestly don't get why this is coming up now. TOR's funding never was a secret. Serious infosec people didn't need Snowden to be suspicious about the actual anonymity provided. If one was not concerned back then, what does an ex-CIA agent (or even not-so-ex CIA agent) in the tor project change?
Sort of. The Pando article they reference, which showed me more about them than the author, points out that they try to promote the funding as "independent" source rather than U.S. government-backed groups made by or tight with CIA. All the press around the situation would make you think it's a group for the people, by the people, and so on with some historical military connection. Whereas, the people aren't funding most of Tor: "The Man" Tor appears to oppose is. Even in this conversation, they're worried about that image situation and how to minimize exposure that one CIA person might work in Tor despite the fact that such types are funding it it. If it's so transparent, you wouldn't have so much work on that.
Who knows why it's coming up & it's not secret as you said. Yet, Tor pages I've read certainly weren't describing themselves as a tool of U.S. intelligence agencies funded by their fronts. They seem to work at avoiding that in favor of some image independent that U.S. intelligence just happens to also like and use. Which is inaccurate.
I'm curious. If we take away all U.S. govt connected funding, then how much is left for the developers and how many will that be? That should be a hint at level of independence.
Your point doesn't contradict mine even if made-up 51% number was true. Selective as usual focusing on its start and fact there's USG funding. Yet, a person looking on site at "About Tor," "Core team," and "Sponsors" doesn't get a clear indicator that the vast majority of funds so far as come from groups CIA created to wage propaganda wars and act for U.S. foreign policy. That fronts allegedly separated from despite them doing basically the same jobs today funded by U.S. government doesn't reduce that concern. Readers might think instead it's a mostly for-the-people organization whose funding is spread out among many groups instead of the kind its libertarian proponents would seem to fight rather than work for. Then, we have chat logs from a group funded by CIA & affiliates worried about their image if one CIA person is in the project.
Hence, "sort of." I'll change my statement to their source of support being clear when they state such things clearly on their web site and stop the kind of smears I saw in response to the Pando article. I mean, here's people taking money from CIA and/or affiliates openly speculating that someone saying so or implying it means something must be... working for CIA, a fascist, or something in a smear job. Repeat, people paid by vicious, authoritarian regimes they claim to fight accusing someone of evil or connections to such regimes for reporting their source of funding. Unreal...
I'll be interested to see how long popular support for Tor lasts if it's marketed as a former Navy tool currently supported by CIA and State department groups. The reality probably will change the perception of it and when/where to use it a lot. I still support the project as realists like me know it's a double-edge sword they need to work but might try to compromise in limited ways. Hence, me pushing strong security engineering to be applied to it.
I got it. Stepped on it in my counter. The response to Pando piece and these logs don't fit that joke or its implication at all. Plus a strawman given Tor is meant for laypeople mostly. Let's restate the Tor sponsor page differently to show what they're doing:
"A US project about helping people enable anonymity plus fight oppression of authoritive regimes, from China to US, that's mostly paid for by CIA and other US propaganda organizations along with small contributions from these other organizations."
Juxtapose that against the IRC logs for the real joke. They fear what will happen if seen as affiliated with even one CIA person. Only imagine what their image would be like if lay users, not just security experts, saw their funding spread and sourcing. Probably why they present the sponsor page and other parts they way they do. Obscuring source to maximize uptake.
Truth is that they're a tool that can be wielded for good or bad. That it's mostly US govt villians funding it is acceptable to me for greater good so long as legit software. It is so Im fine. That's realistic. This hide the CIA guy crap doesnt fit with reality if they push a genuine one.
Tor is supported by intelligence agencies because of the value it brings to them. For someone undercover, Tor is a great way to keep in touch, and if you're confronted you have a plausible explanation of wanting to buy LSD or watch kiddie porn or whatever most people use Tor for.
Didnt say DARPA was an intelligence front although it funds things for use by DOD mainly. NRL funded Tor for use by US military. State and CIA have numerous front organizations whose goal is to push propaganda into foreign countries to destabilize regimes. I see a notorious one on the page you listed: Radio Free Asia. Look up its backstory. They could've just wrote CIA-funded but tgen it was put under another propaganda organization claiming no CIA ties.
Given those propaganda groups and CIA affiliates are majority of its funding, it's strange to worry about a CIA person involved for project's "image." It's CIA & State funded for their use!
Far as supporting them, I totally agree and mentioned it in my main comment. Nothing wrong with taking money to do things of mutual benefit/interest.
Agreed on one hand. But on the other hand, these are literally (as noted in the log) people who have physical security concerns travelling to a large part of the world if their identities are public.
Only paranoia if your laptop doesn't get seized at customs every time you fly, etc etc.
People are likely to act much differently when facing an "existential threat". Certainly for the guy worried this could get his family killed, but even just for people who've invested years of work into the Tor project, and think this could lead to it's downfall. For something like Tor, userbase has a particularly key role in maintaining the project.
This is likely something to do with the instinctual "fight or flight" response. I think you can see people who chose each in this chat log.
I like to think that most people don't expect something like TOR to protect against a determined government. That doesn't make TOR useless, since I suspect that most people are not trying to be anonymous from intelligence agencies, only law enforcement agencies.
Are you talking about the current FBI case? That was an exploit in the Tor Browser Bundle (could force the browser to make a request using the non-tor network), not in the Tor Network itself.
You mean the Flash based NIT exploit, as part of Metasploit? Flash which is by default off in TBB and has really nothing to do with tor, is actively discouraged by the tor project, and is in strong decline world over?
Or are the talking about the Carnegie Mellon attack that modifying Tor protocol headers? If so, is that fixed security bug enough to judge tor as failure and only usable for research? Even seatbelt, which has a fairly simple concept, had initial issues and are still being improved.
On the topic of the Carnegie Mellon attack, the tor project both addressed the protocol header bug and changed their security practices. Strange activity in the tor network has in the past been deemed safe until proven harmful, but as a result of having an research university doing attacks on users of the network, that practice has been reversed and strange activity is now deemed harmful until proven safe.
Like most research projects that want to affect humans, eventually Tor moves to human trials. Proper trials require not just cypher punks, but actual people hiding from repressive governments.
The Tor folks I've met have always been careful to say that Tor is not designed to work well against a global passive adversary, but it might be worth something against a local adversary.
Why are we letting USG people be involved with anything? Anyone with a current or former association with the military-industrial complex should be blacklisted. These people are nothing but trouble; they are ideologically untrustworthy and very likely beholden by both carrots and sticks to government interests. They're unfit to be involved in any project but especially those with security implications to the average person.
For one: because much of what we know of the surveillance capabilities of state actors and the ways these capabilities are being used, we owe to whistleblowers like Edward Snowden, Chelsea Manning, and Thomas Drake.
Don't want to drag up the whole Jacob Applebaum thing again, but just the way he talks in these logs makes me wonder how anyone could tolerate working with someone who keeps saying things like "I did X, I did Y".
It's surprising that it seems like only Isis really stood up to his line of questioning while the rest kind of fell silent.
At one point they say that the CIA would do and say anything to keep an agent's cover. If so, then why would they send an agent in who's openly admitting to being an agent?
Correct, the title is "Officer" of the "National Clandestine Service", a part of the CIA. Source, I worked with some spooks in Iraq when I was US Army Military Intel (UAV was then changed to Aviation after I got out).
After reading this, I'm pretty sure I understand why Appelbaum is getting bombarded Assange-style with rape/harassment allegations: He single-handedly acted as the voice of reason in this conversation.
> ioerror: I shut down the city of san francisco to stop the war
> ioerror: Once, I was deported from Lebanon for being jewish, which was because htey said i was a spy for israel (false)
> ioerror: If we have a CIA person working with Tor, I won't get out of that next time, I fear
Is there a breakdown somewhere of who these individuals are/what their relationship to the project is? I find that more context I'm missing might help me understand.
I can't quite connect the dots...how is the involvement of the ex-CIA guy putting the family of one of the people in the logs in (more) danger? It's already CIA funded so any government that wants to torture people for using Tor can already legitimize that practice (but tbh why would they even bother) since they are "using CIA-software" or whatever reason you want to give.
I feel like I'm missing a logical step here.
I do think ex-spies should not be involved in the project and the insistence of DaveC1 is really odd (as is joining before getting clearance to say he was CIA...why not get that first then ask if he can join). Why isn't he coming to the conclusion that it is probably a bad idea and he can get involved in other ways.
Do we know who leaked this, is it more likely to be someone on the pro or contra ex-CIA-involvement side?
Logically it makes no sense for say mrphs to leak this, right?
Apparently TOR's reputation can be utterly destroyed and result in loss of life by something as simple as a person trying to join the team. Who knew?
They claim that just by approaching them he did damage, why didn't they think of this before? Just send agents to offer to write blog posts, watch the devs flip out and revoke their keys.
Seriously, if that's all it takes, you have bigger problems.
57 comments
[ 2.3 ms ] story [ 100 ms ] threadhttp://hastebin.com/ecuwegiven.xml
* How should Open Source Projects deal with internal drama?
* Should people who have a history of working with governments be shunned by the infosec community?
While I have no input on the first one, I can't help but notice that the connection between tor and the US government is already so strong (funding, the lead developer "arma" being a former NSA intern) that "undermining tor" would be pointless.
I wonder how many times arma has been approached.
I hate saying it, but I do feel like ex-gov is fruit of the poisonous tree.. at the same time I think these people specifically would understand the need for tor.
Anyway, the right way go do security against nation-states is creating deliverables and processes that are verified by mutually-suspicious parties. As in, with high-assurance security, you assume the people are largely malicious while focusing on vetting thd product and process throughout lifecycle. Not sure what this CIA person's role is supposed to be but it's bad INFOSEC and OPSEC if he can unilaterally do lots of damage. Shouldn't be possible.
Far as image, just like my subversion-resistant build scheme, having helpful CIA rep onboard as a check American government can trust is beneficial at least for review and testing. Have one from each major government or institution using the service acting as checks against inserted or ignored subversions. Plus non-government groups of course. That one CIA guy can compromise either service or image again makes process or trust assessment look weak.
I say let them come onboard but with non-critical access and any actions reviewed. Even if failure, it would teach important lessons.
Except for the fact that the USG actually buys into the concept of NOBUS, as evidenced not only in the classification system - but also foreign policy (the proliferation of AA and AT weapons comes to mind). So the USG's use of TOR provides me with zero confidence that they wouldn't actively weaken it. That said, I agree on the issue of trust - secure software shouldn't need any. They need to decide between two very distinct paths: accept the insecurity and try to control it socially (no CIA guys), or mathematically demonstrate infallibility. Because one is so hard, and the inevitable failure of the other can be ignored for now - I'm guessing that we'll see no push for formal verification :)
"Except for the fact that the USG actually buys into the concept of NOBUS"
This is true. I considered it given a subverted, but otherwise working, Tor network would be a win-win if CIA was subjected to pressure or wanted to de-anonymize opponents. Yet, the Tor project themselves answer this one: it's vulnerable to a global, passive adversary. NSA has painstakingly built partnerships with all kinds of countries that collectively do a giant SIGINT operation. Most of them probably don't like Tor. CIA or partners can get info from NSA on these things. So, CIA can already defeat Tor for some fraction of users since their partner is outside its probability of success. On top of whatever CIA might pull.
"accept the insecurity and try to control it socially (no CIA guys), or mathematically demonstrate infallibility. "
Well, remember that there's always the path of just clearly specifying the functionality plus implementing it in the safest way possible. We used to call this medium assurance. OpenBSD is the code-only version of that. Praxis w/ Ada/SPARK is the spec + code version. Only around 30-50% premium in labor/cost added doing these things despite immunity to all kinds of shit. They aren't going to do it, though. They never do. Leading to...
"I'm guessing that we'll see no push for formal verification :)"
...no push for that or even system-oriented languages and techniques that make the service immune to memory- or interface-level attacks that make up 80-90% of vulnerabilities. Not even that.
> Yet, the Tor project themselves answer this one: it's vulnerable to a global, passive adversary.
Vulnerable to traffic analysis, I'm sure certain organizations wouldn't mind seeing that vulnerability include cleartext.
> ...plus implementing it in the safest way possible.
I've never seen an Underhanded Ada Contest, but I'm pretty confident that a bad actor could still introduce vulnerabilities that would pass a reasonable code review and be deniable. It would be an improvement for sure, but you'd still have a trust requirement. I think a good half measure would be: fully spec'd pure functions don't need human code review - just feed patches to the theorem prover and regression tester, all the trusted human labor can then focus on things that touch global state. At the risk of incentivizing spaghetti code, you'd incentivize the production of code that really lends itself to static analysis.
> ...memory- or interface-level attacks that make up 80-90% of vulnerabilities.
I look forward to us getting past the memory vulnerabilities, but the next battle will be one hell of a fight - timing attacks. Thought getting people to trade C performance was tough? Try getting them to intentionally delay all comparison operations... in the entire software stack :)
Well, certainly. Depends on what this guy's role is supposed to be in the organization. One can always relegate the riskier people to stuff that can't harm them much. In any case, NSA can already do what you mentioned given leaks mention active targeting. Catalog includes regular malware, 0-days on stuff, and implants. Tor is the LTD they aim at themselves with optional LGB's following from QUANTUM and such. So, it would be a matter of already-vulnerable people or services getting more so.
"I've never seen an Underhanded Ada Contest, but I'm pretty confident that a bad actor could still introduce vulnerabilities that would pass a reasonable code review and be deniable"
Well, sure. Just remember, though, that what you're saying already applies to the Tor project. Any of the contributors, maintainers, relay hosts, and so on might be malicious. That's why A1 class called for protection throughout whole lifecycle which my framework below expanded on. SAP security guides showed most areas requiring protection. Examples below:
http://pastebin.com/y3PufJ0V
http://www.dss.mil/documents/odaa/nispom2006-5220.pdf
Now, from here, we have to ask what can be done to mitigate potential exploits. Well, we know the protocol itself is subject to strong, peer review by parties more than willing to publish problems and organization that corrects them. The main problems occur in crypto libraries, protocol engines, interfaces, type checks, memory errors, parsing, handling time, and error handling. A type-safe, memory-safe, low-level language along lines of Ada/SPARK, Go, Rust, or Modula-3 plus specific libraries and guidance on aforementioned can knock out vast majority of the risk. Well, that along with parser/protocol generators already available in academia with hand-checked code and design-by-contract to encode constraints. OpenBSD people probably do considerably more work on their code than what would be necessary to take care of this in safer language while focusing on areas most likely to be hit.
So, I think we can get plenty mileage without full, formal verification. There will be flaws just as there are in protocol itself. Yet, it will work most of the time with people finding problems so long as plenty are on it motivated to do so.
" I think a good half measure would be: fully spec'd pure functions don't need human code review - just feed patches to the theorem prover and regression tester, all the trusted human labor can then focus on things that touch global state."
They still need review. You have to specify what you're going to do, what security properties it maintains, how it maintains that, and the implementation correspondence. Usually also show compiler didn't screw it up. That's tricky. Pure functions are fine but covert channel analysis means it's going to be an imperative language for final implementation. Old model was basically decomposing functional components into state machines representing every permissible state. Can check by eye that they either should work securely or fail-safe. Still keeping my eye out for CompSci tech that can derive imperative from simple, functional languages in human-readable form.
"Thought getting people to trade C performance was tough? Try getting them to intentionally delay all comparison operations... in the entire software stack :)"
Oh my god, I've been there. Mainstream INFOSEC totally ignored that problem saying it was unnecessary until recently rediscovering it under "side channel" label. Running wild with it. I called out Freenet on Schneier's blog as probably having plenty du...
I see it as a massive difference: dragnet scope, loss of forward security due to precomputed magic numbers, etc. While the threat is hypothetical, unlike traffic analysis and active targeting, the consequences elevate it to a point where it deserves its own consideration.
> ...on aforementioned can knock out vast majority of the risk.
I'm usually a one bite at a time sort of guy when it comes to eating elephants, but I think a language switch should bring a little bit more benefit - especially considering the unsolved compiler optimizing security away problem (outside of language subsets enforced by self discipline). It is dangerous, and it has led to the slow death of many projects, but I'd recommend some time spent on custom tooling. The furthest I'd suggest would be language extensions, likely implemented as external llvm modules, nothing crazy - retaining array size metadata in function arguments instead of throwing the information away. ACSL for contract specification would be nice, or at least fix frama-c so that it isn't so awful.
> They still need review. You have to specify...
I was speaking of implementation changes to already specd functions, but after further consideration I want to double down. Any changes to code further down stream of well specified functions shouldn't need code review. That wouldn't be a very good way to go about it, one massive function specification instead of a composition, but it would still be secure.
> ...covert channel analysis means it's going to be an imperative language for final implementation.
Yeah I didn't mean a functional language like haskell, as I've yet to write any production quality code in it after several years of trying... I was thinking more along the lines of the function __attribute__((const)). This might make my no review suggestion not work, but that custom tooling might be able to help with detecting information leaks through variable loop iteration counts. Lots of ways to tackle the problem.
> Mainstream INFOSEC totally ignored that problem...
I can sympathize, I recognize it as a problem - and I try not to think about it because it makes me very sad.
Well, it does but maybe not here. Let's remember the situation. The consideration is only applying because a person openly said they're ex-CIA. So, we apply these considerations when people say that. Result? Instead of risk going away, they just stop saying they're ex-CIA. Maybe start talking about privacy, crypto, Anonymous, blockchains, and so on. Infiltration 101 applied to Tor project. Filtering out anyone claiming to be ex-government doesn't filter out ex-government except for those specific cases. This level of consideration, if infiltration risk is high, has to be all or nothing.
"The furthest I'd suggest would be language extensions, likely implemented as external llvm modules, nothing crazy"
It's a reasonable proposition. I considered something like Cyclone, a security-aware scheme for managing heap, and with JIF-style labels for information flow. Might knock out a lot of problems while keeping code mostly the same and able for C programmers to handle.
https://en.wikipedia.org/wiki/Cyclone_(programming_language)
https://www.cs.cornell.edu/jif/
" Any changes to code further down stream of well specified functions shouldn't need code review. "
This is ambiguous. Are you saying that, with how they all interface, that any changes to lower-level functions should preserve interface invariants enough that higher-level stuff shouldn't have to be re-reviewed? If so, that would be reasonable. If not, please elaborate.
It was my understanding that he first misrepresented himself as a State Department employee, then for some reason came clean several years later. I think filtering that sort of behavior out has a lot more pros than cons.
> I considered something like Cyclone...
A lot of that can be done with compiler annotations, the disadvantage of course being that it isn't default behavior... which is consistent with the rest of the C universe - things are no more secure than you design them to be.
> If not, please elaborate.
That is what I'd say if I was an OO programmer, yes. But I'll elaborate anyway because... have you ever just been in the mood to write gibberish C?
More like an edge beacon ("Hi there! I'm using tor, fyi!!"). Based on a false narrative of security to the clueless dissidents, they get their desired result (info/propaganda dissemination) and no doubt later can horse trade with their sister spooks when burning the no-longer-useful-idiots.
Tor stands out too much. Also obscures what you're doing, though. So, a double edge sword whose benefit depends on situation. Gotta think catefully. I predicted NSA would auto-target Tor users for further surveillance given uptake demographics. We saw that in the leaks. Double-edged sword. ;)
Sort of. The Pando article they reference, which showed me more about them than the author, points out that they try to promote the funding as "independent" source rather than U.S. government-backed groups made by or tight with CIA. All the press around the situation would make you think it's a group for the people, by the people, and so on with some historical military connection. Whereas, the people aren't funding most of Tor: "The Man" Tor appears to oppose is. Even in this conversation, they're worried about that image situation and how to minimize exposure that one CIA person might work in Tor despite the fact that such types are funding it it. If it's so transparent, you wouldn't have so much work on that.
Who knows why it's coming up & it's not secret as you said. Yet, Tor pages I've read certainly weren't describing themselves as a tool of U.S. intelligence agencies funded by their fronts. They seem to work at avoiding that in favor of some image independent that U.S. intelligence just happens to also like and use. Which is inaccurate.
I'm curious. If we take away all U.S. govt connected funding, then how much is left for the developers and how many will that be? That should be a hint at level of independence.
Hence, "sort of." I'll change my statement to their source of support being clear when they state such things clearly on their web site and stop the kind of smears I saw in response to the Pando article. I mean, here's people taking money from CIA and/or affiliates openly speculating that someone saying so or implying it means something must be... working for CIA, a fascist, or something in a smear job. Repeat, people paid by vicious, authoritarian regimes they claim to fight accusing someone of evil or connections to such regimes for reporting their source of funding. Unreal...
I'll be interested to see how long popular support for Tor lasts if it's marketed as a former Navy tool currently supported by CIA and State department groups. The reality probably will change the perception of it and when/where to use it a lot. I still support the project as realists like me know it's a double-edge sword they need to work but might try to compromise in limited ways. Hence, me pushing strong security engineering to be applied to it.
"A US project about helping people enable anonymity plus fight oppression of authoritive regimes, from China to US, that's mostly paid for by CIA and other US propaganda organizations along with small contributions from these other organizations."
Juxtapose that against the IRC logs for the real joke. They fear what will happen if seen as affiliated with even one CIA person. Only imagine what their image would be like if lay users, not just security experts, saw their funding spread and sourcing. Probably why they present the sponsor page and other parts they way they do. Obscuring source to maximize uptake.
Truth is that they're a tool that can be wielded for good or bad. That it's mostly US govt villians funding it is acceptable to me for greater good so long as legit software. It is so Im fine. That's realistic. This hide the CIA guy crap doesnt fit with reality if they push a genuine one.
I'm not sure DARPA or Naval Research Laboratory are really intelligence agency fronts.
https://www.torproject.org/about/sponsors.html.en
Tor is supported by intelligence agencies because of the value it brings to them. For someone undercover, Tor is a great way to keep in touch, and if you're confronted you have a plausible explanation of wanting to buy LSD or watch kiddie porn or whatever most people use Tor for.
Given those propaganda groups and CIA affiliates are majority of its funding, it's strange to worry about a CIA person involved for project's "image." It's CIA & State funded for their use!
Far as supporting them, I totally agree and mentioned it in my main comment. Nothing wrong with taking money to do things of mutual benefit/interest.
Only paranoia if your laptop doesn't get seized at customs every time you fly, etc etc.
This is likely something to do with the instinctual "fight or flight" response. I think you can see people who chose each in this chat log.
Tor is an important research project. But that's what it is.
Or are the talking about the Carnegie Mellon attack that modifying Tor protocol headers? If so, is that fixed security bug enough to judge tor as failure and only usable for research? Even seatbelt, which has a fairly simple concept, had initial issues and are still being improved.
On the topic of the Carnegie Mellon attack, the tor project both addressed the protocol header bug and changed their security practices. Strange activity in the tor network has in the past been deemed safe until proven harmful, but as a result of having an research university doing attacks on users of the network, that practice has been reversed and strange activity is now deemed harmful until proven safe.
The Tor folks I've met have always been careful to say that Tor is not designed to work well against a global passive adversary, but it might be worth something against a local adversary.
Correction: What you have been told.
It's surprising that it seems like only Isis really stood up to his line of questioning while the rest kind of fell silent.
> ioerror: Once, I was deported from Lebanon for being jewish, which was because htey said i was a spy for israel (false) > ioerror: If we have a CIA person working with Tor, I won't get out of that next time, I fear
I sincirely hope you are being ironic.
Do you have evidence that he wasn't deported for being jewish, and that having CIA ties to Tor wouldn't cause him injury?
Do you have evidence that he didn't hack SF infrastructure as hacktivism?
I do think ex-spies should not be involved in the project and the insistence of DaveC1 is really odd (as is joining before getting clearance to say he was CIA...why not get that first then ask if he can join). Why isn't he coming to the conclusion that it is probably a bad idea and he can get involved in other ways.
Do we know who leaked this, is it more likely to be someone on the pro or contra ex-CIA-involvement side? Logically it makes no sense for say mrphs to leak this, right?
asn: George Kadianakis
atagar: Damian Johnson
athena: Andrea Shepard
DaveC1: David Chasteen
gamambel: Moritz Bartl
helix: Erinn Clark
ioerror: Jacob Appelbaum
infinity0: Ximin Luo
isis: Isis Agora Lovecruft
Julius23: Julius Mittenzwei
Lunar^: Lunar
mikeperry: Mike Perry
mrphs: Nima Fatemi
puffin: Karen Reilly
Phoul: Colin Childs
qbi: Jens Kubieziel
Runa: Runa Sandvik
sekritarma: Roger Dingledine
sysrqb: Matt Finkel
weasel: Peter Palfrader
yawning: Yawning
Apparently TOR's reputation can be utterly destroyed and result in loss of life by something as simple as a person trying to join the team. Who knew?
They claim that just by approaching them he did damage, why didn't they think of this before? Just send agents to offer to write blog posts, watch the devs flip out and revoke their keys.
Seriously, if that's all it takes, you have bigger problems.