Tor, NSA, GCHQ, and QUICK ANT Speculation

by phobos | September 11, 2013

Many Tor users and various press organizations are asking about one slide in a Brazillian TV broadcast. A graduate student in law and computer science at Stanford University, Jonathan Mayer, then speculated on what this "QUICK ANT" could be. Since then, we've heard all sorts of theories.

We've seen the same slides as you and Jonathan Mayer have seen. It's not clear what the NSA or GCHQ can or cannot do. It's not clear if they are "cracking" the various crypto used in Tor, or merely tracking Tor exit relays, Tor relays as a whole, or run their own private Tor network.

What we do know is that if someone can watch the entire Internet all at once, they can watch traffic enter tor and exit tor. This likely de-anonymizes the Tor user. We describe the problem as part of our FAQ.

We think the most likely explanation here is that they have some "Tor flow detector" scripts that let them pick Tor flows out of a set of flows they're looking at. This is basically the same problem as the blocking-resistance problem — they could do it by IP address ("that's a known Tor relay"), or by traffic fingerprint ("that looks like TLS but look here and here how it's different"), etc.

It's unlikely to have anything to do with deanonymizing Tor users, except insofar as they might have traffic flows from both sides of the circuit in their database. However, without concrete details, we can only speculate as well. We'd rather spend our time developing Tor and conducting research to make a better Tor.

Thanks to Roger and Lunar for edits and feedback on this post.

Comments

Please note that the comment area below has been archived.

September 11, 2013

Permalink

What about the fact that Tor uses 1024-bit RSA, is there a defence somewhere of this decision? (A recent Ars Tech article said everybody should move to 2048, so it'd be nice to have some reassurance here.)

Tor 0.2.4.x uses a new stronger circuit handshake and stronger link encryption:
https://gitweb.torproject.org/tor.git/blob/refs/tags/tor-0.2.4.17-rc:/C…
As soon as I get time to write the release notes, this will become the new Tor stable.

For more technical details, see Section 6 of this research paper:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.228.6223
and you can read more about curve-25519 at
http://cr.yp.to/ecdh.html

2048-bit asymmetric crypto would be nice, but it's way too expensive CPU-wise -- the relays are maxed out right now handling circuit create requests from the botnet traffic, and the network would be in way worse shape right now if those were all 2048-bit requests.

[Edit: here's a point I made in response to a journalist question, which I'm pasting here too for completeness:

"It's not at all clear that NSA can break 1024-bit keys easily, or even at all currently. The main risk is that there will come a time in the future when it is easy -- and we don't know when that time will arrive -- and if they've logged Tor traffic flows from today, they'll be able to break those flows at that future point.

That's the biggest reason why upgrading to Tor 0.2.4.x is a good idea security-wise."]

September 14, 2013

In reply to arma

Permalink

Arma, thank you for your analysis and perspective..

I'm puzzled by your writing:

"if they've logged Tor traffic flows from today, they'll be able to break those flows at that future point."

due to Tor's use of forward secrecy technique.

Is this because you are distinguishing between "decrypt" and "break flows" -- are you referring to correlation techniques to identify who is connected where rather than decryption of content?

Forward secrecy means that if you break into the relays later, nothing you learn from them will help you decrypt stuff from the past.

It doesn't mean that the traffic flows from the past are magically undecryptable even by an adversary with enough computing power (or some other break on the crypto).

The Tor handshake provides this forward secrecy property, such that after the relay rotates its onion key there's no point breaking into the relay to help learn it. But if the attacker can just straight-up break the encryption, the forward security doesn't help.

September 19, 2013

In reply to arma

Permalink

Am I correct that you are explaining that breaking the PK asymmetric crypto leads to breaking the final symmetric crypto even when forward secrecy is used ?

To a non-expert it seems that employing forward secrecy using Diffie-Hellman means that the symmetric crypto's key is never exchanged between the parties. Therefore that key cannot be discovered by breaking the asymmetric crypto of old recorded traffic flows; the symmetric key used is simply not there.

Where do I have it wrong?

Thank you.

Unfortunately, what you describe doesn't exist as far as I know.

DH with forward secrecy means you use a new asymmetric key for each transaction. So they have to break each transaction separately (and breaking one doesn't help them break any others).

Edit 1: Ah, but I realize I was imprecise in my earlier explanation. There are actually two steps to breaking an old-style Tor handshake. First you have to break the relay's (1024-bit) onion key, which is rotated once a week. Once you've broken that, you can see the client side of the DH handshake (that is, g^x). If you can see g^x and g^y and also you're great at breaking 1024-bit DH, you can learn the session key for that circuit. So step one, they have to break a new key every week. And if they do that, they *also* have to break a new key for every circuit.

Edit 2: Oh, and you have to break TLS before you can see any of this. Or be the relay.

September 21, 2013

In reply to arma

Permalink

Ah, some people might be great at breaking the 1024-bit key, which isn't that hard by the way. It's almost 2015 and statistically, you may need only a little over 50% of the effort.
http://eprint.iacr.org/2010/006.pdf
And, oh, I haven't had any idea about the huge period of time that passes until the relay key is rotating. I thought it's a matter of minutes, hours at most, especially if it comes to a cheap 1024-bit key.
Well, it might be that in the near future you'll end up with users improving the Tor code on their own.

I encourage you to learn about the old design -- it is breakable by an adversary who finds breaking 1024 bit keys easy, but I think its main problems are not the one you describe.
http://freehaven.net/anonbib/#tap:pet2006

In any case, you should realize that I keep saying "old-style" and "old" design. The new design, NTor, is believed to be much stronger. See the links from
https://lists.torproject.org/pipermail/tor-dev/2013-September/005473.ht…

As for users improving the Tor code, that sounds great! Everybody who thinks that Tor was made in a closed room by two brilliant people and then it sprang forth fully-formed into the world is, well, misunderstanding how open source and research works.

September 21, 2013

In reply to arma

Permalink

Arma, I'm back, the one who was asking before the smart aleck stepped in front with his "Ah" and "oh" and blah.

You pointed out "what you describe doesn't exist as far as I know".

Where would my interpretation of Wikipedia be wrong? (I'm not relying on W as my only source). This seems critical to true forward secrecy.

Article "Diffie-Hellman key exchange" says that DH

"allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel".

In other words, supposing in a belt-AND-suspenders approach a channel to determine a symmetric-key for use by both parties is encrypted anyway (with asymmetric crypto) even though DH works fine with plaintext against a passive attack. Breaking the asymmetric crypto (by obtaining the private key) doesn't reveal the symmetric crypto's key because using DH the symmetric key was never transferred thru the channel in the first place --- exactly as I was suggesting above.

In Diffie-Hellman, Alice sends g^x, Bob sends g^y, and they each compute their shared secret key g^{xy}. Anybody watching can't compute the secret key, because you need to know either x or y in order to compute it.

But if I can compute the discrete log of g^x to learn x, I win. Or if I learn y from g^y. In either of those cases, I can compute the secret key.

October 03, 2013

In reply to arma

Permalink

... which has nothing to do with the asymmetric key, unless the old TOR handshake is broken. I'm supposing it is not, as it's based on TLS. So you have to break the symmetric key for each session.

It is becoming clear that an extended blog thread is the wrong forum for this discussion. :)

The old Tor handshake is not based on TLS. But that is probably not the root of your confusion. I'm not sure what is. I suggest irc, or the mailing list, or our shiny new tor.stackexchange.com.

September 28, 2013

In reply to arma

Permalink

Arma, I've got a question concerning this issue: Assuming that they have recorded tor traffic in the past and they are able to break all those encryption at a future point - What will they "see"? afaik, the content of the transmitted data as well as the IP from the client, so they would be able to break the anonymity, right?

To say it clear, if this is correct it would be a major issue for all tor users who care about their anonymity, which was the initial goal of tor. In the worst case, all tor traffic from the last years could have been recorded and then, when 1024 bit RSA/DH is broken (which is believed to happen soon or already has happened) be decrypted and associated with the clients as well as the servers identity?

Would it help if the clients ISP doesn't save any IP logs at all or if they are deleted after a few days/weeks? So the attacker won't be able to do the last step and link the IP to the end user?

The real threat happens if the attacker is logging traffic at the client side. In that case they know the user's IP, and they're trying to decrypt the traffic in order to learn the destination websites that the user has visited.

So in this case it doesn't really matter what the ISP keeps or doesn't keep -- they've already let the nice man put the big black box in the secret room, or given them a realtime feed of all the data that goes over their backbone, or however it's done.

If the attacker isn't logging at the client side, then it's going to be a lot harder for them to trace any traffic back to a particular client, even if they're good at breaking crypto.

September 11, 2013

Permalink

I am currently investigating the sourcecode of "Mevade.A" they have Anti-Debugging methods and reportings if someone is debugging the Code. I have done with them, they don't catch me debugging cause I am debugging from outside the VM. Now this coculd be a break through cause I am a part of the Bot.Net outside of TOR. They think I am a TOR node but I am not and I am communicating with some other Bots within the TOR Network. They unhide their Identity by contacting me directly not through TOR cause I have an Exit Node and TOR Relay routed through my VPN. They can't see that their traffic is routed otherwise. Its time that my Node got attantion from the C&C Servers to discover their hosts. This takes some time... :-(

But I am offending them and kick their lame cypher asses!

best regardes!

September 11, 2013

Permalink

Staiing within .onion is secure , and yes timing can be used if the input and output are unencrypted.....
if one ore both the sides is encrypted its mutch harder.

September 11, 2013

Permalink

1) Why does Tor project continue to accept money from the US Department of Defense and the Broadcasting Board of Governors? Is this a conflict of interest?

2) Why would the Tor project allow the Broadcasting Board of Governors to run major Tor relays and exit nodes when it is widely know that they are part of the CIA/DoD's psywar operations?

3) Is there any reasonable expectation that the feds haven't just been running relays/exit nodes and saving the traffic for later decryption?

4) What does Dingledine have to say about his NSA internship? Or the fact that Paul Syverson still works at the Naval Research Lab? Or that Dingledine and Matheson were private contractors for the Naval Research Lab?

