- tor-dev - lists.torproject.org

Firejail Integration
by bancfc＠openmailbox.org 13 May '16

13 May '16

Hi Yawning. We are thinking about how to integrate your Firejail profile [0] in Whonix. Do you plan to upstream the changes in the start-tor-browser script soon? If not then what is the best way to ensure the custom script survives TBB upgrades? [0] https://git.schwanenlied.me/yawning/tor-firejail

2 1

exitmap modules that make *lots* of connections
by Zack Weinberg 13 May '16

13 May '16

I'm working on an exitmap module that wants to feed order of 5000 short-lived streams through each exit relay. I think this is running foul of some sort of upper limit (in STEM, or in Tor itself, not sure) on the number of streams a circuit can be used for, or how long, or something. What I see in the logs (note: I've modified eventhandler.py for more detailed debug logs) looks like 2016-04-22 16:07:53,306 [DEBUG]: Circuit status change: CIRC 6 LAUNCHED PURPOSE=GENERAL TIME_CREATED=2016-04-22T20:07:53.305851 2016-04-22 16:07:53,325 [DEBUG]: Circuit status change: CIRC 6 EXTENDED [fp] PURPOSE=GENERAL TIME_CREATED=2016-04-22T20:07:53.305851 2016-04-22 16:07:54,114 [DEBUG]: Circuit status change: CIRC 6 EXTENDED [fp],[fp] PURPOSE=GENERAL TIME_CREATED=2016-04-22T20:07:53.305851 2016-04-22 16:07:54,115 [DEBUG]: Circuit status change: CIRC 6 BUILT [fp],[fp] PURPOSE=GENERAL TIME_CREATED=2016-04-22T20:07:53.305851 2016-04-22 16:07:54,136 [DEBUG]: Port 47488 preparing to attach to circuit 6 2016-04-22 16:07:54,136 [DEBUG]: Port 47488 circuit 6 waiting for stream. 2016-04-22 16:07:54,155 [DEBUG]: Attempting to attach stream 65 to circuit 6. 2016-04-22 16:07:54,387 [DEBUG]: Port 47492 preparing to attach to circuit 6 2016-04-22 16:07:54,387 [DEBUG]: Port 47492 circuit 6 waiting for stream. 2016-04-22 16:07:54,388 [DEBUG]: Attempting to attach stream 67 to circuit 6. 2016-04-22 16:07:54,809 [DEBUG]: Port 47496 preparing to attach to circuit 6 2016-04-22 16:07:54,810 [DEBUG]: Port 47496 circuit 6 waiting for stream. 2016-04-22 16:07:54,810 [DEBUG]: Attempting to attach stream 69 to circuit 6. 2016-04-22 16:07:55,060 [DEBUG]: Port 47502 preparing to attach to circuit 6 2016-04-22 16:07:55,060 [DEBUG]: Port 47502 circuit 6 waiting for stream. 2016-04-22 16:07:55,061 [DEBUG]: Attempting to attach stream 72 to circuit 6. 2016-04-22 16:07:55,468 [DEBUG]: Port 47506 preparing to attach to circuit 6 2016-04-22 16:07:55,468 [DEBUG]: Port 47506 circuit 6 waiting for stream. 2016-04-22 16:07:55,469 [DEBUG]: Attempting to attach stream 74 to circuit 6. 2016-04-22 16:07:55,720 [DEBUG]: Port 47508 preparing to attach to circuit 6 2016-04-22 16:07:55,720 [DEBUG]: Port 47508 circuit 6 waiting for stream. 2016-04-22 16:07:55,990 [DEBUG]: Port 47512 preparing to attach to circuit 6 2016-04-22 16:07:55,990 [DEBUG]: Port 47512 circuit 6 waiting for stream. 2016-04-22 16:07:55,990 [DEBUG]: Attempting to attach stream 77 to circuit 6. 2016-04-22 16:07:56,241 [DEBUG]: Port 47518 preparing to attach to circuit 6 2016-04-22 16:07:56,241 [DEBUG]: Port 47518 circuit 6 waiting for stream. 2016-04-22 16:07:56,242 [DEBUG]: Attempting to attach stream 80 to circuit 6. 2016-04-22 16:07:56,492 [DEBUG]: Port 47528 preparing to attach to circuit 6 2016-04-22 16:07:56,492 [DEBUG]: Port 47528 circuit 6 waiting for stream. 2016-04-22 16:07:56,495 [DEBUG]: Attempting to attach stream 85 to circuit 6. 2016-04-22 16:07:56,836 [DEBUG]: Port 47536 preparing to attach to circuit 6 2016-04-22 16:07:56,836 [DEBUG]: Port 47536 circuit 6 waiting for stream. 2016-04-22 16:07:56,836 [DEBUG]: Attempting to attach stream 89 to circuit 6. 2016-04-22 16:07:57,100 [DEBUG]: Port 47540 preparing to attach to circuit 6 2016-04-22 16:07:57,100 [DEBUG]: Attempting to attach stream 91 to circuit 6. 2016-04-22 16:07:57,351 [DEBUG]: Port 47544 preparing to attach to circuit 6 2016-04-22 16:07:57,351 [DEBUG]: Port 47544 circuit 6 waiting for stream. 2016-04-22 16:07:57,352 [DEBUG]: Attempting to attach stream 93 to circuit 6. 2016-04-22 16:07:57,769 [DEBUG]: Port 47550 preparing to attach to circuit 6 2016-04-22 16:07:57,769 [DEBUG]: Port 47550 circuit 6 waiting for stream. 2016-04-22 16:07:57,769 [DEBUG]: Attempting to attach stream 96 to circuit 6. 2016-04-22 16:07:58,118 [DEBUG]: Port 47554 preparing to attach to circuit 6 2016-04-22 16:07:58,118 [DEBUG]: Port 47554 circuit 6 waiting for stream. 2016-04-22 16:07:58,118 [DEBUG]: Attempting to attach stream 98 to circuit 6. 2016-04-22 16:08:04,697 [DEBUG]: Circuit status change: CIRC 6 CLOSED [fp],[fp] PURPOSE=PATH_BIAS_TESTING TIME_CREATED=2016-04-22T20:07:53.305851 REASON=FINISHED 2016-04-22 16:08:05,878 [DEBUG]: Port 47690 preparing to attach to circuit 6 2016-04-22 16:08:05,878 [DEBUG]: Port 47690 circuit 6 waiting for stream. 2016-04-22 16:08:05,879 [DEBUG]: Attempting to attach stream 166 to circuit 6. 2016-04-22 16:08:05,879 [WARNING]: Failed to attach stream because: Unknown circuit "6" You can see that circuit 6 is no longer available, but the module is still trying to use it. It looks like it lasted for almost exactly ten seconds, which smells like a time limit, but I can't find any relevant configuration parameters in the documentation. Rather than trying to make a circuit survive as long as necessary, which might not even be possible, it'd probably be better if exitmap could notice that it's lost a circuit that's still in use and create a new one. However, I'm not sure how to do that in the current architecture. The existing code has "one circuit per module invocation = one circuit per exit node" as a pretty deeply embedded design constraint. Anyone have any ideas? Full logfile available on request, but it's huge. zw

