tor-dev

tor-dev@lists.torproject.org

5 participants
3594 discussions

HSDir Auth and onion descriptor scraping
by grarpamp 10 Nov '14

10 Nov '14

> George K: > I suspect that HS authorization is very rare in the current network, > and if we believe it's a useful tool, it might be worthwhile to make > it more useable by people. Is anyone making their HSDir onion descriptor scraping patches available somewhere? I'd suspect the rarity of HS authorization could also be determined with that since some fields would be obfuscated and thus not match patterns. s/scraping/logging/ rend--spec.txt: 2. Authentication and authorization. 2.1. Service with large-scale client authorization 2.2. Authorization for limited number of clients 2.3. Hidden service configuration 2.4. Client configuration

3 4

Running a Separate Tor Network
by Tom Ritter 10 Nov '14

10 Nov '14

Hi all, Not content to let you have all the fun, I decided to run my own Tor network! Kidding ;) But the Directory Authorities, the crappy experiment leading up to Black Hat, and the promise that one can recreate the Tor Network in the event of some catastrophe interests me enough that I decided to investigate it. I'm aware of Chutney and Shadow, but I wanted it to feel as authentic as possible, so I forwent those, and just ran full-featured independent tor daemons. I explicitly wanted to avoid setting TestingTorNetwork. I did have to edit a few other parameters, but very few. [0] I plan on doing a blog post, giving a HOWTO, but I thought I'd write about my experience so far. I've found a number of interesting issues that arise in the bootstrapping of a non-TestingTorNetwork, mostly around reachability testing. ----- One of the first things I ran into was a problem where I could not get any routers to upload descriptors. An OR checks itself to determine reachability before uploading a descriptor by building a circuit - bypassed with AssumeReachable or TestingTorNetwork. This works fine for Chutney and Shadow, as they reach into the OR and set AssumeReachable. But if the Tor Network were to be rebooted... most nodes out there would _not_ have AssumeReachable, and they would not be able to perform self-testing with a consensus consisting of just Directory Authorities. I think nodes left running would be okay, but nodes restarted would be stuck in a startup loop. I imagine what would actually happen is Noisebridge and TorServers and a few other close friends would set the flag, they would get into the consensus, and then the rest of the network would start coming back... (Or possibly a few nodes could anticipate this problem ahead of time, and set it now.) What I had to do was make one of my Directory Authorities an exit - this let the other nodes start building circuits through the authorities and upload descriptors. Maybe an OR should have logic that if it has a valid consensus with no Exit nodes, it should assume it's reachable and send a descriptor - and then let the Directory Authorities perform reachability tests for whether or not to include it? From the POV of an intentional DoS - an OR doesn't have to obey the reachability test of course, so no change there. It could potentially lead to an unintentional DoS where all several thousand routers start slamming the DirAuths as soon as a usable-but-blank consensus is found... but AFAIK routers probe for a consensus based on semi-random timing anyway, so that may mitigate that? ----- Another problem I ran into was that nodes couldn't conduct reachability tests when I had exits that were only using the Reduced Exit Policy - because it doesn't list the ORPort/DirPort! (I was using nonstandard ports actually, but indeed the reduced exit policy does not include 9001 or 9030.) Looking at the current consensus, there are 40 exits that exit to all ports, and 400-something exits that use the ReducedExitPolicy. It seems like 9001 and 9030 should probably be added to that for reachability tests? ----- Continuing in this thread, another problem I hit was that (I believe) nodes expect the 'Stable' flag when conducting certain reachability tests. I'm not 100% certain - it may not prevent the relay from uploading a descriptor, but it seems like if no acceptable exit node is Stable - some reachability tests will be stuck. I see these sorts of errors when there is no stable Exit node (the node generating the errors is in fact a Stable Exit though, so it clearly uploaded its descriptor and keeps running): Oct 13 14:49:46.000 [warn] Making tunnel to dirserver failed. Oct 13 14:49:46.000 [warn] We just marked ourself as down. Are your external addresses reachable? Oct 13 14:50:47.000 [notice] No Tor server allows exit to [scrubbed]:25030. Rejecting. Since ORPort/DirPort are not in the ReducedExitPolicy, this (may?) restrict the number of nodes available for conducting a reachability test. I think the Stable flag is calculated off the average age of the network though, so the only time when this would cause a big problem is when the network (DirAuths) have been running for a little bit and a full exit node hasn't been added - it would have to wait longer for the full exit node to get the Stable flag. ----- Getting a BWAuth running was... nontrivial. Some of the things I found: - SQLAlchemy 0.7.x is no longer supported. 0.9.x does not work, nor 0.8.x. 0.7.10 does. - Several quasi-bugs with the code/documentation (the earliest three commits here: https://github.com/tomrittervg/torflow/commits/tomedits) - The bandwidth scanner actively breaks in certain situations of divide-by-zero (https://github.com/tomrittervg/torflow/commit/053dfc17c0411dac0f6c4e43954f9…) - The scanner will be perpetually stuck if you're sitting on the same /16 and you don't perform the equivalent of EnforceDistinctSubnets 0 [1] Ultimately, while I successfully produced a bandwidth file [2], I wasn't convinced it was meaningful. There is a tremendous amount of code complexity buried beneath the statement 'Scan the nodes and see how fast they are', and a tremendous amount of informational complexity behind 'Weight the nodes so users can pick a good stream'. ----- I tested what it would look like if an imposter DirAuth started trying to participate in the consensus. It generated the warning you would expect: Oct 14 00:04:31.000 [warn] Got a vote from an authority (nickname authimposter, address W.X.Y.Z) with authority key ID Z. This key ID is not recognized. Known v3 key IDs are: A, B, C, D But it also generated a warning you would not expect, and sent me down a rabbit hole for a while: Oct 10 21:44:56.000 [debug] directory_handle_command_post(): Received POST command. Oct 10 21:44:56.000 [debug] directory_handle_command_post(): rewritten url as '"/tor/post/consensus-signature"'. Oct 10 21:44:56.000 [notice] Got a signature from W.X.Y.Z. Adding it to the pending consensus. Oct 10 21:44:56.000 [info] dirvote_add_signatures_to_pending_consensus(): Have 1 signatures for adding to ns consensus. Oct 10 21:44:56.000 [info] dirvote_add_signatures_to_pending_consensus(): Added -1 signatures to consensus. Oct 10 21:44:56.000 [info] dirvote_add_signatures_to_pending_consensus(): Have 1 signatures for adding to microdesc consensus. Oct 10 21:44:56.000 [info] dirvote_add_signatures_to_pending_consensus(): Added -1 signatures to consensus. Oct 10 21:44:56.000 [warn] Unable to store signatures posted by W.X.Y.Z: Mismatched digest. Over on the imposter: Oct 14 00:19:32.000 [warn] http status 400 ("Mismatched digest.") response after uploading signatures to dirserver 'W.X.Y.Z:15030'. Please correct. The imposter DirAuth is sending up a signature for a consensus that is not the same consensus that the rest of the DirAuths computed. Specifically, the imposter DirAuth lists itself as a dir-source and the signature covers this line. (Everything else matches because the imposter has been outvoted and respects that.) I guess the lesson is, if you see the "Mismatched digest" warning in conjunction with the unrecognized key ID - it's just one issue, not two. ----- The notion and problems of an imposter DirAuth also come up during how the network behaves when adding a DirAuth. I started with 4 authorities, then started a fifth (auth5). Not interesting - it behaved as the imposter scenario. I then added auth5 to a single DirAuth (auth1) as a trusted DirAuth. This resulted in a consensus with 3 signatures, as auth1 did not sign the consensus. On auth1 I got warn messages: A consensus needs 3 good signatures from recognized authorities for us to accept it. This one has 2 (auth1 auth5). 3 (auth2 auth3 auth4) of the authorities we know didn't sign it. I then added auth5 to a second DirAuth (auth2) as a trusted DirAuth. This results in a consensus for auth1, auth2, and auth5 - but auth3 and auth4 did not sign it or produce a consensus. Because the consensus was only signed by 2 of the 4 Auths (e.g., not a majority) - it was rejected by the relays (which did not list auth5). At this point something interesting and unexpected happened: The other 2 DirAuths (not knowing about auth5) did not have a consensus. This tricked dirvote_recalculate_timing into thinking we should use the TestingV3AuthInitialVotingInterval parameters, so they got out of sync with the other 3 DirAuths (that did know about auth5). That if/else statement seems very odd, and the parameters seem odd as well. First off, I'm not clear what the parameters are intended to represent. The man page says: TestingV3AuthInitialVotingInterval N minutes|hours Like V3AuthVotingInterval, but for initial voting interval before the first consensus has been created. Changing this requires that TestingTorNetwork is set. (Default: 30 minutes) TestingV3AuthInitialVoteDelay N minutes|hours Like TestingV3AuthInitialVoteDelay, but for initial voting interval before the first consensus has been created. Changing this requires that TestingTorNetwork is set. (Default: 5 minutes) TestingV3AuthInitialDistDelay N minutes|hours Like TestingV3AuthInitialDistDelay, but for initial voting interval before the first consensus has been created. Changing this requires that TestingTorNetwork is set. (Default: 5 minutes) Notice that the first says "Like V3AuthVotingInterval", but the other two just repeat their name? And how there _is no_ V3AuthInitialVotingInterval? And that you can't modify these parameters without turning on TestingTorParameters (despite the fact that they will be used without TestingTorNetwork?) And also, unrelated to the naming, these parameters are a fallback case for when we don't have a consensus, but if they're not kept in sync with V3AuthVotingInterval and their kin - the DirAuth can wind up completely out of sync and be unable to recover (except by luck). It seems like these parameters should be renamed to V3AuthInitialXXX, keep their existing defaults, remove the requirement on TestingTorNetwork, and be documented as needing to be divisors of the V3AuthVotingXXX parameter, to allow a DirAuth who has tripped into them to be able to recover. I have a number of other situations I want to test around adding, subtracting, and manipulating traffic to a DirAuth to see if there are other strange situations that can arise. ----- Other notes: - I was annoyed by TestingAuthDirTimeToLearnReachability several times (as I refused to turn on TestingTorNetwork) - I wanted to override it. I thought maybe that should be an option, but ultimately convinced myself that in the event of a network reboot, the 30 minutes would likely still be needed. - The Directory Authority information is a bit out of date. Specifically, I was most confused by V1 vs V2 vs V3 Directories. I am not sure if the actual network's DirAuths set V1AuthoritativeDirectory or V2AuthoritativeDirectory - but I eventually convinced myself that only V3AuthoritativeDirectory was needed. - It seems like an Authority will not vote for itself as an HSDir or Stable... but I could't find precisely where that was in the code. (It makes sense to not vote itself Stable, but I'm not sure why HSDir...) - The networkstatus-bridges file is not included in the tor man page - I feel like the log message "Consensus includes unrecognized authority" (currently info) is worthy of being upgraded to notice. - While debugging, I feel this patch would be helpful. [3] - I've had my eye on Proposal 164 for a bit, so I'm keeping that in mind - I wanted the https://consensus-health.torproject.org/ page for my network, but didn't want to run the java code, so I ported it to python. This project is growing, and right now I've been editing consensus_health_checker.py as well. https://github.com/tomrittervg/doctor/commits/python-website I have a few more TODOs for it (like download statistics), but it's coming along. ----- Finally, something I wanted to ask after was the idea of a node (an OR, not a client) belonging to two or more Tor networks. From the POV of the node operator, I would see it as a node would add some config lines (maybe 'AdditionalDirServer' to add to, rather than redefining, the default DirServers), and it would upload its descriptors to those as well, fetch a consensus from all AdditionalDirServers, and allow connections from and to nodes in either. I'm still reading through the code to see which areas would be particularly confusing in the context of multiple consensuses, but I thought I'd throw it out there. -tom ----- [0] AuthoritativeDirectory 1 V3AuthoritativeDirectory 1 VersioningAuthoritativeDirectory 1 RecommendedClientVersions [stuff] RecommendedServerVersions [stuff] ConsensusParams [stuff] AuthDirMaxServersPerAddr 0 AuthDirMaxServersPerAuthAddr 0 V3AuthVotingInterval 5 minutes V3AuthVoteDelay 30 seconds V3AuthDistDelay 30 seconds V3AuthNIntervalsValid 3 MinUptimeHidServDirectoryV2 1 hour ----- [1] diff --git a/NetworkScanners/BwAuthority/bwauthority_child.py b/NetworkScanners/BwAuthority/bwauthority_child.py index 28b89c2..e07718f 100755 --- a/NetworkScanners/BwAuthority/bwauthority_child.py +++ b/NetworkScanners/BwAuthority/bwauthority_child.py @@ -60,7 +60,7 @@ __selmgr = PathSupport.SelectionManager( percent_fast=100, percent_skip=0, min_bw=1024, - use_all_exits=False, + use_all_exits=True, uniform=True, use_exit=None, use_guards=False, ----- [2] node_id=$C447A9E99C66A96E775A5EF7A8B0DF96C414D0FE bw=37 nick=relay4 measured_at=1413257649 updated_at=1413257649 pid_error=0.0681488657221 pid_error_sum=0 pid_bw=59064 pid_delta=0 circ_fail=0.0 node_id=$70145044B8C20F46F991B7A38D9F27D157B1CB9D bw=37 nick=relay5 measured_at=1413257649 updated_at=1413257649 pid_error=0.0583026021009 pid_error_sum=0 pid_bw=59603 pid_delta=0 circ_fail=0.0 node_id=$7FAC1066DCCC0C62984B8E579C5AABBBAE8146B2 bw=37 nick=exit2 measured_at=1413257649 updated_at=1413257649 pid_error=0.0307144741235 pid_error_sum=0 pid_bw=55938 pid_delta=0 circ_fail=0.0 node_id=$9838F41EB01BA62B7AA67BDA942AC4DC3B2B0F98 bw=37 nick=exit3 measured_at=1413257649 updated_at=1413257649 pid_error=0.0124944051714 pid_error_sum=0 pid_bw=55986 pid_delta=0 circ_fail=0.0 node_id=$49090AC6DB52AD8FFF95AF1EC1E898126A9E5CA6 bw=37 nick=relay3 measured_at=1413257649 updated_at=1413257649 pid_error=0.0030073731241 pid_error_sum=0 pid_bw=56489 pid_delta=0 circ_fail=0.0 node_id=$F5C43BB6AD2256730197533596930A8DD7BEC367 bw=37 nick=exit1 measured_at=1413257649 updated_at=1413257649 pid_error=-0.0032777385693 pid_error_sum=0 pid_bw=55114 pid_delta=0 circ_fail=0.0 node_id=$3D53FF771CC3CB9DE0A55C33E5E8DA4238C96AB5 bw=37 nick=relay2 measured_at=1413257649 updated_at=1413257649 pid_error=-0.0418210520821 pid_error_sum=0 pid_bw=51021 pid_delta=0 circ_fail=0.0 ----- [3] diff --git a/src/or/networkstatus.c b/src/or/networkstatus.c index 890da0a..4d72add 100644 --- a/src/or/networkstatus.c +++ b/src/or/networkstatus.c @@ -1442,6 +1442,8 @@ networkstatus_note_certs_arrived(void) waiting_body, networkstatus_get_flavor_name(i), NSSET_WAS_WAITING_FOR_CERTS)) { + log_info(LD_DIR, "After fetching certificates, we were able to " + "accept the consensus."); tor_free(waiting_body); } }