1) Because we do great things with the funding, and everything we do is open and you can look at it. I would rather have more diverse funding (anybody know other funders we can talk to?), but so long as they only ask us to do things we wanted to do anyway, I think it's better than not.

You might like http://www.washingtonpost.com/blogs/the-switch/wp/2013/09/06/the-feds-p… for more details (if you can get over the inflammatory headline).

2) BBG doesn't run any relays or exit nodes. Citation please? (Also, you are mistaken to think they're part of CIA/DoD, but whatever, that's irrelevant one way or the other here.)

3) They might be running exit relays and saving the traffic. That said, you are totally right to be worried, but you're worried about the wrong thing. You should be worried that they're *monitoring* existing honest exit relays and saving their traffic. See also
https://mailman.stanford.edu/pipermail/liberationtech/2013-August/01059…

4) I'm Roger. I'm glad I worked there for a summer -- I wanted to learn if it was the sort of place I wanted to work at more, and I learned that it sure wasn't. Happy to explain more in person sometime. Almost all the people there are typical government employees (not very motivated and not very competent). That perspective also helps me to figure out how best to educate other groups, like law enforcement, about Tor:
https://blog.torproject.org/blog/trip-report-october-fbi-conference

As for Paul still working at NRL, see point '1' above, and also see the research papers that he produces, as listed e.g. on
http://freehaven.net/anonbib/

Why are you concerned about Paul but not concerned about university professors, who get research funding (which in turn pays their students) from this same system?

For more discussion on sustainability, see also
https://svn.torproject.org/svn/projects/articles/circumvention-features…

As for the original funding from NRL through DARPA... same answers as above.

I understand that it's easy to see conspiracies everywhere these days (and there clearly *are* many conspiracies out there these days), but if you think there's a conspiracy and you don't look at all our code, design documents, research papers, and so on, you're doing it wrong.

September 12, 2013

Permalink

If HTTPS security relies completely on trusting a central authority (CA's), and the CA's are under the control of the NSA, then can we assume that HTTPS is broken?

Using HTTPS is way better than not using it, but you are right to be concerned about how safe it is. The real trouble isn't that all the CAs are under the control of NSA. The trouble is that there are 200 or so of them, and if *any* of them is run by, compromised by, or otherwise working with your adversary, you can lose.

For a close-to-home example, it is silly that Firefox will believe an https certificate for www.torproject.org that's signed by the Chinese government's certificate authority. One fix there involves certificate pinning (ask your favorite search engine about it), but that's also not a complete solution.

This issue with https is part of why we're so fervent at trying to get people to check PGP signatures on their Tor downloads:
https://www.torproject.org/docs/verifying-signatures
I am extra sad here that it's so difficult for Windows users to check signatures smoothly and correctly.

September 12, 2013

In reply to arma

Permalink

why not release MD5 or CRC32 hashes ? Those are easy as pie to check on windows.

Also SFV which is based on CRC32 i believe by default works nicely cross platform.

Quoting from https://www.torproject.org/docs/verifying-signatures:

"Some software sites list sha1 hashes alongside the software on their website, so users can verify that they downloaded the file without any errors. These "checksums" help you answer the question "Did I download this file correctly from whoever sent it to me?" They do a good job at making sure you didn't have any random errors in your download, but they don't help you figure out whether you were downloading it from the attacker. The better question to answer is: "Is this file that I just downloaded the file that Tor intended me to get?""

If we provide MD5 hashes along with the downloads, you have the same problem you had before: how do you know the MD5 hashes are actually the ones we meant for you to get?

CRC32 hashes have a much worse problem: I can easily generate a Tor Browser Bundle whose CRC32 matches any CRC32 you give me. It's way too short to have any security for this scenario.

September 19, 2013

In reply to arma

Permalink

Yes,
But how do i know that the key i fetch via "gpg --recv 0x...." is the right one?
I can check the fingerprint, but HOW ? How can i know if the key fingerprint is the original one or not? The only way to be sure about that clould be for me to fly to the US so that you or some other Tor developer give me the original fingerlrint for that key.
it's unrealistic. We live in a Totally insecure world.

the same apply as well for debian/fedora/slackware/ecc keys fingerprints. I cant trust the Net because routing makes my traffic pass through the U(/N)SA territory or through ISP that are collaborationists with the Nsa.

I know there's something called web-of-trust of the gpg keys but how can i do that? To do that i would need to personally know/meet some developer of that software (Tor/debian/fedora/ecc) i'm downloading. not so pratical/realistic.

Btw is fingerprint a warranty for collisionless of the key?

Ah, do you know that using the TBB is IMPOSSIBLE to download the signatures and chòecksums for devian live?
With ALL version of the Tor Bundle. it freezes. only with that files. Try! It always freezes if you try and then the only way to get the files remains the "plaintext Internet" (aka "nsa-net")

Thanks for your time reding this and the other post about the insecure Tor version for android (the one from guardianproject.info, DATED 2012!! That leaks the device modelname in the useragent)

Re: the web of trust, see also the last paragraph of
https://www.torproject.org/docs/faq#KeyManagement

It's actually not that crazy to find a Debian person in your city who is connected to the pgp web of trust. They're everywhere. And I bet the signature chain between them and me is surprisingly short.

Re: debian live, what URLs specifically? Sounds like you should file a ticket on trac if it actually breaks your Tor Browser Bundle. It might be a bug in https-everywhere, or in our Tor Browser patches, or in something else.

September 21, 2013

In reply to arma

Permalink

hi, ( and thanks for the reply! )

GPG web of trust:
I've managed to get safe-enough gpg keys of debian from and old (checksummed sha256) system backup and now i'm confident that my installation is ok (original).
I notice that there are debian-keyring and a torproject-keyring packages available via apt-get. Is there a way to use them to verify & trust Tor keys? Does torproject-keyring contains the normal Tor keys? can i use it to verify the legitimacy of the Tor apt-key file and the Tor Bundle keys ?

Debian live checksums:
I tried to disable HTTPS-Everywhere but nothing changes.
the urls:

1) http://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/SHA51… it freezes(***) the browser for like 5 seconds and then the browser is usable again but the page of that tab is still empty (but it loaded the page icon for the tab)
(***)freeze = unusable, and i see the "loading circle" that's freezed too.

2)http://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/SHA51…
It managed to load the file but *only* 4 lines and almost an half of the 5th line.

3)the bugs remains also if i disable HTTPS-Everywhere, Javascript and the images.

4)Note:
I can download them if instead of TBB i use the "apt Tor" from the torproject repository + privoxy + iceweasel-OR-links-OR-elinks-OR-firefox
And yes, i think the bug is in the modified browser itself, not in Tor.

OT: is there a way to learn coding&understanding Tor & involved cryptography? i mean a "developer guide". I tried looking at the code some time ago and i've found it not so easy to understand.
Any advice about the needed background? Is there something about it on this website?
I'm reading Applied Cryptography (Schneier), is is a good startpoint?

thanks for your help.
you all are doing a very good work and i think it's useful not only to chinese/russian dissidents but specially to the US and European ones (we have FB and Google etc! :( )

(Still me)

hi arma,
Does that bug only happens to me?
have you tested if it the TBB you use has the same problem?

was my connection to https://tor.eff.org hijacked by some US agency in order to give me a modified version (aka non original, aka NSA-friendly version) of TBB?

September 14, 2013

In reply to arma

Permalink

I agree that it's disappointing how difficult it is for Windows users to check signatures.

Would it not be possible to code a simple Firefox addon that could be incorporated into the Tor Browser Bundle (and used in non-Tor Firefox of course) that allows the user to select the .asc and the .exe (after downloading them of course) and have it check and confirm the signature automatically? Perhaps also with an option to paste in a sha1sum instead of selecting the .asc file as an alternative check.

The real challenge is that first download -- how do they know they got the right thing? That's the same problem Windows users have with GPG right now: our instructions start with "first, fetch this exe using this http URL..." It doesn't matter how amazing the program would be if you didn't actually get it in the first place.

That said, you're absolutely right to point out that things can be made a lot easier assuming the user bootstrapped correctly the first time.

Ask google about 'tor thandy' for details on our secure updating design, which is stuck in part because there's no such thing as a package manager or package format for Windows.

One of the upcoming steps we're going to try is using the Firefox updater to auto fetch updates for your TBB. Then it can auto check the signatures on them too. (Though last I checked, Firefox doesn't do this -- it just relies on https, which in turn relies on every single one of the CAs. See above thread. :/ )