2 2

Fewer Failures in Shared Random
by Tim Wilson-Brown - teor 12 May '16

12 May '16

Hi All, Currently, the shared random system treats the first vote of the next commit phase specially - it's the only time it tries to agree on a new shared random value. This makes one consensus in each day particularly attractive to adversaries (or particularly vulnerable to failures), because if we fail to agree on that consensus, the next shared random value is never agreed. This makes hidden service behaviour far more predictable for the next 24 hours. But we can try to agree 12 times on a new shared random value like this: * for the first consensus in the new commit period: * vote the calculated shared random value based on the commits and reveals we've seen; * for subsequent consensuses in the new commit period: * if we have an agreed shared random value from a trusted, previous consensus in the period, vote that value; * if not, (if the new shared random value is missing from all previous consensuses in that period, or there is no trusted consensus), continue to vote our calculated value. This way, we try up to 12 times to agree on a shared random value. (But we never change an agreed value after we've agreed on it.) This is very similar to how the previous shared random value is determined. I've added #19045 to keep track of this: https://trac.torproject.org/projects/tor/ticket/19045 Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n

1 0

RFC-ish: basket2 (aka obfs5)
by Yawning Angel 12 May '16

12 May '16

Hello, So I've been somewhat productive as of late and have been working on the successor to obfs4. I have a "oh my god, you wrote how much code, with no documentation" minimum-viable-product-ish release that appears to work, though ABSOLUTELY NO ONE SHOULD USE IT YET, because I will break bridge line/protocol wire compatibility intentionally at least once before release. The code: https://git.schwanenlied.me/yawning/basket2 (Really, don't use it, at all. I will ignore cries of help, mercilessly mock people that attempt to chase a moving target, and laugh as I break things). The documentation: Hahahahahahahahahahahahahahaha (It should be self explanatory). A brief overview of the improvements: * Client can now negotiate the link padding/delay algorithm at handshake time with the server (no more `iat-mode=blah` argument), and defaults to something which injects delay. * Link cryptography changed to a XChaCha20/Poly1305 construct, with AVX2 used for the ChaCha20 when available, and the framing construct it self is a lot better designed. * Handshake is X25519 + NewHope or X448 + NewHope based (available algorithms specified as part of the bridge line), with X25519 (Elligator2) for authentication. * SHA-3/SHAKE are used as the handshake routines. * When adding IAT on a burst basis, the code attempts to detect bulk data transfer resulting in less delay for large downloads/uploads. * Server side buffering reduced by 50% (not sure if that'll stick, I need to think about some of this stuff). TODO: * Implement a "expensive" padding option for bridges that can afford to run such a thing. (WTF-Pad, CS-BuFlo, or Tamaraw, not sure yet. WTF-Pad is a bit harder to implement than I'd like...) * Improve the lightweight padding algorithms instead of using what is essentially the same as obfs * Finish support for user authentication. * Write a formal specification. * Debug, debug, debug. * Write an AVX2 Poly1305 so it goes faster on boxes that matter (my laptop). * (Maybe) Write NEON and 32 bit x86 assembly optimized versions of the custom crypto, so it runs faster on various low end shit boxes. NEON is more important to me than 32 bit Intel (and a low end Atom does ChaCha20 at 40 MiB/s or so anyway...). Anyway, this is sort of a heads up that something like this is in the works, and is approaching alpha state, though DID I MENTION NOT TO USE IT YET? Questions/Comments/Feedback welcome as always. Regards, -- Yawning Angel