3 3

Pluggable-transport implementations of your website fingerprinting defenses
by David Fifield 09 Nov '14

09 Nov '14

NB I'm copying the tor-dev mailing list on this message. At CCS I saw Rishab present these papers: "CS-BuFLO: A Congestion Sensitive Website Fingerprinting Defense" http://www3.cs.stonybrook.edu/~rnithyanand/pubs/wpes2014-csb.pdf "Glove: A Bespoke Website Fingerprinting Defense" http://www3.cs.stonybrook.edu/~rnithyanand/pubs/wpes2014-glove.pdf "A Systematic Approach to Developing and Evaluating Website Fingerprinting Defenses" http://www3.cs.stonybrook.edu/~rnithyanand/pubs/ccs2014.pdf I spoke quite a lot to Rishab and suggested, since these schemes have source code, that they be wrapped in a pluggable transports interface so they can be easily used by tor clients. It is not super difficult to turn a network program into a pluggable transport, as there are libraries like pyptlib and liballium that implement the internal pluggable transports protocol. You might be familiar with wfpadtools (https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools), which aims to make it easy to prototype fingerprinting defenses by specifying them in terms of (e.g. padding) primitives. I looked for the source code mentioned in the papers and I wasn't sure what would be best to use. I found https://crysp.uwaterloo.ca/software/webfingerprint/ which links to some short Python files like https://crysp.uwaterloo.ca/software/webfingerprint/tamaraw.py There is also https://github.com/xiang-cai/CSBuFLO but it doesn't appear to be directly usable. It appears to be a modified OpenSSH, without a commit history showing what was modified. What source code do you recommend for an implementation? David Fifield