And finally, check out the Tails instructions for verifying the download:
https://tails.boum.org/download/#index3h1
I like them, but then, they're targetting users who are planning to run a Linux LiveCD, so they probably won't work so well for the broader Windows crowd.

September 18, 2013

In reply to arma

Permalink

As you say, there's no real way to be sure that the OpenPGP I download, to verify that GPG isn't comprised, is itself uncompromised!

Tor Thandy sounds very promising though and I look forward to it.

I agree...
that it is disappointing that people still use windows then have the nerve to bitch to anyone about problems with their system. Same for the TBB when Tails is head and 'tails' above it not to mention it provides a Linux experience for all those who think Linux is a difficult OS which could not be further from the truth. May have been true years ago but not anymore in any way. Both Mac OS whatever & Windoz are in fact much more difficult OS's to work with. The amount of people who complain and think that PGP/GnuPG is difficult are ALWAYS windoz, crApple, TBB users. The same users that DID NOT UPGRADE then complained and BLAMED the tor devs for their own incompetence and apathy after the TBB exploit in late June. That was a pathetic thing to watch, the blame game by TBB users who couldn't be bothered to upgrade or use Tails. arma and crew can't hold your hands every second and IMO they already have to spend too much time coddling these types of users. The same users who tore them to bits in every comments section of every article dealing with the FBI's pathetic attempt in June. How bout you ingrates say thank you to these guys for the opportunity then go and teach yourself. Thank you arma, and everyone else who does there best and Roger, you're a better man than I, your patience is amazing.

Thanks for the support.

.oO("Also, my master plan is working! They think Roger and I are two different people!")

September 16, 2013

In reply to arma

Permalink

I have an idea to help users check PGP signatures.
I constantly use the extension DownThemAll for any and all of my downloads, the reason I use this extension on Firefox is because of it's built-in ability to check MD5, SHA1, SHA265,SHA384, and SHA512.

If we could talk to the developers about programing it to give the user the option to check PGP signatures as well, then this would all around be a lot easier on the end user.
If they do make DTA capable of checking PGP, then it would also be a great idea to have it bundled in with the Tor Browser bundle.

I personally have very little programming experience, so I'm not entirely sure on how feasible this would be, but it would certainly help make many users that much more secure when downloading (should they choose to use it).

Here is the website for DTA: http://www.downthemall.net/

~1Sonicsky1

Bundling it with TBB would be the wrong way around. Then you'd have to use the thing you fetched in order to check if it was the thing you should have fetched.