1 0

Directory authority of type bridge?
by Nicholas R. Parker (RIT Student) 11 May '16

11 May '16

Hey again all, got another one for you. When we've started adding bridges to the network, they send a warning "Publishing server descriptor to directory authorities of type 'Bridge', but no authorities of that type listed!" Not sure how to have a directory authority as a bridge type given that if you set BridgeRelay 1 on an authority it drops the DirPort and just becomes a bridge relay. How does one list an authority as a bridge type? Nicholas R. Parker Rochester Institute of Technology 5thYear, BS/MS Computing Security

2 2

Re: [tor-dev] [Proposal] Obfuscating the Tor Browser Bundle initial download
by Blake Hadley 09 May '16

09 May '16

> The environment you're were in was mounting a MITM attack to break TLS, > or has compromised your box, because the only component of the URL that > is visible otherwise is the host in the SNI field. > > In such an environment, gettor in general isn't unblockable because > there is no privacy/security for the request/response messages. > > Regards, > > -- > Yawning Angel Sorry, I'm not completely familiar with how TLS works. The environment requires an HTTPS proxy to reach the World Web Web. Do HTTP proxies inherently create a situation similar to MITM?

4 3

[Proposal] Obfuscating the Tor Browser Bundle initial download
by Blake Hadley 09 May '16