1 0

Hi everyone!
by Conny Hermansson 09 Nov '14

09 Nov '14

Hi! I´m new to the Tor project and I´m looking for some easy project to get me started. preferebly in Java, I can do debugging or write some code. Conny

2 1

yes hello, internet supervillain here
by Fears No One 09 Nov '14

09 Nov '14

Sorry in advance for the length. I just want to make sure that everything is included. If you have any questions/clarifications, just ask. It isn't every day that someone like me pops up on tor-dev, and I just want to make sure this is as productive and helpful as possible. This will probably be a very humbling experience, because unlike my fellow illegal onion operators both past and present, I will actually be outside of a jail cell and able to read the ruthless dissection of my set-up. On the bright side, you're all are getting way more info from me than the pigs will ever willingly cough up, which means if they have some sort of magic onion decloak trick, this mailing list discussion is a good chance at finding it. All of these files are in the hands of the cops anyway (And I have no plans of bringing doxbin back), so there are 0 real-time opsec concerns. First, the files: http://doxbin.strangled.net/ http://qhlkmirbijvet2dp.onion/ sha256 and sha512 checksums for all the files are at the bottom. NOTE: This isn't my box and I didn't set it up. WARNING: The .xz files will unpack to roughly 1 GB. Some other info: 1. The box (An OpenVZ VPS) was hosted with Hetzner in Germany. People on Twitter keep asking if the box was in Bulgaria, but we didn't use Bulgaria for one simple reason: The very first doxbin box (Bought in 2011) was with a VPS company in Bulgaria. After the first month, they said "TOR IS ILLEGAL" (I shit you not), killed the box, and kept the $5 we had paid for the 2nd month. Can't say I blame them. 2. It wasn't transproxied. We did this once before, but it became a hassle to drop iptables rules just to upgrade tor, especially when tor was getting regular updates semi-recently. Console access with VPS companies generally requires java plugins or something just as gross, so there aren't a lot of sane options here. It gets annoying when there's a surge in the frequency of tor upgrades, so we stopped transproxying the box. inb4 OMG OPSEC MISTAKE DETECTED!!!11 3. This script (And copypasta that contained its important parts) was used to build nginx for the various boxes from roughly November 2011 to mid-October 2014: http://pastebin.com/dBC7E8Jd Early versions didn't use naxsi, and sed replaced the server banners in the source before compiling. Yes, I know it doesn't verify the source. See the next point: 4. Around 2 weeks ago, I started grabbing dotdeb.org's source versions of nginx and building .debs using hardening-wrapper with the following command at the end: DEB_CFLAGS_SET="-O2 -fstack-protector-all -fforce-addr -ffast-math -fomit-frame-pointer -falign-functions=64 -falign-loops=32" dpkg-buildpackage -uc -us -j8 5. The tor build was from deb.torproject.org. I'm not able to check the box and never thought to back up /etc/apt/sources, but it used the experimental-wheezy repo. All updates were done within 24 hours of the new .debs going live. 6. Last but not least, the elephant in the room: The php is a headache-inducing nightmare. I inherited the code and it worked, so I just papered over its defects over the years (There was no anti-flood protection originally, for example) and built it up to resemble Kowloon Walled City expressed in php. I have a feeling that a lot of focus is going to be placed on the code, to the detriment of finding any possible tor bugs. In any case, everything about doxbin's setup is being disclosed in the spirit of making this an interesting learning experience for all parties involved. BEGIN TINFOIL Upon scrolling through the .xz files (I personally use xzless), you'll find a bunch of stuff like: 1 /%5C%22http://www.hackforums.net/code/fail/code/code/code/code/code/code/old/code/old/code/old/code/code/old/fail/fail/code/fail/fail/fail/fail/fail/fail/code/old/code/old/code/fail/fail/old/old/old/code/code/fail/fail/code/code/fail/old/code/old/old/code/code/fail/code/code/code/old/old/code/code/old/old/old/code/old/fail/fail/old/code/code/old/code/code/code/fail/code/code/code/fail/code/code/fail/fail/old/code/code/code/code/code/code/old/fail/code/code/code/old/code/fail/old/fail/code/code/fail/old/code/fail/fail/code/code/code/code/fail/fail/code/code/old/old/code/code/old/old/old/code/code/old/code/old/code/code/old/old/old/old/code/code/fail/code/old/fail/code/old/code/code/code/code/fail/code/code/code/code/code/code/old/code/code/fail/code/code/code/code/code/code/old/code/fail/fail/fail/code/fail/old/fail/old/fail/old/fail/code/code/fail/fail/fail/code/code/code/fail/code/code/old/code/code/old/fail/fail/code/old/old/fail/old/code/old/old/old/old/old/old/old/pgp.txt All of the requests were around (If I recall correctly) 3KB in size. Oddly enough, it caused tor to hiccup pretty badly, although the web server itself was just fine and I didn't have any network bandwidth problems (i.e. No obscene traffic spikes). It's also worth pointing out that the tcp buffers weren't even close to maxed. The same box has handled a similar volume of legitimate requests before (Namely back in March, after The Hidden Wiki debacle; see https://twitter.com/loldoxbin/status/530765088366821377). The solution to getting tor availability back was to set ConstrainedSockets to 1 and play with ConstrainedSockSize (Originally set to 8192, then 4096). This made doxbin regularly available again, whereas before it was hit or miss. Once the requests stopped, I waited a couple of days before commenting those two config lines out and reloaded tor. A month later, the same kinds of requests started coming in again. After the first few hours, I started 301 redirecting all requests containing /%5C%22 to the new Hidden Wiki's Hard Candy page. I also added a grep -v to my log report script in order to filter out the noise (Possibly a mistake, but we both tailed logs and watched for something like a different attack style that the ddos was being used to cover and never noticed anything). That was good enough to maintain availability, so I rolled with it and the requests eventually stopped. I have no hard data on that last point, just the fact that I tailed the access log and the requests went from 5 per second to 1 every 3-6 seconds before dying off completely. I said on Twitter that we suspected it was a deanonymization attempt, but I didn't elaborate why because LOL 140 CHARACTERS. Intangir (The other admin, who took over for me from Halloween 2013 to some time around July of this year) and I talked about it back in August and decided that an attacker was probably involved spraying specially crafted packets at the box in order to mess up its circuits, and eventually get us on attacker-controlled nodes. Since we mitigated the availability loss, we deemed it as no big deal. In hindsight, that seems hilariously stupid/naive of us. The kid who started doxbin had a similar theory that I'm just going to paste verbatim: <founder> ANYWAY <founder> i think <nachash> CONTINUE <founder> the attack <founder> was to DoS you <founder> until you created circuits <founder> entirely made of dickbleedable nodes <founder> and then dickbleeding them <nachash> but the server <nachash> got seized <founder> yeah, the IP was discovered by dickbleed though <founder> the entire circuit was leaking info <nachash> lol, did you just reproduce this? <founder> not yet, i'll be trying <nachash> Do you mind if I share this with tor devs? <founder> go ahead <founder> its just a theory at the moment If either of these theories even remotely pan out, a possible mitigation for the next person like me (Which shouldn't require any tor dev work) might look something like this: 1. Make several public relays and configure the torrc of the hidden service to only make circuits which begin with those nodes. Private bridges would be a liability in this case because anyone who figures out the guard node by weaponizing one of attacks from a whitepaper (Which guard nodes were modded to mitigate) will be able to find the guard node and then quickly discover that it isn't part of the public tor network. Public bridges might be ok, but probably less so. 2. Cross your fingers and pray really, really hard that the money trail is correctly obscured. 3. ???? 4. PROFIT! (Or lulz, in my case) (No, the similarity between the idea of drug market operators giving back to the network by donating nodes to the practice of drug cartels building schools and hospitals is not lost on me) Another thing to consider is the recommendation against running a hidden service as a relay. Of course, the argument against doing so in the documentation is very sound. At the same time, the FBI has stated in the Silk Road criminal complaint that upon finding the IP, the investigator verified that it wasn't a tor node and knew he had won the onion lottery. Of course, that could still be psyops/parallel construction garbage to scare people into making their jobs a little easier, but it's something to thing about. END TINFOIL sha256sums of all the files: 04261115c2ca8d28c439ee16926e271479b8626cc9403d31d686317227f9f4b0 archive.php.txt 2811be83aa41666f245432a1a562a3ac6c7035a59a16beae09571a71723e734c captcha.php.txt c5b9bff30748b8d68666f6d4687757f955cde96e67bbb00edad703af45b776ae doxbin_2014_08_21.txt.xz cde066ef290ee22c8d78a34af17d33a393845105d21f9fd96db93e0a51290b77 doxbin_2014_08_22.txt.xz 43ec183ee7efc3e9d14d084e50fe054ac6ffb60919e596a8dc4824f116fa1d83 doxbin_2014_08_23.txt.xz 3e630b3843341926ab7667a41a023fa4d63a38d01a5a3549a66f8bc98507cd39 doxbin_2014_08_24.txt.xz 20af2efec930e477fe5595eee66418f87af047ad4316ffc399761002c2d5f45d doxbin_2014_08_25.txt.xz 1c24eecbc98456a4c2f489a6012a48ec2119927402e7dd1ac12cff7732d04192 doxbin_2014_08_27.txt.xz afcdafc5293b6a9dbe402da65522f01a231f3f9727a4e597e70cf44321f96c2f doxbin_php.txt 66d495a5d21df855eedc6e3493a159b2b522b1b8170610c7c7e013f31d01e0ba doxviewer.php.txt 34611133cb4da451fc45f09e2ca6a08a71267439755b68608cbbc9b2a151ccee error.php.txt f37e6be62b149e40fb604cef90313d321f2bf4d2156808ef997a82004307c22f faq.php.txt 10bc8b38757ad7b27576488a37cec4a2f9dd0ed2ef467cc605ac0da8e83f3e23 index.php.txt 9596d7339f7a89eca7f18dd36cc2f433cdaa23700497816a6a71889158f90bc7 legal.php.txt 912241933303556097d60b890bac18be4577cbefaa6794088b256a3bf1f3796e naxsi_core.rules.txt 36bfb91a072d43a07de816d78a7cae8b7350a7f8069798468c8f3556acbeab9b nginx.conf.txt 66df06cdf6e6aba5dab8655e72c30bc5020f2319db1329c2f93bc74e96a96ac4 post.php.txt b9c12279b289a56702c9a3dc9b873b453ca4642efbcacba597c8bd252a9092ab privacy.php.txt 728fb96cbecafd974a9afc3211e8d9eb7bbb49f73e3ccb64fe9f7390341b3d38 proscription.php.txt ae0b124f3ccd849653ef806b10dd41cf316ffd45ef5d8d5af8c2d117027835e4 resources.tar.xz 7ba7ab341f29fc6d5a449bcd2f18c8962b8475b34c8b5745676da4f4c8e51a90 search.php.txt 6aa7c5dbe7aaa25b729ab542e0396f7f7d322244935ea4c0ad0e468b01d19374 thw.php.txt sha512sum: 7a0e5eaed12d6f7134c56cdd6e68e8255e49c00897fe05701abb84e91d215ed23f462d6b0485467da04a2d7c0a51d5e6a3fece943d9ce2137321a0913448afec archive.php.txt 804d679233f811aa66ca6fbc370e0734c7ba830959165496c66a0585637e4c5f966e6dfcbed618bea65ab11aa2f49351840376abc553e74c84001cf5e737da2b captcha.php.txt 734adca606f984fce830ebb5d5a05dee0c75d06ff05498483ff057cfd879f670f1a6bd42f5ad090bd63edd0f54d8eed86a0aa04cfe60669c11ac141f271ec366 doxbin_2014_08_21.txt.xz c9b55b8b9cf3d3f5820b8cde5b3de77cd609b17c1f6c234118b4b632978a8ef131227500fac66e2238756014437672178515ba028b70f8dc29b0b3b7ef158632 doxbin_2014_08_22.txt.xz c63ab075b0383be0703c97bf9fbe42e1dbb3f1ab01eddddbe1752af12bd38a71d6906c2c4c18695b0afa091049ca8583a86b747690cea17c45bd4edcaf269611 doxbin_2014_08_23.txt.xz 4486fbf61e5132a6167f46c7ec88f7fe25d879e72094d43b3189f786ad84a4e3fd75adc76fddf4ece26b7b670091d29e6a5e7631fd0660b4d549cc49d2e8bcfc doxbin_2014_08_24.txt.xz 1ac1e9359092d77e0a13a404ea428cc396b22a8f89dd7bb3241a80a4aa16a3d769aacf0289d1c83e3e367e24ca0a922ca9b3d950a14f962defd6f7c69c62cc63 doxbin_2014_08_25.txt.xz e6722d43221a13d6df3f521b040d11a17cd27a63017a73893bf25396468127bbb7f8d81b1b4c7c0aba52e82b09419e63c3df9df877c68fc7603fc9f19b8bda20 doxbin_2014_08_27.txt.xz c9d20c82b473260473824ed4909c165f10a3a1a93405cab1ac28d8ae17ee839754998f0d6e7e78c09fec4e21bf4efd6c65ece4734c87f437199cd256cd6756ab doxbin_php.txt b73db1ceefdc501f6ec0fd52c368a88f1e88d80049ed2824fb4a8c60d2c70a87079528f1a043bca6fd2d073ce186eb87531a9cf69b449f537a041786e4f634f3 doxviewer.php.txt 4f4702f4f4970f67f73b23ca357f764f62eddd63a6fa7878d1c0aeaa2f48ed3813e84261a278ee396aa3e0c6dbe4e5333d8d83b85d173e13be9bea337cf7a678 error.php.txt 6cfc57fd6f3aaf9a7829b83f8a43852e965dc11929be29f59c494bd8b5723b0fee9aa9ccdc734b8bb07127555d14a8619343061d6fe88508afe7f9ba569ac376 faq.php.txt d568388cd9abcad5c0db31a25feef410f7a1a1b26ca3d542b38d1e75c232dbc6d852040dffb3d754d74aac6ecf04e996844b673d4b74ac00c05bb920f63528d1 index.php.txt 35164a260e89a3ef296460ebfba7b3f5b902b4594fcbc5871e1b431f6c4b89c2e80ae372c50fd6a30d50edeaa94e7326c0cbefca92537e37a3deddbfa610e8f7 legal.php.txt 93fcbfd36e299239ec2e350fc9a768b9c819089a6922aa997c377d205e7895cd3f6beef00fbadf7de0e02f26efd3ce7a0e47c5d927ae5eb4c9c256c4be58855e naxsi_core.rules.txt 1c0ac0e10e715ef8049ea7d1ae3fc635b96a9d62811137e98a4c3794f8ba86f5b66ea883d5ebe939d7cb607cc575e04d8c47ee4ddaabf0887ef44e99c56c4a0a nginx.conf.txt 3f29d8d34bc91e1114f089a937bf736b7b74837f5aeb834ae0ace6e7612e2b401bc8f769fa74a432533d92c28b7165eb31dc40eb7ffbfaf82dd870815cc4e189 post.php.txt 8079dff1ceb2309d98198d3503db8bdaeb38bcdf9679548e8fe7ce1a8bbc87506f8d165713d90c7d2f6316031c1bd7eb7765441d325741c8bd5ca6bc2a6a2843 privacy.php.txt a1f6d218a2f65617203d53fbbf625da362d9f2e2676fbc1a28491a1717a6c21367b0a241bd1599c336be2d31d085717b16b3efaffeb383e0a11ce73839ce648f proscription.php.txt 94b8bd2fb8b25880e1c25d5fcf60ebe93d3c42857ef61cdf5261dfcaaf1d34cc5d085c358793d22dc7cfd66dcb7628f0eb9953560c3c646d2b7abc08a368c4d3 resources.tar.xz 0fee75a98e3f8ae4d0c578af399144c49382c7680626cc62e01aa250fad11d1aea522e87ec8e79e6136632bd54bffe681b2ecc283e1d56a7e75b7ab17f7e2319 search.php.txt e69bdba3aeb6c94a3b785b96385fafe0ec58e66688333f423004da1a4725bd54666f1e0b427d52068cdbefa430146162f1511c3c0930ea4379f6b022756a48bf thw.php.txt Hope this helps, - nachash