I think we can solve the "how to check if your update is legit" problem (though we haven't chosen a good way to do that yet, so it remains an issue in the short and mid term). The really hard problem is the initial bootstrapping of trust.

On Debian, you get gpg in the operating system, so you have a trust anchor. On Windows you don't. Oops.

September 18, 2013

In reply to arma

Permalink

Sure, on one hand it seems illogical to "trust a downloader to verify a downloader", but most people aren't going to compile the initial downloader and inspect it for themselves (and never will), so, on the other hand, the flow has to incorporate a trusted package that was, at some point, downloaded. If you're going to bother to design verification well enough to be trustworthy, why not incorporate the "ideal" verification method to download the initial bundle into DTA or another plugin? It's silly to think that just because someone has downloaded gpg4win from some other server than the one of the package I need to verify, then somehow that means it is substantially more trustworthy. Anyone who attacks your fancy anononymizer encryption thingy will almost certainly prioritize attacking the other websites hosting the tools used to verify your thingy. Demanding that a separate process verify the thing you provide than the thing you provide just means that it is either another host's, or a different program's responsibility to ensure. At best, you are forcing the attacker to secure multiple targets, neither of which apparently has guarantee against compromise.

On another note, it could work to have one verification method for the TBB, but still incorporate the above poster's DTA suggestions for other downloads that TBB will handle in the course of it's daily use. Downloading is a part of any browser experience, secure mechanisms absolutely should be built in.

One of the main ways to make sure a checksum or hash, or the file they pertain to, haven't been intercepted is to obtain them using different computers on different connections at widely different times. This doesn't ensure the absence of tampering, but it hedges the danger. The attacker would have to have compromised a broad array of servers over a long period of time (depending on the distance in time the downloads took place) in order to make sure that the downloader got and installed or executed a bum file after trusting a tampered checksum or hash.

In this way, it is almost more important for the creators of the software to make the hashes secure and available and than the distributed software itself. Get Tor off Tucows or Softpedia, why not? (ok, gross... but anyway...) The hashes will let you know what you do or don't have. You can try getting the hashes weeks apart, if you need to be extra sure. Just don't forget to make sure the version is the same.

Word to those newish folks who are wondering about all this.

But regarding the post above, perhaps a method could be made that employs this specifically? Hashes not only distributed, but aged? Or some such?

September 25, 2013

In reply to arma

Permalink

It would be assumed that if the user was a target that their personal email would be a target, so they'd have to make sure to get either the hash or the bundle or both from separate throwaway email accounts.

Essentially, in the case of getting the bundle mailed, your adversary at that point would have to own every large-attachment-allowing free email provider and sensitize it to incoming communication from Tor's servers; not an absurd prospect considering the aforementioned dearth of providers allowing such sizes. Better to use one of a thousand random small providers and just get the hash, taking your chances to find its corresponding bundle in whatever wilds you happen to be in. Even then I'd try to check it against Tor's website and any other official mirror - I don't really understand why Tor maintainers do not print the hash next to each download in addition to making it available as a download. Seems like the best idea.

At some point, if not already, the resources of nation states will be as such that subtly owning all relevant assets of a target will be as easy as owning one or two. I'm not sure if we're at that point yet, so spreading out the trust sources (hashes) of Tor across as many allied domains as possible seems to be a really good tack.

It'd be pretty cool (though of course a little tedious) to cross reference the latest bundle's hash on the downloads page with one posted on EFF.org and with, say The Colbert report's website and that of Senator Wyden. Making no assumptions here about their sympathies to the project - I just said it would be cool.

Actually, posting the hash would be a better and more direct political statement than some banner ad. Not to mention spreading out the damages able to be claimed and litigation vectors when one of those hosts finds out they've been tampered and potentially gets pissed about it.

very interesting post.
Only one thing: the hash changes for each release/update.
A better solution could be to spread (via EFF.org, Colbert report website and others...) the hash (better sha512sum ) of the GPG *key* of TBB. So that everybody can get the key and check if it's the original one.
For example the user in possession of the hash could download the key from a large list of servers and then he could check the sha256sum of the key.
If the key is ok ---> problem solved

October 04, 2013

In reply to arma

Permalink

they could use some of the many available programs to check the sha256sum (or sha512sum) of the key, and then they could use gpg (windows versions do exist) to use the key to verify the downloaded file.

pretty simple

Gpg4win is a mess visually. I've run before and it annoyed the crap out of me. The workflow is all over the place... "how many applications am I running at once for this again?" "why does that thing have to camp out in the tray since all day I only needed it once?" 9_9 ugh

Version numbers changing isn't relevant; presumably the posted banner or sidebar or page or whatever would state the relevant version and platform alongside the CH (Keccak yet, anyone?). If someone is clueless enough that they use the CH for a version it was clearly posted not to pertain to, that would have to fall outside the sphere of the project's concern.

Anyway, screw the keys - distributing software packages isn't chatting. Just broadly distribute CHs.

CA technically means 'Certificate Authority' not 'Central Authority'. There are a bunch of them, and they sign public keys. One popular CA is verisign. You have to trust the CA to trust that a public key belongs to who it says it belongs to. Its a weak point in public key crypto, surely. The NSA could corrupt CAs by a variety of means such as legal threats, or spy type operations (the Iranians did just this a while back). They don't need to 'control them', they just need to get them to sign a public key that says they are, say google, and/or modify a certificate revocation list.

Right. And remember that they just have to compromise any one of the hundreds that are out there. Even if you totally trust Verisign, that doesn't matter because they could go ask Turkish Telecom, or whoever, for help.

As a little tidbit to add: I hear Chrome is giving up on the certificate revocation check -- it's a big hassle for usability and speed, but most importantly a local attacker could just prevent that connection on the network, preventing your browser from learning whether any revocation has happened.

September 12, 2013

Permalink

Earlier, I do remember reading that the recent traffic increase was solely about directory information exchange and that it didn't affect the tor network itself. Ever since it has started, I was thinking, given sufficient computing resources, that they (could be more than one entity) are actually trying to map the whole tor network, which isn't that big, by doing these directory requests and de-anonymize, even decrypt in real-time (1024 bits RSA keys are jokes ATM! 4096 might last another 5-10 years) the most part of the streams they focus on.

Some suggestions for the next "full" version of Tor:
- advertize/randomize/change peer connections faster and the peers/relays keys renewals - might increase the administrative trafic but it's worth "obfuscating" the internal functionality
- go for 4096 bits keys - commercial sites are using 2048 and tor is supposed to provide a higher level of security. The end users, the ones who need the service won't be affected and the relays/bridges will maybe handle less (but better secured) connection, that's if they are not running on some new CPU that has AES capabilities embedded

Best regards and thank you for your hard work and this beautiful piece of software. It truly helped me a lot.

P.S. I also strongly suggest to all tor users/relays/bridges to disable (if possible - in Linux it's very simple) the tcp timestamping.

Unfortunately, the spike is not solely about directory fetches. Those were the first thing we noticed, but soon after we noticed a huge spike in circuit create requests:
https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients
Latest theory is that each of these new clients is hitting a hidden service (thus generating many circuits) pretty often.

Mapping the whole Tor network, if by that you mean relays, is not hard. It's exactly what we already tell you in the directory information. It's not a secret. See also
https://www.torproject.org/docs/faq#HideExits

So making a bunch of new circuits as a client won't help deanonymize other Tor users like that. There are some other potential attacks where it could help, e.g
http://freehaven.net/anonbib/#ccs2011-stealthy
But I think for an adversary of this size there are much simpler attacks than this one.

I think changing peer connections faster could actually introduce other anonymity attacks -- see e.g.
http://freehaven.net/anonbib/#esorics12-torscan
So it is not this simple.

As for 4096 bit keys, sounds great except the cpu load on relays would be unbearable. See comments elsewhere on this blog post for why the ECC-based handshake is the only practical way forward at this time.

And as for disabling TCP timestamps... go ahead I guess, but I think there are many many things on the list before this one.

September 16, 2013

In reply to arma

Permalink

I would prefer NTRUsign for the digital certificates... this seems more secure if you choose the proper size for 256 bits AES.

September 12, 2013

Permalink

And if my previous comment was approved, then add to the suggestions list:
- a minimum key size for the encryption protocol, like 256 bits for AES, that's if you don't already consider any other protocol than AES. Key sizes should be doubled every 5 years or so (128 bit is already dangerous) - just to keep pace with the technological developments - see Moore's law.

I think you have your math wrong. If you stick to Moore's law of computation power doubling every 18 months, then the change between 128-bit and 256-bit is 192 years, not 5 years.

In any case, both 128-bit AES and 256-bit AES are doing great against brute force attacks. The real worry, well before the 192 years elapse, is that they'll have some new analysis to make the attack significantly quicker than brute force.

September 13, 2013

Permalink

The main problem this article describes is at the exit points, where NSA and others can monitor traffic.
But what about hidden services? AFAIK, if someone visits a hidden service, his/her traffic will never go through an exit point, since all communications remain inside tor.

So I guess visiting (and/or hosting) a hidden service is safe from this kind of eavesdropping?

In short, unfortunately, the answer is "not at all and maybe it's even worse".

It sounds like you're conflating two issues.

The first is that if you make a connection through Tor to some external destination, and you don't use encryption, then somebody sniffing at various points on the Internet (but not inside the Tor network) can see the plaintext of your traffic. This is a big deal, but it isn't the issue here. (It also has at least theoretically a very simple fix: use encryption.)

The second is that an attacker who can watch a lot of places on the Internet can examine traffic flows and realize that they're correlated. And this has nothing to do with whether traffic "exits" the Tor network. One variant of this attack would be for the attacker to visit the hidden service, and then see if the traffic flow on his Tor client is correlated with any traffic flows he sees elsewhere on the Internet, e.g. connecting from a Tor relay to a Tor client. In this case hidden services may actually be weaker than normal Tor connections, since the attacker can induce them to talk at a timing and volume of his choice, potentially making the correlation attack easier.

September 18, 2013

In reply to arma

Permalink

By dynamically changing routes and delaying packets inside tor, there will be no correlation possible. Hidden services should by default act as relays, better as exit nodes, then they'll have plenty of traffic going through, even when nobody is accessing the hidden service itself.
Throughput should be the least important factor in router decisions, focus on uniformity instead. Tor should not prioritize on streaming data like video,voip or file sharing.

As for the first paragraph, I'd also love for these claims to be true, but currently they appear to not be true. If you think it results in "no correlation possible", it means you haven't studied the statistics enough. Now, I am optimistic (though some others aren't) that some sort of changes in padding could improve our resistance to correlation attacks. But I'll try being more concrete: "Give us a specific proposal? Because every previous specific proposal that anybody has ever come up with has been broken."

As for the second paragraph, the main reason Tor is slow right now is from queueing inside the relays. That is, it's because there are many more bytes trying to go through the Tor network than can fit. If clients choose their paths by anything other than weighted by relay capacity, we would make these hotspots even hotter, making performance way way worse. For example, web browsing would be unusable. And then all the users would disappear, and all the relays would disappear, and then what.

September 21, 2013

In reply to arma

Permalink

I think I do know enough about statistics and their limitations.
Briefly, I'll cover some proposals:

1.I haven't been through the tor path allocation algorithm but my suggestion is focusing on the very end of it.
Say you have 3999 available paths, which you already sort according to several factors like throughput, link stability, etc and you end up with some candidates.
You take these candidates, just the conjuncture top ranking ones and put them in a matrix with their according priority, like:
ABCD
1234
Then, the most simple way that comes to mind, you generate a random number, in Linux by using urandom (plus some environmental salt) and in Windows hmmm... the same, by using the number of running processes, cpu cores, free RAM, xor-ed (or maybe a succession of binary operations, not too many since you don't want to kill the CPU) with a randomly generated number. Say you'll get 6598 as a random number, which you will xor with the 1234 form above, then the new matrix will look like:
ABCD
7444
By sorting this, you'll get BCD as prioritized candidates. The statistics would end up trying to guess the random number, awesome.
So, you'll satisfy a little of both worlds, keep prioritizing on throughput/link stability and add some entropy in the path allocation process, all this achieved with a little overhead and through an irreversible function.

2. Queues, I forgot about these, sorry, my bad. I guess the algorithm is FIFO, therefore the same entropy generation from above would shuffle the queue a little bit. It will also solve the timing/delay pattern recognition issue.

3. Timers, they are very important in both the path allocation and circuit building processes. They should be put in place and generated randomly, in such that you won't use a circuit more than several minutes, after that you should end up in another round through the above points 1&2.
I just noticed, that as a client I ended up with the same 2-3 peers for several hours, although I played with the already available CircuitPriorityHalflife, NewCircuitPeriod, MaxCircuitDirtiness and MaxClientCircuitsPending. I must admit that I observed some unsuccessful new circuit creations every now and then but that was all. Not sure now if these conf variables do have any impact at all.

4. Packet size, shape - header - payload. At this level, although it will be identified as tor traffic, a little uniformization will make any circuit recognition/backtracking impossible.

You are right, unfortunately the actual tor performance is pretty bad but changing the rules might discourage the ones that are testing their science and algorithms right now.

September 22, 2013

In reply to arma

Permalink

I'm just suggesting to do some small architectural changes, by diverting the potential adversary statistical efforts at an entropy generator, all this by following the KISS principle. I guess it will address more than what is covered in the freehaven papers, which are all based on assumptions and trying to make the math consistent with the idealistic and deterministic environment where it is applied.

September 13, 2013

Permalink

hi, please can you link me here an URL o the 2.4.17 (or must be a 16 ??) varinate of TOR for WIN? i had some months ago problems with NOnameScript as well - they attacked the TOR and became no more safety.

September 13, 2013

Permalink

QUICK ANT is most likely a correlation between exit and entrance nodes. Unfortunately, the absence of such correlation also leaks information about hidden services.

Regardless of the efficacy, the Tor project, and those who support it, are modern-day heroes.

"Most likely"? I don't see that from the screenshot at all.

See the last two paragraphs of the blog post for my theory.

I mean, I don't want to declare that NSA has no tools for correlation of flows across the Internet. We've long assumed they do, and the remaining game is to wonder how much of the Internet they can see vs where the Tor flows go. But in any case, it's not at all clear to me that this 'quick ant' thing is that.

September 15, 2013

Permalink

"Tor flow detector" -- old question but I'm confused - so if I run my own Entry and Exit nodes can NSA and others get my data?

Running your own entry and exit points doesn't really change much unfortunately.

There's still the chance that a large attacker has done deals with your upstream to be able to tap the traffic. Where will you run them such that their ISP, or their ISP's ISP, or so on up the chain, is out of reach of large attackers?

Plus if you run your own relays and you use them preferentially, and an attacker knows this, and the attacker sees some anonymous person using them, he can guess that it's more likely you than the average Tor user. See
http://freehaven.net/anonbib/#ccs2011-trust
for more discussion of this second issue.

September 15, 2013

Permalink

Al you geeks can argue about technical details. TOR doesn't work and it probably never did! Moderate that!

(I assume this comment and the one above it are from the same person.)

I guess the answer is "it depends on your threat model". There are many people out there for whom the Internet as a whole is just too scary for their security requirements, and it is a reasonable choice for them to stop using the Internet.

Or said another way, I think Tor is still better than the alternatives, but in this world you're right that that may not be enough.

geeks and tech details.... Dude, you are on Tor blog with heavy participation from a lead dev... what did you expect and do you need to post here to tell all that you're done w/tor????? lol Sounds like you got bigger issues than not trusting tor.
***And, "moderate that!" ?????
Real helpful addition to your worthless post.
this(my) post may be equally worthless but I can not stand to see all the haters, do you see this man responding politely to all of the insulting/ignorant commenter's??
He's too good of man to call you fools out but I am not.

September 15, 2013

Permalink

- Authentication wise - which is the most important step in the tor game, for the increasing the 1024 bits RSA key size proposal - look at the "theoretical" TWIRL device. Personally, I guess it's already done and maybe even parallelized - very cheap solution.
- it's naive to believe that somebody will use supercomputers (clusters) to compute software overhead (just changing the value of a variable takes some processing cycles) instead of building a specialized ASIC or FPGA system. I guess the Moore's law suggestion was misinterpreted, there are a lot of "groundbreaking" technologies appearing (see the quantum computing and the application of Grover's algorithm) and by looking at the timeline of changing ciphers, you would notice that every 5-10 years, things are fundamentally changing. Besides, AES256 if implemented correctly (very important aspect) has more rounds and greater complexity than AES128.
- about obfuscation, it was 2010 or 2011 that I first saw some articles about using many instances (over 10) of tor, load-balanced through a proxy server (squid). Some even developed and published scripts for doing that - use the "don't be evil" guys search engine for more details. That's all for achieving an increased anonymity by using the principle "if I don't know what I'm doing, nobody else will". Pretty healthy principle, but abusive and unethical towards the tor network and usage principles. This might also be a cause for the recent traffic increase. I was also tempted to do this but using only two tor instances now, on which I alternate (kill and restart) in a random fashion - since sending a NEWNYM through the tor control interface is a little bit more complicated to automate - you should consider a variable in the conf file for this purpose (I guess a lot of people would like to randomly change their identity, even for the purpose of escaping an IP ban and maybe re-authenticate too, that's with the very helpful 1024 bit key)
- I'm using tor (together with a lot of browser plugins) solely for clearing my way through the more and more invasive algorithms that tailor the content for you - it's already psychiatrical what these people are doing by trying to distract you form your "carefully planed browsing or interests/study".

Keep it upbeat and again, thank you for this beautiful piece of software that keeps me sane and focused on my tasks while browsing the internet and ... poisoning the "evil" algorithms with false identities. It's so nice when I get an advertisement in a language I don't understand - my mind rejects it instantly.

September 15, 2013

Permalink

So pretty much the answer to any suggestion made is "Just be cautious, we can't/won't do anything".

No, we're continuing to do a huge amount on both research and development of how to build a scalable good anonymity / blocking-resistance system. And by 'we' I mean a broad community of people, not just the Tor people.

The lesson to learn from some of these responses is that building a good anonymity system is *hard*, and most of the first ideas you'll have are wrong in counterintuitive and interesting ways.

If you want to contribute, step one is to get some more background on previous designs, previous attacks, and some of the defenses against those attacks. Otherwise you're very likely to produce an approach or design that falls to those same attacks.

To quote https://research.torproject.org/ :
"To get up to speed on anonymity research, read these papers (especially the ones in boxes):
http://freehaven.net/anonbib/
"

I guess the other lesson is that a several-sentence suggestion in a blog comment is the wrong way to contribute usefully to the design. See
https://www.torproject.org/docs/documentation#UpToSpeed

September 16, 2013

In reply to arma

Permalink

The Vision/Mission of tor was (hope still is) to help its users (some of them in really bad sociopolitical situations) to achieve a certain degree of anonymity and not too much security. However, in the actual context, anonymity implies strong security.

The successful hacks on tor were predominantly statistical (pattern seeking, correlative), here, a little entropy will make the math/graphs look irrelevant.
Focusing only on the tor system, that's by disregarding issues at the user side - leaking DNS calls, unsecured application/browser, unsecured SSL infrastructure etc, which are all the fault of the user itself (unless they are using Tails/Tor browser bundle), I do see two generic weak points and would like to develop on them in the following lines:

a) User side Authentication & Encryption: If the authentication/encryption is weak (or broken), it renders the rest of the effort useless. Actually you might need to consider all the available encryption broken and estimate the time in which it's possible to obtain the key and change the key accordingly (random based or per changing connection it's even better, an adversary cannot do too much with chunks and bits of data, maybe getting more angry). ECC, although very efficient, more efficient than AES it seems, which was also adopted mainly because of efficiency, seems to be an unhappy choice, both from the perspective that it has not that much academic/scientific scrutiny and because not even NSA is using it - but had a recommendation to use it in the future, more like: it's promising but please do some decent research on it. Here, Bruce Schneier gives more details on ECC:
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-s…
http://www.wired.com/opinion/2013/09/black-budget-what-exactly-are-the-…

b) Entropy, noise, call it also obfuscation: if the data streams are a little (voluntarily) delayed, packet size constant, packet structure uniformed, follow different routes on random base (randomness is a strong word, since it's hard to achieve, but you might be able to do some simple math on the nontransparent tor router/bridge HW serial numbers / environment (amount of RAM, storage, CPU type), etc), then the pattern seeking and correlation will be very difficult. Moreover, on the client side, the peers should change dynamically (diversity/noise) and re-authenticate too (see the point above). If the client communication is filtered, the first bridge that he/she successfully connects to should help.

The above points are tackling the capabilities of the potential adversary and suggesting to make tor a little more dynamic. It's all economic related in the end, in such that if the effort to capture a stream is to high (encryption + entropy), then it will be dropped and more traditional intrusive (hard to keep private and stealthy) approaches will get in place.

Tor is collaborative on the infrastructure side and the source code open on the developers side. Collaborators should be encouraged to grow, by providing them with quality and serious approaches. Open source itself cannot hide dirty tricks, which is why randomness (a little salt & pepper) can only be achieved through the nontransparent environment of the nodes, any other algorithm in the source code can be understood and back-engineered.

When taking decisions about compromises, please put security and anonymity at the top of the list. If they require more processing power, I'm confident that the collaborators will understand that and improve their equipments, it's all so cheap now.

Have a wonderful day! & Keep doing what you do!

September 16, 2013

In reply to arma

Permalink

arma,

I was using this blog to reply to your Speculation and stay anonymous. I would go on a tor mailing list and provide there some suggestions and opinions, although I don't understand your point with the way I'm trying to help.

You shouldn't approve this post and maybe not even the previous one. I believe I did my job, shared my thoughts and maybe made some contribution.

Best regards,
anonymous

September 18, 2013

In reply to arma

Permalink

Maybe you're doing a lot of research, but you sure as hell haven't done the most obvious things to protect your users, such as disable JavaScript by default. You're STILL distributing Tor with javascript enabled, and not even warning new users, and telling them what happened.
And you also haven't stopped the botnet, because you're still accepting connection from it. Anyone who is a real user can upgrade, the bots won't so all you have to do is add code to stop accepting connections from the version that botnet uses.
Since you guys haven't done any of these things, it really makes me wonder about your lack of focus and reliability of tor.

We're certainly being overloaded these days with the wide variety of technical and social things that need to happen.

As for the Javascript question, help us make
https://trac.torproject.org/projects/tor/ticket/9387
happen.

I think that teaching our users about what security properties Tor can provide is really important. Once upon a time we did that pretty well, but then we got the other 800000 users, and most people were suddenly learning about Tor from some newspaper story rather than from me in a talk. Help us sort out the best way to communicate these complex topics -- "here, click this thing you don't understand" isn't going to teach them to fish.

I actually think the botnet is lower priority than some of the other issues. It's reasonable stable. I would like to explore whether we can come up with better ways to handle the entire topic, before we kick this one off the Tor network. To be clearer, we can kick it off now (along with a lot of normal users, yes), but if it upgrades we're in a much worse position without a future roadmap.

September 16, 2013

Permalink

When I originally commented I clicked the -Notify me when new comments are added- checkbox and now each time a comment is added I get four emails with the same comment. Is there any way you can remove me from that service? Thanks!

September 17, 2013

Permalink

I can't believe you guys are still distributing Tor Browser with javascript enabled by default, after half your userbase just got totally screwed and had their MAC addresses and IPs revealed to FBI. Seriously what is wrong with you people ?

Half our user base? There's no telling how many it was, but I'd be shocked if it's anywhere near half. Most Tor users don't know what a hidden service is.

As for the usability tradeoff, see
https://www.torproject.org/docs/faq#TBBJavaScriptEnabled

While we're making broad claims, I'll go with "more than half our users would think the browser is broken, and go use something even worse, if it didn't support javascript".

September 22, 2013

In reply to arma

Permalink

Apart from JavaScript deanonymizing potential, Firefox, Chrome and Safari are leaking an unique browser identifier. Including and enabling the Firefox plugin FireGloves in the TorBrowserBundle seems to be a good idea.
For more details, check:
http://ip-check.info/?lang=en

FireGloves sounds great except
a) Their page says they're not working on it anymore, and doesn't say when they stopped; and
b) If you're the only Tor Browser Bundle user who has installed Firegloves, that right there could be your unique identifier. Anonymity is hard.