09 May '16

Hey everyone, [How it's currently done] Distributed by gettor(a)torproject.com, the URL makes it pretty clear what you're downloading. Dropbox: https://www.dropbox.com/s/mz9ug2rzvj85791/torbrowser-install-5.5.5_en-US.ex… Google Drive: https://docs.google.com/uc?id=0B76pDbk5No54VHowTEprZnBfWlU&export=download GitHub: https://github.com/TheTorProject/gettorbrowser/releases/download/v5.5.5/tor… [Security problem] The download URL on Google Drive is somewhat obfuscated, but once the download is started, the filename that the browser requests is 'torbrowser[...]' An environment I was working in has started to block the files based on name, and it would be very easy for an adversary monitoring network traffic to detect users downloading it. [Solution proposed] When the user emails gettor, they could also request obfuscation. An application would randomize the filename and upload it to a mainstream host (Google, Dropbox, GitHub, AWS). Maybe even protect the file from scanning by making an AES encrypted ZIP file, and giving the user the password in the reply email. I'd be happy to make a proof-of-concept. What do you all think of this? Does anyone have any better ideas? Anything that uses less processing resource?

2 1

Re: [tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope
by eikovi＠sigaint.org 09 May '16

09 May '16

Typos: > used as input to the SHAKE-256 extendable output function (XOF), as decribed deScribed > In the case for relays possessing Ed25519 identity keys (c.f. Tor proposal > ... > descriptor (c.f. Tor proposal #264) advertises support for the "Relay" > ... > (c.f. Tor proposal #249). > ... > We introduce a new sub-protocol number, "Relay=3", (c.f. Tor proposal #264 confer, cf., it's a single flying word > public keys already being in included within the "ntor-onion-key" entry. s/in included/included/ > poly_getnoise() first generates 4096 Bytes of uniformly random data. This can s/Bytes/bytes/ > mode). The output of the PRG is considered an array of 2048 16-bit integers > ... > Note further that the output of this function is secret; the PRG (and the PRnG was used previously > pseudocode description of a very naive inplace transformation of an input > ... > [0]; a pseudocode description of a very naive inplace transformation of an s/inplace/in-place/g

3 5

Testing Network Node Availability
by Xiaofan Li 08 May '16

08 May '16

Hi all, We've finished building TOR on QUIC and everything works fine with chutney. However, we have an issue with the node availability when we test on real networks. We need this to work in order to evaluate the effect of HOL blocking with QuicTor vs. Tor. Specifically: 1. When using our QuicTor and normal TOR* without path restriction*, warning messages like: [warn] Failed to find node for hop 1 of our path. Discarding this circuit. Keeps showing up but the node would actually reach 100% bootstrap and all file transfer functionalities work fine. 2. However, our real issue is when I *restrict the path selection* to 3 pre-determined nodes for all exit circuits, the client will not reach 100% anymore and keeps hanging at 85% (or 80% sometimes). 3. We've thoroughly tested path restriction with chutney and it works. Our network has 11 nodes: 3 clients and 8 relays (2 of which are authorities). We already have assumeReachable and I've tuned up voting frequencies, just like chutney's default config. Any other configuration flag that could help propagating router availability info? Any idea at all? Li.

3 11

Exit relay proportions for test network
by Nicholas R. Parker (RIT Student) 08 May '16

08 May '16

Quick question for all of you. At this stage of construction on a private tor network, I've reached the point where I can't quite figure out how many of our relays ought to be exit relays. I know that a 25 node network ought to have 4 authorities, 16 relays, and 5 clients, but is there a minimum required number of exit relays? Nicholas R. Parker Rochester Institute of Technology 5thYear, BS/MS Computing Security

2 1