5 6

Re: [tor-dev] [HTTPS-Everywhere] "darkweb everywhere" extension
by teor 09 Nov '14

09 Nov '14

Hi All, A "privacy everywhere" solution could have two components: 1. the HSTS-like "always open this site in .onion" policy already discussed; and 2. an AppLinks or AppLinks-like[1] header that specifies a preferred app and/or URL for Tor, I2P, namecoin, … The first handles the situation where you're already in the Tor browser, I2P, namecoin, and simply wish to pin the .onion etc. URL for that site. The second handles the situation where you're browsing the web in your standard browser, but want to switch to a .onion site in the Tor browser if one is available (or the equivalent namecoin or I2P action). AppLinks is mainly designed for mobile platforms, but has Windows schemes as well. I could imagine schemes like: al:onion:url https://facebookcorewwwi.onion al:onion:attribute value al:namecoin:url https://... al:namecoin:attribute value al:i2p:url https://... al:i2p:attribute value What do you think? I wonder if this is helpful, or could just end up being out of scope, duplicating effort, or abusing the AppLinks protocol design (which is focused on an app per platform, not multiple options for alternate URLs). T [1]: http://applinks.org/documentation/#applinknavigationprotocol teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w… > On 3 Nov 2014, at 23:00, tor-dev-request(a)lists.torproject.org wrote: > Date: Mon, 03 Nov 2014 00:12:53 -0600 > From: Jeremy Rand <biolizard89(a)gmail.com> > To: tor-dev(a)lists.torproject.org, https-everywhere > <https-everywhere(a)lists.eff.org>, namecoin(a)googlegroups.com > Subject: Re: [tor-dev] [HTTPS-Everywhere] "darkweb everywhere" > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Yan, > > Namecoin would definitely be interested in something similar (we were > actually discussing the possibility of exactly this yesterday). Maybe > we could produce a list of relevant projects that would benefit from > this? (The three that come to mind immediately are Tor, I2P, and > Namecoin, but there may be others.) If there are more than a few > projects that would benefit, then it might be interesting to find a > neutral format for the HTTP header, so that we wouldn't have to list > all the supported TLD's explicitly in the spec. > > (CCing to Namecoin dev list.) > > - -Jeremy Rand > Lead Application Engineer, Namecoin Project > >> On 11/02/2014 11:48 PM, yan wrote: >> +tor-dev. tl;dr: Would be nice if there were an HTTP response >> header that allows HTTPS servers to indicate their .onion domain >> names so that HTTPS Everywhere can automatically redirect to the >> .onion version in the future if the user chooses a "use THS when >> available" preference. >> >> I imagine the header semantics and processing would be similar to >> HSTS. It would only be noted when sent over TLS and have the >> max-age and include-subdomains fields. >> >> -yan >> >> yan wrote: >>> Hi all, >>> >>> Some people have requested for the "Darkweb Everywhere" extension >>> [1] to be integrated into HTTPS Everywhere. This is an extension >>> for Tor Browser that redirects users to the Tor Hidden Service >>> version of a website when possible. >>> >>> I'm supportive of the idea; however, I'm worried that since >>> .onion domain names are usually unrelated to a site's regular >>> domain name, a malicious ruleset would be hard to detect. AFAIK >>> Darkweb Everywhere only defends against this by publishing a doc >>> in their Github repo that cites evidence for each ruleset [2]. >>> >>> What if, instead, we asked website owners to send an HTTP header >>> that indicates the Tor Hidden Service version of their website? >>> Then HTTPS Everywhere could cache the result (like HSTS) and >>> redirect to the THS version automatically in the future if the >>> user opts-in. >>> >>> If this is something that EFF/Tor would be willing to advocate >>> for, I would be happy to draft a specification for the header >>> syntax and intended UA behavior. >>> >>> Thanks, Yan >>> >>> >>> [1] https://github.com/chris-barry/darkweb-everywhere/ [2] >>> https://github.com/chris-barry/darkweb-everywhere/blob/master/doc/EVIDENCE.… > _______________________________________________ >>> HTTPS-Everywhere mailing list HTTPS-Everywhere(a)lists.eff.org >>> https://lists.eff.org/mailman/listinfo/https-everywhere >> >> _______________________________________________ tor-dev mailing >> list tor-dev(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUVxzXAAoJEFgMI9bDV/9qY3UIAJrl5LI/1OHJngu1W9DsLAjr > nh+Csnm66z5tQTwiwva1Tb4b6trHv4KkHItaTm0cI44mQNsd+YEkh0oRBTSNNcRm > HY0BDn2pqTlQPN9bWvclGEtCacevCbaQiZgPpxPa+1crtavto4VAnv0/EI85QVAe > XHUNBeAHmB3qNATXsVJ61oksWlU/x8ao62fB13cUd2fVyaasWz4PPsAJ9n3TkdYG > /el7mAuM6XdA1fFaGFd1ta0jRuER2VgKQvJQctu/6a/9jiNlib3YmMOOxvF0WR+/ > foUdhFkNCmRWwxqnxFDiKM0ilRLjTQ47CYRkgkqD4azPlkNvUULbO3KhaWPB9/4= > =rUsH > -----END PGP SIGNATURE----- >