September 17, 2013

Permalink

Well then why don't you have a warning that clearly tells people the risk in huge red letters and let's them decide before downloading. You are misleading your users. Many of the people, who want to access hidden sites will not realize this is a problem.

The Tor Browser has failed in a really bad way. I obviously don't have numbers but probably 10,000+ of your users were compromised by the FBI. You could do a bit more to warn new users now.

The other thing is, Tor is unusable now, you have to stop this botnet. It's been a month now, the only way it's going to stop is if you build in code to reject requests from older browsers that the botnet uses. You guys really need to get on top of the situation, because secret services and the botnet are whipping you. I'm switching to I2P and hope Tor will exist still when I check back in a couple weeks.

I unfortunately have to agree with this person. As it stands at the moment, TOR is broken and it needs a fix immediately.

It is near impossible to get on hidden services (for some reason, regular public websites that anyone can go to are unaffected) at the moment or it needs 3 or 4 refreshes of the browser.

I believe hidden services are suffering more than normal circuits because they involve on-the-fly circuit extends, and many circuit extend attempts are failing in the Tor network right now. Normal Tor circuits are built preemptively and before you need them, so it's fine if it takes a few tries before it works.

The circuit extend success rate should improve as more relays upgrade to Tor 0.2.4.x (and also, the hidden service as well as you the client need to be on it too). When I get some more time I plan to switch it to be the new stable release, which should help move that trend forward faster.

