
Internal irc-log of the tor-project reveals debate about hiring an ex-CIA agent - mercuryIntox
http://pastebin.com/WPAmqkW8
======
shruubi
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.

~~~
fapjacks
He is _insufferable_! Exactly the kind of person that makes at least half of
Freenode so awful to participate in.

~~~
cocotino
+1, this is just typical irc behaviour.

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

~~~
nickpsecurity
"TOR's funding never was a secret."

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.

~~~
tptacek
"Sort of"? Tor was a project of the Naval Research Labs. Even 51% of Wikipedia
editors know about its USG funding.

~~~
nickpsecurity
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.

~~~
89284923482
The 51% was a joke, and a good one at that.

~~~
nickpsecurity
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.

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

------
nickpsecurity
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.

~~~
woodman
> 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 :)

~~~
nickpsecurity
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.

~~~
woodman
We certainly share an interest.

> 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 :)

~~~
nickpsecurity
"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:

[http://pastebin.com/y3PufJ0V](http://pastebin.com/y3PufJ0V)

[http://www.dss.mil/documents/odaa/nispom2006-5220.pdf](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 due to use of Java. Meanwhile, old methods of handling
timing channels were reducing precision, fixed-rate, maximum-time, turning off
caches (extra painful on Core i7), masking, and my favorite being
asynchronous, randomized execution. I was going to put the latter in a CPU
then found someone else already did that. Clever. Partitioned caches are
another popular strategy. I just stick with Red/Black model in my designs with
trusted part being dedicated chip with timing mitigation for just needed part.
Still performance hit no matter what.

Anyway, I did a write-up for someone on how to secure a service like Tor here:

[https://www.schneier.com/blog/archives/2014/09/identifying_d...](https://www.schneier.com/blog/archives/2014/09/identifying_dre.html#c6678915)

~~~
woodman
> 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.

~~~
nickpsecurity
"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.

[https://en.wikipedia.org/wiki/Cyclone_(programming_language)](https://en.wikipedia.org/wiki/Cyclone_\(programming_language\))

[https://www.cs.cornell.edu/jif/](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.

~~~
woodman
> ...a person openly said they're ex-CIA.

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 */
         /* ... */
       }

------
frunt
What a histrionic, over-emotional mess these people are. With personalities
like that, it's a wonder any meaningful work on Tor gets done.

~~~
ethbro
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.

------
mercuryIntox
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.

~~~
coroutines
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.

~~~
ashitlerferad
Depends on their motives for joining the gov in the first place? Leaking and
whistleblowing? Awesome! Everything else? Not so much.

------
pizza
Mirror, since these things have a habit of getting deleted...

[http://hastebin.com/ecuwegiven.xml](http://hastebin.com/ecuwegiven.xml)

------
crumpled
RE: Those reactions from mrphs and ioerror

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.

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

~~~
anonbanker
he lied and said he was from the state department first.

------
gnu8
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.

~~~
atdt
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.

~~~
eternalban
"what we know of the surveillance capabilities

Correction: What you have been told.

------
rasz_pl
There is no such thing as 'ex-CIA agent'

~~~
SEJeff
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).

------
anonbanker
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.

~~~
mercuryIntox
> 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

I sincirely hope you are being ironic.

~~~
anonbanker
I fail to see how your quotes discount anything I say.

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?

------
Aelinsaar
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.

~~~
tptacek
Hasn't Tor already demonstrably failed to protect people from US law
enforcement?

Tor is an important research project. But that's what it is.

~~~
jimktrains2
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.

~~~
tptacek
No, I was referring to the FBI hidden service de-anonymization attack from
last year.

~~~
belorn
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.

------
ivraatiems
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.

------
raverbashing
Why are they using IRC instead of something like SILC? Or is this an internal
IRC channel that's only accessible using TOR (or maybe something else?)