2 1

Re: [tor-dev] [tor-internal] HS attack blog post (was Re: Hidden services and drug markets takedown)
by A. Johnson 09 Nov '14

09 Nov '14

I think the option to rate-limit guard selection is a great idea to defend against guard DoS. The downside is possible connection loss even if you’re not under attack and you just happen to pick flaky guards. In case you’re interested, I examined this defense and how often such benign service loss would occur in section 6.B of "The Sniper Attack: Anonymously Deanonymizing and Disabling the Tor Network” <http://ohmygodel.com/publications/sniper-ndss14.pdf>. Table 6 shows the probability that this happens for a Tor client that operates continuously for two months (after 2-3 months all guards will have expired and the process repeats). If, for example, you are willing to require only one active guard (a_g=1) and you limit yourself to no more than 4 new guards (r=4) chosen in the last 28 days (t=28), then you had a 0.0008 chance of having any down time (whether or not it happens depends on which guards you chose). If you increase the number of allowed new guards to 5 (r=5), then the probability of downtime was zero. Cheers, Aaron > Got it. Though on the client side, could we have a warning or have an option to hibernate a HS if they have been forced to switch guards N times in the last N minutes or hours or such? This would allow a DNS on the HS of course, but that may be preferable to discovery. > > David Chasteen > > PGP 0x48458ecd78833c0d > > On Nov 9, 2014 12:49 PM, "Matthew Finkel" <matthew.finkel(a)gmail.com> wrote: > On Sun, Nov 09, 2014 at 12:34:01PM -0500, David Chasteen wrote: > > Would it be possible to create some kind of tor weather-like detection > > and alert system to warn if such a massive DoS attack were underway such > > that users could know that perhaps now might not be the best possible > > time to use Tor? A hidden threat is worse than a known one. We're not > > going to be able to mitigate every known threat, but making users aware > > that the threat profile is heightened can allow them to make informed > > risk decisions. > > > > Unfortunately we don't receive any real-time statistics from relays, > and our metrics calculations are run daily, so there's a significant > delay in any visualizations we generate. Perhaps we can still look for > and see long-term attacks (> 24-36 hours) but nothing that will > significantly benefit users shortly after the attack begins. > _______________________________________________ > tor-internal mailing list > tor-internal(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-internal > _______________________________________________ > tor-internal mailing list > tor-internal(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-internal