September 18, 2013

Permalink

the word now is that TOR is a trap ... not sure if you will be able to clean that reputation any time soon.

If people haven't figured out that basically the whole Internet community is under massive attack by large well-funded organizations, who are especially targeting the systems that frustrate their large-scale surveillance... they should learn more.

If you know of some good solution that isn't under attack, that sure would be nice. The world is a bit short on options these days.

September 22, 2013

In reply to arma

Permalink

I got a suggestion, start shooting all federal agents... Period. They have declared war on us but we are not fighting back but I know how much 1st amendment advocates hate the 2nd...????? Not sure how they justify that one but they'll try until confronted with facts

Again, nothing but respect for the Tor devs and it is sickening to see the attacts against arma who responds politely. You guys attacking the devs need to contribute, shut up, grow up, or go find or build a better system.
I mean if idiots like Roger can do it how hard can it be & whats stopping y'all. /s

September 22, 2013

In reply to arma

Permalink

I know a really good solution, stop screwing around and fix tor. You should've fixed it immediately once you saw there was a botnet. You should've just deprecated the entire tor, released a new version and started fresh with that. All you have to do is stop accepting connections from the previous version, this would probably require you to insert one line of code. Have the browser check page tell the users they need to upgrade because the bots have taken over the network. Within a couple days all real users would upgrade. There, problem solved. It's called common sense. Instead it seems to me like you guys are trying to write a PhD thesis on this problem, instead of solve it.

Just one more thing (I'm the OP of the above single post), don't misunderstand I really respect you guys and appreciate what you do, I just do not appreciate how you are handling these attacks. You should have disabled javascript immediatly when the FBI attack started, and warned users. You didn't do this, you were obviously aware of it and let it go on for days without warning users. You should have had an enormous warning on the browser check page that tor is under attack and to disable javascript. And now you're still distributing Tor without a proper warning that tells new users what happened. You're also handling this bot net like an academic case study. So wtf, guys?

September 18, 2013

Permalink

I REALLY NEED A WAY TO VERIFY TAILS>
I have not figured out how pgp works. I need an ap for that! I have no wish to make my daily boreing life known to the NSA! That means that it is of no huge consequence for it to get out. However, I want to be ABLE to have conversations in private. It seems like NSA FUD (Falsehoods Untruths and Deception) to say there is no secure way to get the process done therefore we wont try. What I desparately need is a cut and drag way to check hashes. How for instance do I get the hash for tails 20 to check against the real one? Tails 20 seems to be working well BTW unchecked unverified. Will tails 20 do check the program against the hash for me? Also I tried the version that is supposed to work as a VM. It has a different hash.

I really have no idea how a vm works and would not recognize it if one bit me.

The reason I am interested in the vm is that EFF.org makes heavy use of >.PDF files and tells me that these are not secure unless done in a vm.

Finally I would gladly do more processing to use the 4096 since my $600 8-core Ubuntu machine has most of the processors unused. I would also gladly wait longer for salted connections or split route connections or whatever. Please give us the opportunity and the tools we need!!!!!! Not all connections have to be 1024. Let those running servers decide. I am really bad in Linux!!!!!!!! BUT I WONT GIVE UP!!!

finally this is in the clear because Tor (on my Win 8 machine!) for the first time in a long time says: "The Proxy Is Refusing Connections." And I have no recollection what causes it. and it is not searchable on the tor site. >>>> ....... .......

Anyway TOR IS AWESOME!!!!! Don't let the adversary get you a bent around the axel.

Cheers!!

If you have Ubuntu, you should be able to use gpg (an open source tool functionally equivalent to pgp) to verify signatures. It should already be installed.

In a "line command shell" (technically, probably konsole), try typing

man gpg

To check the signature of a file with a detached signature you need to download the signing key, the detached signature, and the signed file itself.

You will need to install the appropriate signing key into the keyring in your gpg. The command you use will look something like this:

gpg --install keyfile.asc

Next you verify the downloaded file whose detached signature you need to verify. The command you use will look something like this:

gpg --verify file.tar.gz.asc file.tar.gz

Tails' .iso is NOT being served currently from httpS!!
No security on it.

"You have chosen to open:
tails-i386-0.20.1.iso
which is: iso File (883 MB)
from http://dl.amnesia.boum.org"

One's guard is down starting from Tails' download page because that intro IS using httpS: "https://tails.boum.org/download/"

.......................

(btw I'm not the OP and regarding his VM-with-Tor question I thought that was someone else's project, Whonix or such)

Yeah, it would be nice if they could solve that. The trouble is that the tails download page is multi-homed by a bunch of volunteers and they can't (shouldn't) give out an ssl cert to all of them.

The somewhat safer way, that I do it, is to fetch the tails torrent file over their https site. Then bittorrent verifies integrity (assuming you started with the right torrent file). One of the files the torrent gives me is the signature file, which I check manually.

September 21, 2013

In reply to arma

Permalink

Thank you for suggesting this alternative method for Tails download (given their difficulty of providing an httpS download capability).

1.) This seems to be an improvement for all users, including those not yet using GPG for whatever reasons. Correct?

2.) What approach to using torrent safely do you recommend.

(Unfair q. -- boum.org escaping responsibility by not providing a private communication channel for their own version of a private communication product ...feel free to quote me :-)

1) Yes, but it's most an improvement for people who don't check signatures. I hope there aren't any of those.

2) Safely, like, without the RIAA bust down my door? They usually leave me alone when I seed / fetch Linux software. It's just a protocol after all.

September 18, 2013

Permalink

Roger raised an important point above concerning the enemy:

The agency can draw upon the technical skills of thousands of full time employees who work inside the agency itself, often as federal employees, but often as contract employees who can provide specific essential skills. These people include black hat hackers who work in the TAO to develop malware for intruding into specific target computers (for example, key switches in the internet backbone which are owned by a provider which resists legal intimidation, journalist laptops).

But the agency also uses a large number of people with full time jobs in academia (math/CS/physics/ENG professors) for irregular contract work (sometimes in a government site, but often from their usual location while also doing their usual job). The enemy long ago learned that many of the best ideas are out in academia, and that they can best keep tabs on what researchers are currently thinking about by coopting the academic community.

Specifically, since so many posters have expressed (not unreasonable) concern about what our enemy knows that we might not about good/bad curves to use with ECC, many academics who work in number theory on topics which underlie ECC in some way have ties with the enemy. In some cases, the enemy even paid for their graduate education.

Universities love federal handouts and persuading faculties to cut their ties to the enemy will be difficult, particularly at a time of rising costs and decreasing ability of students to pay some of their tuition fees. But some academics have stepped forward to urge such measures, because over the next ten years it could considerably downgrade the enemy's R&D viz our own efforts.

I share the concerns of others here about the ties between Tor Project, Tails Project, and the US federal government, but I don't agree with the posters who have concluded that Tor is so "broken" as to be worse than useless. The post-Snowden evidence is still consistent with the conclusion that when used wisely, Tor can still make things difficult for the enemy, possibly even forcing it to engage in risky illegal practices such as attempting to intrude into Tor nodes. I would just point out that the Tor community can fight back by trying hard to capture and reverse engineer any malware used to infect Tor nodes.

Even the knowledge that the Tor community is doing this will provide some deterrence to the enemy's schemes, because the enemy will be reluctant to unleash its most sophisticated tools once it sees that we can detect and counter less sophisticated ones. In other words, I urge the Tor Project to think about countering the TAO as well as improving handshakes, moving towards using strong ECC, etc. (which are clearly also necessary in the current threat environment).

Roger suggested that concerned Tor users study the Tor-related papers at the freedom host archive, but that is hardly practical for most users, who lack the background needed to follow along. I DO have the background and I HAVE read those papers, and I'd like to try to help educate other Tor users about what they suggest about using Tor less unsafely. But currently the only way to do that appears to be to sign onto a mailing list, but many users are quite rightly reluctant to do that (either to ask questions or to offer answers). Indeed, someone at the Tor Project (I can't remember who) even admitted recently that no-one seems to know any currently effective means of using email with anything approaching reasonable anonymity viz our enemy.

So I hope that the Tor Project will work harder to provide a forum allowing anonymous posting via Tor connections, which is far from perfect (some of the reasons why have been mentioned above), but which appears to be less unsafe than alternative methods of two way communication with the user base. I appreciate that project members would rather work on other issues where it is more clear what is needed right away, but I hope they will consider the view that improving communications with the user base now could possibly improve the Project's ability to become aware of and to tackle other issues in the future. (I would remind them that for many years they resisted warnings from the user base, urgent warnings to update their thread model, warnings which have been thoroughly validated by the Snowden disclosures; some of the reasons why are discussed above.)

I have a question about Tor Browser Bundle: some Linux users have pointed out that when they unpack the Linux tarballs, they find Windows style end of line characters in the torrc and other files, suggesting that TBB is developed under Windows. Is that true? Strange if so because someone at Tor Project (right now I forget who) recently warned against using Tor under Windows owing to various intractable problems in obtaining reasonable security while using a proprietary OS developed by a PRISM partner company.

Thanks. Several clarifications / follow-up points:

> I urge the Tor Project to think about countering the TAO

I think isolating various components (Firefox and Tor in particular) in their own separate VMs will go a long way here. However, the current Tor people don't have the right skills and time to make that happen in a usable, buildable, safe way. We need your (yes, you, the broader community) help.

> Roger suggested that concerned Tor users study the Tor-related papers at the freedom host archive

Please do not confuse http://freehaven.net/anonbib/ with something by the name of 'freedom host'. :)

> So I hope that the Tor Project will work harder to provide a forum allowing anonymous posting via Tor connections

Yeah, me too. We have too few people, and spreading them over "make Tor better", "teach people how to use Tor more safely", and "set up forums and stuff" isn't working out great. We must grow -- that means you.

> I would remind them that for many years they resisted warnings from the user base [...] to update their thread model

I don't think that's a fair statement. Nobody knows how to build a usable network that handles the user base of Tor and provides better anonymity. It's not like we were saying "you folks are wrong, there's no need to defend against that". We were very aware that there are realistic threats we can't defend against. It sucks that that's the state of the technology and the research. (Did I mention you should help?)

September 18, 2013

Permalink

Guys, I have a question/fear in my mind.
I host a tor hidden service, with some nasty content (no, not CP, but otherwise nasty.)

3 days ago my webserver is under some kind of an attack. Somebody (probably a robot) querying my website, once in a second(!), and always the same page. My log is now filled with these GET requests, every 1 or 2 seconds there is one.

These requests coming through the TOR network, firstly because it is originating from 127.0.0.1, secondly because if I shut down Tor, the requests also stopping.

I have a fear. Can it be connected to the NSA/FBI somehow? I mean, why the hell anyone wanna flood me with get requests? It's too slow for a DDOS attack (my website is fully operational).

And speaking of slow, how the hell can a TOR user request anything from my site every one or two seconds?
The TOR network by default is way slower than that. Even if I start pressing the reload button on Tor Browser, it takes 8-10-15 seconds to reconnect and reload the page. And yet, in my log files I see someone who can reload my page every 2 seconds, and does that over 3 days now.

Anybody knows what can it be?
Do I need to fear, is it something with the topic discussed here, or... or what?

Thank you!

My best guess is that it's a researcher trying to look at statistics for hidden services, what they serve, how available they are, etc.

But the next guesses should in fact worry you -- if I were trying to locate a Tor hidden service one of the components of my attack would be "access it frequently, to force it to talk frequently".

As for the speed thing, Tor actually has not-bad latency these days, if you can get your circuit built (using Tor 0.2.4.x will help a lot there), and if you're using a recent enough Tor Browser so it uses the optimistic begin cells:
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/174-opti…
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/181-opti…

September 20, 2013

In reply to arma

Permalink

Another theoretical explanation to that could be a form of "tagging": the hidden server machine could be later identified, if this known pattern is found in some connection log.

To the "scared" operator: do you hear the cop cars pulling in the driveway yet? ;-)
Seriously, do us all a favor - don't use the Tor network for any nasty purpose. You'll sleep better.

Seems like a pretty funny-shaped tag. Why not stick a unique number in the user-agent, or the page it's asking for, etc? And then ask only once. That would be a much more robust, and much tinier, tag.

September 18, 2013

Permalink

I'm afraid. What if you ll force to collaborate (and force to be silent by court)? This currently has happened to many american companies.

I answered this one here:
https://blog.torproject.org/blog/calea-2-and-tor

"We should all keep in mind that they can't force us to do anything. You always have the alternative of stopping whatever it is you're doing."

And I even wrote that before Lavabit et al. :/

To make it clearer, they will not force us to collaborate. And we won't stay silent.

You're right that it *has* happened to many American companies, and that sucks. It also means that those companies had different priorities than you and I think they should have.

September 18, 2013

Permalink

Much of what has been discussed above is beyond my level of expertise at this time; however, thankfully you have already considered this and provided a way for those of who might feel discouraged...to still be able to participate and not feel quite so...well, dumb?

When I scrolled through comments and arrived at the bottom of the page...there it was...a simple addition problem and upon successful completion of said math problem. ..I found myself here...in thev land of our most brilliant and technological geniuses. ..now I could be proud. ..because I was now in the room...at the party...and sitting at the cool guys table. It seemed as though all was right in the world...and I did belong here...even if...I only understood the math!

lol...thank you all for sharing your knowledge and expertise, as I am forever in your debt. Hopefully. ..you will have gotten a smile from this...and continue to be patient, as we continue to listen to all you have to share. :-)

God bless...and Goodnight!

September 19, 2013

Permalink

My comments are not appearing. Is the reason that I wanted to discuss the issue of the NSA internship?

September 19, 2013

Permalink

Good job, but i'd like to say that the "guardianproject" that distributes the Android version of Tor is TOTALLY INCOMPETENT and it's can also be DANGEROUS to use, for some people:
the Tor version they distribute via their F-droid repo is DATED *2012* !!
And right now i noticed that the "switch user-agent" feature is buggy and LEAKS my phone model and the language if i choose "android" or "nokia" as user agents.

Please, torproject, be careful while choosing who distributes your software.
Guardianproject is seriously damaging the public image of Tor and the Torproject.
GP diistributes a (seemengly by purpouse) BUGGY AND INSECUREversion of Tor and is endangering the privacy of dissident in the world (remember: FULL dev name and real language leakage)

Written by a user that from now on will only use the PC version of Tor, since a SECURE Android version DOESNT EXIST right now

Actually, Tor 0.2.3.25 is the current stable release of Tor, and we released it on 2012-11-19. So don't be upset with them about that.

If you want to be nervous about Orbot, be nervous that they don't include all the browser-level privacy fixes that Tor Browser has.

Confirm that Orbot/Orweb browser leaks my phone model, Android Version and build info in an added (by the browser itself) HTTP WAP header. That's ridiculous.

Further investigation shows that Orweb is leaking verbatim certain values from android build.conf if they are present into HTTP headers.. After a quick search I further note there are active bug reports in their system on this problem.

Seems Orbot/Orweb is very much a work in progress.

September 22, 2013

In reply to arma

Permalink

Would be good if there could be a hookup. The leaking headers (from Android's build.prop) bug reports seem to have been open for months so I'm not sure how much developer time they have available to work on problems.. Rooted phone users can remove the constants from build.prop as a workaround. I doubt anyone is really worried about WAP configuration these days.

September 19, 2013

Permalink

Tails is developed at boum.org, but they currently provide no web feedback, so I hope the Tor developers will get some important feedback to them.

Please let the Tails developers know that on their download page, the detached signature for the Tails 0.20.1 iso (released 19 Sept 2013) points to the signature for the torrent (not the iso) and in any case both signatures appear to be missing!

Once this problem is fixed, anyone using Mac or Linux OS should be able to download

* the iso image
* the detached signature
* the signing key

and follow directions to

* import the Tails signing key into your local GPG keyring
* verify the detached signature
* burn a bootable DVD using the iso image

Windows users should keep in mind that there is no way to download GPG without using an unknown .exe. If possible they should obtain another live Linux distro such as Knoppix and use that to obtain Tails.

Another suggestion for Tails: consider an alternative detached signature using seccure with the maximal sized curve. This at least would avoid keyrings at the cost of requiring users to download and use seccure. I suggest it only as an alternative signature mode, not the default.

September 20, 2013

Permalink

Is it not better to build a world with more LOVE!...many people and also people that have power are not filled with love but with HATE, they want to know what other people do and want to manipulate them.

What's wrong with those people?, we can build a better world with for example respect for other people's religion and other things in life.

We now mostly fight the symptoms but you will fight till infinity and that's taking a lot of energy, we can better give our energy to spread love and acceptance for other people..(win win situation)

September 20, 2013

Permalink

This is a huge media blow to Tor, more like a scandal revealed to the general public whom often do not read any further than Tor's front page which states "Tor prevents anyone from learning your location or browsing habits".

There are no clear warnings on the front page of Tor's limitations and that is made intentionally to promote the project, and this worked quite a while for overly excited lazy people.

For the more experienced, the weaknesses have been long known, so there isnt much of a surprise there. The NSA is too much ahead of Tor, so if you are up against them it would be wise to stop using the internet.

Hope this comment isn't too much for anti-censorship claiming fellas and would actually make it unscathed.

Yeah, if the NSA is targeting you, "stop using the Internet" is a very reasonable step. Tor isn't going to help much. And there are many other technologies you should stop using as well.

We used to have a pile of warnings on the download page, about anonymity risks. They're still there:
https://www.torproject.org/download/download#warning
but they've been simplified over time because too many users were confused.

Our website is definitely suffering from trying to be understandable by too many audiences.

My rough plan for resolving this, short to medium term, is:

A) Finish my blog post about why we need to raise the guard rotation parameters, which should improve anonymity a lot against these large-scale adversaries. Oh, and start to actually take the steps I'll suggest.

B) Go through the new FAQ entries that Matt merged in from the wiki faq, and try to make them accurate and useful again.

C) Write a FAQ entry, or maybe a new page, explaining what anonymity properties Tor can and can't provide, including pointers to attacks that are known in the research literature. I worry that step 'C' by the time it's done will produce something hard for the normal user to understand. I guess we'll see.

September 21, 2013

In reply to arma

Permalink

"TOR CANNOT PROTECT YOU AGAINST NSA SURVEILLANCE"

in red, caps, bold, and at a clear spot on the front page is simple enough

That is if being honest surpasses the need for misleading marketing

Well, for one because that's a false statement too.

Notice that I said "if they're targeting you" above. Then they bust out the TAO team and it no longer matters that Tor is in the picture.

I think there are some user scenarios where Tor helps a great deal even against large scale surveillance like the kind NSA is doing.

And some cases where the large scale surveillance is in the right places, and assuming they do their math well enough they can link you to your destinations.

I'd rather try to explain the underlying issues that people need to consider, since no single sentence is going to be the right thing to say.

It's complicated by the fact that every time we do anything public like that we get swamped by journalists who write partially accurate articles and cause more journalists to swamp us. (And the 'us' is the Tor developers, so we're trading off fixing the actual problems in Tor for trying to correct press articles.) That happens in large part because we got behind on explaining research results to everybody, and so now they're shocked and excited every time they hear from us. Bad cycle to be in. Hopefully I will get to my plan in not too long and then I can stop trying to explain why I haven't gotten there yet.

September 24, 2013

In reply to arma

Permalink

I'd like to add another voice of appreciation to arma's work here.

The crush he describes of being caught between press/media outreach and "doing real work" is one that anyone on the front lines knows all too well. It would seem he's experiencing it, along with the rest of the Tor folks, at an almost unimaginable level.

It is indeed a Good Thing to patiently talk with the press - who are actually human beings, individual people - to help them understand how all this works and why it matters. It also takes an enormous amount of one's time - far more than it would seem to those who read the articles and see a quote or two, nothing more. Almost without exception, that was a few hours' time talking with the reporter and that work is invisible to the public eye.

But to say "too busy for you press folks, go away!" is also simply not an option as they will write their stories anyway, but the stories will be even more technically inaccurate as a result. And people rely on the press - normal, nontechnical folks - to tell these stories. If we just wash our hands of the press, then we're washing our hands of most human beings using the internet, period. That is not an option.

Folks with the expertise and professionalism of arma could be, let us not forget for a minute, making vast sums of money working for Vupen or some other cyberwar drum-beater: stable hours, no political pressure, executive assistant to open the mail and bring coffee... honestly, this is the alternative for talented folks. That he is working to make Tor as good as it can be, with all the other pressures, is a testament to an integrity of spirit and true dedication.

As we say elsewhere, this recent round of anti-Tor hits does not seem at all to be just a random confluence of events. Not to us. For those with experience in the darker sides of how folks with power strike back against those who threaten them, this is all of a piece. And arma is doing his absolute best to handle it all whilst still producing quality code & managing a team of talented folks working on some not-simple technical challenges. This is an extraordinary burden to be carrying.

We may not always agree with how "Tor" is doing this or that - and I personally may have my own views on this or that - but that is all picayune relative to the respect the Tor folks have long-since earned from all of us. Tor is facing an organized, multi-pronged, dirty-war disinfo/extra-legal harassment campaign right now and so far they are (in my opinion) weathering it with courage, competence, integrity, and wisdom. There is much to learn from their handling of this round of attacks thus far.

There is also a need for all of us to thank them for what they do.

~ pattern_juggled | http://cryptostorm.is

October 14, 2013

In reply to arma

Permalink

there has been no mention of Whonix as far as I can tell. Having an open OS wthin a VM is a great way to prevent a large chunk of how NSA/GCHQ resolves a users identity/location. From what I've read they rely heaily on exploits and hacks.

I mentioned it in

https://blog.torproject.org/blog/tor-security-advisory-old-tor-browser-…
https://lists.torproject.org/pipermail/tor-announce/2013-August/000089…

Whonix needs more people looking at it, and being able to build it also, before we can comfortably recommend it to a larger audience. The idea is good, but that doesn't mean enough about the implementation.

Ok, I added this statement at the top of the announcements:

"It may be that Tor can't protect you against the NSA's large-scale Internet surveillance, and it may be that no existing anonymous communication tool can. We're working on writing clear explanations for the issues."

Can it be said better?

(I also took the opportunity to tidy up some other big words on the page.)

arma

September 21, 2013

In reply to arma

Permalink

Nick changed what I wrote to something much complexer. I wonder which one is better, for all definitions of better.

September 20, 2013

Permalink

I make some observations and pose questions.

I don't see evidence in the media of people (I suppose that is mainly journalists) thinking through the consequences of the NSA/GCHQ revelations. Now that the Jo Public knows what technically savvy people have long suspected I would expect action to be added to outcry. We now know what only a dedicated conspiracy theorist hitherto would opine. We know that some software/hardware manufacturers have connived in the insertion of "back doors" and that others have unwittingly been compromised.

So, my first question is why isn't there a stampede of people trying to rid themselves of closed source proprietary software, not just operating systems but that which runs on them too? The person who just does a bit of web surfing and social contact via "social media" probably isn't too bothered that their activities will bore the socks off human operatives at NSA/GCHQ.

Professional people, particularly those holding records about individual "clients", whether at the office or at home, should be seething with anger and avidly seeking means of greater security. Large businesses should be worried about the safety of their legitimate commercial secrets. Such businesses have ready access to IT staff and I would imagine that board rooms seethe with anxiety and urgency; if so, no hint has been published.

As a number of organisations has found, e.g. the French police force, the initial costs of transition to open source software are vastly offset by long term saving on unnecessarily bloated, leaking like a sieve (regardless of NSA actions), costly software and by stepping off the treadmill of proprietary upgrades.

Similarly, what idiot would "upgrade" to Windows 8 installed on a machine with a special (hackable from outside) DRM chip on the custom made motherboard?

Perhaps complacency rules. However, I suggest that everyone reading this divest from shares in companies that rely on income from closed source software. Goodbye Microsoft, goodbye Apple and goodbye Adobe? Closed source software will become a thing of the past. Community supported (and checked) software will dominate. In future people will laugh at the notion of software patents and intellectual property (though attribution should remain).

I was with you until the very end. It's not clear to me that stock market performance has much at all to do with technical quality of the company's products.

"Teach your friends why closed and proprietary software is so dangerous" would maybe have a much bigger effect.

September 21, 2013

Permalink

blame it on the drugs!! (everything else is and it is the only subject in the world that is treated as voodoo. e.g. tor project may have fallen into a giant k-hole?

September 21, 2013

Permalink

anonymous34 said...and i quote nsa stands for national.stupid.apartite!.. is this true or am i being obtuse? (personaly i support all government agencies as they only have our interests at heart) we need to be told what to do for our own good! if not it is anarchy, isn't it? and as long as its not my human rights violated-'who cares?' as my daaddy would say.

all government agencies as they only have our interests at heart

sounds like the apple didn't fall far from the stupid tree. ignore if /s but it didn't sound like /s

Nsa + Facebook = Stasi2.0
They *alter* user traffic injecting *malware* to own user computers!
http://rt.com/news/spy-agency-telecoms-access-966/
http://www.sueddeutsche.de/digital/internet-ueberwachung-snowden-enthue…

you're sarcastic here, but the problem is that people with such 'naive' thought to believe that:

"personally i support all government agencies as they only have *our* interests at heart"

really exist!

The sourveillance apparate has *always* followed *only* big corporations agenda.

just a note:
"[...] if not it is *anarchy*, isn't it"

i dont know what you think *anarchy* is, but if you really think it's something to have fear about ... i suggest you read something serious about it, like Petr Kropotkin, Errico Malatesta, just to start.

"Common" people have nothing to fear about anarchy 'cause it's a social model/organization based on freedom *and* equality.

("common people" = people that are not part of the top of the pyramid, aka "not at the guide of the corporations")

September 22, 2013

Permalink

Why not think of all the good things about TOR? It is used in some countries that people are not allowed to have freedom of speech and would be tortured/killed for speaking out. It seems a few people using sites that had illegal content are annoyed at somehow being "tricked". There are many warnings about TOR. How many people used programs to download files for example? Those programs could have "phoned home" or stored information to reveal what users had done.
It is possible that GCHQ, NSA, FBI, MI5/MI6 and whoever else is involved can decrypt and read data and identify users. TOR is not a tool to use for breaking the Law! It will not protect you.

I was with you until the last sentence.

I'd love to live in a world where "the law" was universally agreed upon and only good laws existed. Actually, on second thought, maybe I don't want to live in that world either. In any case, there is no single "the law" to look at.

(To give you a concrete example, consider "the law" in Pakistan against using VPNs.)

December 31, 2013

Permalink

Getting philosophical, what is a law but one man's ideals forced upon another's rights. Just kidding. I think Tor is a great tool if you need to have un-compromised internet