1 0

Proposals 220 and 228 updated
by Nick Mathewson 07 Nov '14

07 Nov '14

Hi, all! I've checked in some small changes to proposals 220 and 228; please see the torspec git repository for information. These reflect changes that I have realized those proposals needed while I was working on implementing them in ticket 12498. best wishes, -- Nick

1 0

tor meetings for the week of November 10: including triage party!
by Nick Mathewson 07 Nov '14

07 Nov '14

Good morning/afternoon/evening! On Tuesday at 1700 UTC, there is the regular patch workshop. On Wednesday at 1330 UTC, there is our regularly scheduled development meeting. On Thursday at 1330 UTC, there is a bug triage party, where we will try to figure out what we need to solve in 0.2.6, and what we can mark as nice-to-have-but-deferrable. All meetings are on the #tor-dev channel on OFTC; if we get too noisy or have a conflict, we'll move somewhere else. Everybody is welcome! yrs, -- Nick

1 0

Why the seeming anticorrelation between obfs3 and vanilla bridges in metrics graphs?
by David Fifield 07 Nov '14

07 Nov '14

In the past few months of bridge user graphs, there is an apparent negative correlation between obfs3 users and vanilla users: when one goes up, the other goes down. If you draw a horizontal line at about 5500, they are almost mirror images of each other. I don't see it with any other transport pairs. Any idea why it might be? I can see what could cause a simultaneous decrease in vanilla and increase in obfs3: Tor gets blocked somewhere and users switch to obfs3. But I wouldn't expect blocking events to look so smooth or happen so frequently, and it doesn't explain why the reverse change happens later (obfs3 being blocked while Tor is unblocked is less plausible). I can also understand the overall long-term trend of obfs3 increasing and vanilla decreasing. But I don't see why they should mirror each other so closely over short time periods. Some hypotheses: 1. There are lots of users who have a mix of vanilla and obfs3 bridges configured. Their tor (randomly?) chooses one of them, which usually works. The number of such users is constant over the short term; i.e. the sum of obfs3+vanilla is constant, but the proportion of obfs3 and vanilla fluctuates randomly. 2. Maybe vanilla-down/obfs3-up is caused by blocking events, and vanilla-up/obfs3-down is caused by natural new-user churn and/or coincidence. 3. There is something about the way BridgeDB hands out bridges, or the way in which users use it, that causes it to give out obfs3 bridges at the expense of vanilla and vice versa. 4. Some kind of feedback loop: obfs3 bridges get used and get congested, so users switch to vanilla, which then get used and congested, etc. David Fifield

3 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev