Re: [tor-dev] Call for testing/review: obfsclient-0.0.1
On Mon, 17 Mar 2014 13:26:25 +0100 Fabian Keil wrote: > My pleasure. Unfortunately I apparently missed one issue on FreeBSD > 8.4: > https://redports.org/~fk/20140317110212-48719-187908/obfsclient-0.0.1.log Ah, that's a easy fix. FreeBSD 8.x's sys/cdefs.h doesn't define __STDC_LIMIT_MACROS when the compiler is using C++11, so the limit macros aren't getting defined when I pull in cstdint. Fixed in: 5ab2988bdd390cdf557b4fd971dcd64380dd8ab5 > When I tested rc2 with Redports the 8.4 build systems had > network problems and thus this might not be a new problem: > https://redports.org/buildarchive/20140302115957-67062/ It's code I changed for rc2. No biggie. I don't think that the build fixes for Darwin/FreeBSD warrant tagging 0.0.2 on their own, but it should be easy to work around in the port package (it's a minor tweak to CXXFLAGS if the host is < FreeBSD 9.1). Thanks! -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Call for testing/review: obfsclient-0.0.2
Hello all, I just tagged obfsclient v0.0.2 (Release) Download at: https://github.com/Yawning/obfsclient/archive/v0.0.2.tar.gz This is mostly a bug fix release that addresses issues found in testing/actual use. The code is quite stable now, and I have been using it for all of my tor for approximately 2 weeks. Changes since 0.0.1: * Change the command line arguments to match the obfsproxy counterparts. This fixes issue #31. * Apply pushback between each side of the proxied connection to limit the amount of data that can be buffered. This fixes issue #3. * Use bufferevent_write_buffer to save allocating/copying in obfs2/obfs3. This fixes issue #24. * Fix assertions primarily seen on abrupt connection close by disabling all reads on transition into the various SOCKS5 FLUSHING states. * Cleaned up the logging, and log SOCKS5 assertions to the log file. * Send a TTL EXPIRED SOCKS5 error on connection timeouts. * Fixed an assertion that occurred if the outgoing connection immediately failed (Eg: Network interface being down). * Darwin build fixes, pointed out by Jeroen Massar. * FreeBSD 8.x/9.0 build fix, pointed out by Fabian Keil. NB: Darwin builds require using liballium from git and not 0.0.1, due to a minor code change to a embedded dependency. It is also entirely possible that I broke this again via changes made since then, but I don't use Darwin at all. Assuming there are no major bugs, I am hoping that 0.0.3 will be a feature release so the pace should be less hectic. Questions, comments, feedback appreciated as always, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] ideas/xxx-pluggable-transports-through-proxy.txt
Hello, The topic of routing pluggable transports through other proxys (SOCKS and HTTP CONNECT) has come up a few times recent, both as bug reports from users and as something that probably should be done to round out the pluggable transport concept since they will be included in the browser bundle by default. Relevant bugs: * #8402 - Tor should help its transport proxy use a proxy, if needed. * #8956 - obfsproxy should use a SOCKS proxy if Tor wants it to * #11409 - Obfsproxy through HTTP proxy There is one change that also needs to be made to the idea document (diff attached) that changes one of the return codes to be slightly more in line with the rest of the PT protocol chatter. As far as code support goes: * tor done, not merged, needs review by nickm or similar (branch linked from #8402). It *may* have rotted since it got triaged as a 0.2.6 thing right before I started working on this, but if that's the case I will update it as needed. * pyptlib, done not merged. Waiting on #8402. * obfsproxy, SOCKS4/5 done, not merged. HTTP CONNECT is a work in progress, needs the pyptlib changes. Regards, -- Yawning Angel From 3ad31e8727b46ef46b73d11764ca5fec15c5b57c Mon Sep 17 00:00:00 2001 From: Yawning Angel Date: Fri, 11 Apr 2014 06:12:32 + Subject: [PATCH 1/1] Change "PROXY true" to "PROXY DONE" for consistency. --- proposals/ideas/xxx-pluggable-transports-through-proxy.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/ideas/xxx-pluggable-transports-through-proxy.txt b/proposals/ideas/xxx-pluggable-transports-through-proxy.txt index 3fc7754..e03a6b9 100644 --- a/proposals/ideas/xxx-pluggable-transports-through-proxy.txt +++ b/proposals/ideas/xxx-pluggable-transports-through-proxy.txt @@ -69,7 +69,7 @@ Specifications: Tor Pluggable Transport communication If the pluggable transport proxy detects that the TOR_PT_PROXY environment variable is set, it attempts connecting to it. On - success it writes to stdout: "PROXY true". + success it writes to stdout: "PROXY DONE". On failure it writes: "PROXY-ERROR ". If Tor does not read a PROXY line or it reads a PROXY-ERROR line -- 1.9.2 signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfsproxy getting scramblesuit password from file in unmanaged mode
On Tue, 20 May 2014 18:25:46 +0300 irregula...@riseup.net wrote: > Hey all, > > when running obfsproxy with scramblesuit in unmanaged mode (e.g. to > obfuscate non-Tor traffic) the UniformDH password is passed in command > line like this: > > obfsproxy scramblesuit --password=W3ECD5GOYU5AAW4G35GSH5QXIHSRBU2X > > The problem with this is that the password is visible in the system's > process list. > > Do you think it would make sense to add an argument like > "--password-file", so as scramblesuit can fetch the password from a > file? Any caveats? > > Although this is not related to the Tor ecosystem, i think it would be > useful. Indeed, we have a bug open for this. https://trac.torproject.org/projects/tor/ticket/8040 I think using `setproctitle` to modify what appears on the system process list may be a better general solution (and it would let us do things like showing `obfsproxy: obfs3,scramblesuit` in the managed use case as well which I think is cute, if not massively useful. As an added bonus it is a general solution that's more futureproof. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] RFC: obfs4 (Name not final)
Hello, The people that have been following Pluggable Transport development may know that I have been working on something tentatively called "obfs4" recently. It's rapidly approaching the point where I would like to open it up for review and feedback, hence the e-mail. A quick and dirty description would be: obfs4 is ScrambleSuit with djb crypto. Instead of obfs3 style UniformDH and CTR-AES256/HMAC-SHA256, obfs4 uses a combination of Curve25519, Elligator2, HMAC-SHA256, XSalsa20/Poly1305 and SipHash-2-4. The feature set offered by obfs4 is comparable to ScrambleSuit with the following differences (implementation specific changes are noted as such): * The key exchange is based on the ntor handshake, and thus authenticates the server to the client. Both obfs3 and ScrambleSuit depend on the encapsulated protocol to handle this on it's own. * obfs4 always does a full handshake. ScrambleSuit style session ticket handshakes are not supported. Even with Elligator2 mapping taken into account, the obfs4 handshake is significantly faster, so there is less of a need for this. * (Impl) obfs4proxy currently does not offer Inter-Arrival Time obfuscation, but this could easily be added if it is something that a lot of people want. It is worth noting that while obfsproxy and obfsclient both support IAT obfuscation, support for it is currently disabled by default as a performance tradeoff. * (Impl) obfs4proxy is currently written in golang. Neither a clear plus or minus, it does allow people to run bridges on reserved ports significantly easier, is probably faster (native code, can use multiple cores for most things), but is more annoying to build and results in rather large binaries (the go runtime is statically linked). * (Impl) obfs4 supports a lot of the protocol improvements made to ScrambleSuit that are pending merge (See #11271, #11203). This difference is temporary. The code and a draft spec is at: https://github.com/Yawning/obfs4 Open questions: * Is the base design and my implementation sane? * Should obfs4proxy also have (disabled) IAT obfuscation? Adding it later will not require wire protocol changes. * The handshake length mimics ScrambleSuit in terms of maximum padding (< 1500 bytes). Should this be increased to be similar to obfs3 (~8k of maximum padding)? The server side cost for this shouldn't be that high. * Is this different enough from ScrambleSuit to be worth deploying? I would be ok with this ending up as "just a research project" and shelving it if the consensus is otherwise. * Should I have named it ScrambleSuit 2? It's a direct descendant of ScrambleSuit and is an obfs derivative only in name at this point. Future plans: * Implement suggestions/improve the code/fix bugs/write more unit tests. * Improve goptlib. * If this is deployed in meaningful amounts, support it in obfsclient. For the extremely brave, I am running a test bridge with the most recent snapshot of the code: UseBridges 1 ClientTransportPlugin obfs4 exec /path/to/obfs4proxy # Bridge line of doom, all one line. Bridge obfs4 178.209.52.110:52810 67E72FF33D7D41BF11C569646A0A7B4B188340DF node-id=Z+cv8z19Qb8RxWlkagp7SxiDQN8= public-key=vm+w9k57aMIX/o+A9ef5C7o9xKEkhr7kRBj3N4etDn8= As with any PT that requires per-bridge arguments, this also requires tor-0.2.5.x. The node-id in this case happens to be my bridge's fingerprint, the public key is the long term key used to validate my bridge's identity and generate M_[C,S]/MAC in the handshake (The bridge line is a bit of a UI/UX disaster unless people are copy/pasting it). Getting either of them wrong will result in handshake failures and tor not bootstrapping. A few warnings: * The spec assumes familiarity with ntor, ScrambleSuit and NaCl's crypto_secretbox. * The wire protocol is not final and I *will* push builds to the bridge as I break backward compatibility without notifying people (It's been 0 days since a wire protocol change.). The test bridge will randomly be broken/rebooted/etc as I also use it for other things. * Development was done with go1.2.x, older versions of the runtime are not supported. * It would be a terrible idea to use obfs4proxy as anything other than a client at this point. Questions, comments, feedback all appreciated. -- Yawning Angel PS: I also wrote https://github.com/yawning/or-applet recently. It's even less supported/tested than obfs4 is (it is written only for my laptop), but some people may find it cute. signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: obfs4 (Name not final)
On Wed, 21 May 2014 12:22:46 + David Stainton wrote: > > obfs4 is ScrambleSuit with djb crypto. Instead of obfs3 style > > UniformDH and CTR-AES256/HMAC-SHA256, obfs4 uses a combination of > > Curve25519, Elligator2, HMAC-SHA256, XSalsa20/Poly1305 and > > SipHash-2-4. > > Elligator... cool! > > > * Development was done with go1.2.x, older versions of the runtime > > are not supported. > > Did you get your builds to work with the deterministic build system? Not yet. While it's important I'm sort of working under the assumption that it's mostly a solved problem as the scary build process can handle flashproxy and meek. I've been a bit more focused on getting the protocol design and implementation to a point where I feel generally good about it. -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: obfs4 (Name not final)
On Fri, 23 May 2014 14:16:49 +0200 Philipp Winter wrote: [snippity] > > * Should obfs4proxy also have (disabled) IAT obfuscation? Adding > > it later will not require wire protocol changes. > > I don't think that inter-arrival times are a significant practical > threat at this point. In addition, it has a major impact on > throughput which is the reason why obfsproxy's ScrambleSuit ships > with the option being disabled. As you write, it shouldn't be a > problem to add IAT obfuscation later on if it turns out to be > important for some reason. I went and added the code last night, so it's there if needed (as a command line option). > > * The handshake length mimics ScrambleSuit in terms of maximum > >padding (< 1500 bytes). Should this be increased to be similar > > to obfs3 (~8k of maximum padding)? The server side cost for this > >shouldn't be that high. > > I'm not sure if sound decisions can be made without comprehensive > data showing how real-world protocols behave. ScrambleSuit's (and > perhaps also obfs3's) padding length was determined by gut feeling, > so ~8k might be fine as well. On the gut feeling of "bigger handshakes = more random *waves hands*", I went and jacked it up last night. More real world data would be nice. > > * Is this different enough from ScrambleSuit to be worth > > deploying? I would be ok with this ending up as "just a research > > project" and shelving it if the consensus is otherwise. > > While you're at it, there are some other things which might be worth > improving: > > - ScrambleSuit's framing mechanism is vulnerable to this attack: > <http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf> > In a nutshell, the receiver needs to decrypt the ScrambleSuit > header before it is able to verify the HMAC which makes it possible > for an attacker to tamper with the length fields. While there are > probably simpler attacks, it would be nice to have a fix for this > problem. I believe obfs4 does not have the plaintext recovery issue as the length field is separate from the AEAD construct (Though at present an adversary tampering with the length field is only caught by MAC errors). However I will go and implement randomizing the length on a out of bounds length value (as suggested in section 6 of the paper) to reduce the timing differential. From reading the paper, I do not believe that ScrambleSuit's vulnerability leads to plaintext recovery either as it uses CTR-AES and recovery is based off CBC-AES, though as the authors note, there may be other side channel hazards. > - We didn't push the idea of polymorphism very far. There are more > flow characteristics such as "packet directions", "total bytes sent", > or "total bytes received" which could be disguised in a systematic > fashion. While reasonable protection against traffic analysis is > tricky, we could at least decrease a classifier's accuracy a bit > more. Some ideas could be taken from this paper: > <http://arxiv.org/pdf/1401.6022v1.pdf> This is the sort of thing that mjuarez is looking into as part of GSOC. As long as a padding frame type is defined, incorporating the results of his research at a later date should be possible without changes to the wire protocol. Thanks for the feedback! -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] wfpadtools: comments about primitives
On Fri, 30 May 2014 17:42:39 +0100 George Kadianakis wrote: > Marc Juarez writes: > > > Hi all, > > > > I am a GSoC student working in a new PT for the development of > > future Website Fingerprinting countermeasures in Tor. > > > > The PT is not targeting any specific defense, but to link padding > > defenses in general. The idea is to implement a set of primitives > > that any link padding-based defense would benefit of. > > > > In this email I provide a more detailed description of these > > primitives and give a short update about their state. I forked the > > obfsproxy repo and made it publicly available in bitbucket: > > > > https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools. Excellent. > > I would appreciate comments from the Tor development community. I'm > > specially looking for advices that help me generalizing the padding > > module (padutils) and comments about the primitives I describe > > below. > > > > The envisaged primitives are: > > > > 1. A general padding class that provides methods to pad the link > > > > This part is almost finished. For that I reused the Scramblesuit's > > probdist and fifobuffer modules to buffer and flush data according > > to a given probability distribution. > > > > Using this class I have implemented a simple version of BuFLO > > (which is also included in the padutils module). > > > > Sounds reasonable. > > (BTW, we recently found that scramblesuit's genDistribution() function > in probdist.py does not generate a uniform distribution. You can see > this, since the way the prob distr is generated, its first element has > a mean value of 1/2 instead of 1/n. Yawning fixed this in obfs4 I > think, but it remains unfixed in scramblesuit.) https://github.com/Yawning/obfs4/commit/9fe9959c76c96ec3284f43c692cbb099230dcb73 That's an example of how to make it uniform. I'm not sure which behavior is better, real world data on what the packet distribution of non-Tor network protocols look like on the wire would be useful here. > [snip] > > 4. Implement the protocol's handshake. > > > > I took a look to the Scramblesuit's handshake.The handshake of this > > protocol would boil down to the negotiation of the parameters (e.g., > > probability distributions) for the padding. > > > > In the end, I think this handshake will need to be confidential > (encrypted) somehow. Otherwise, the adversary could read the > probability distributions and unwrap your padding layer more > easily. Or is this not in your threat model? Likewise, however (correct me if I'm wrong), this is an orthogonal problem. The vision I have currently is, when when we do obfs6 or whatever, that we would come up with our own unique and clever way to handle authentication and confidentiality and use wfpadtools internally. > > 5. Implement a flow control protocol > > > > This would adjust the padding parameters while running. The > > fifobuffer we are currently using helps queuing the messages but we > > will need an extra logic to detect congestion. It's a shame that SIOCOUTQ isn't portable, because checking the send socket buffer's size is one of the better ways to do this. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] wfpadtools: comments about primitives
On Fri, 30 May 2014 20:40:07 +0200 Marc Juarez wrote: > >> 4. Implement the protocol's handshake. > >> > >> I took a look to the Scramblesuit's handshake.The handshake of this > >> protocol would boil down to the negotiation of the parameters > >> (e.g., probability distributions) for the padding. > >> > > > > In the end, I think this handshake will need to be confidential > > (encrypted) somehow. Otherwise, the adversary could read the > > probability distributions and unwrap your padding layer more > > easily. Or is this not in your threat model? > > Yes, you're right. However, I think we shouldn't overlap too much with > Scramblesuit. I was thinking that Scramblesuit or obfs3 could be used > together with this PT. Actually this is a question I wanted to ask > you: can multiple PTs be used together? Except for the overhead of the > protocol headers I don't see any technical limitation. Not as well as we would like. Further improving our designs for combining PTs and adding an implementation is one of our GSOC projects this year though. My 0.02 dogecoin here would be to say "the PT combiner will fix it, so eventually we could do wfpadtools + obfs3/obfs4/scramblesuit/meek/fte and get the added defenses without (many? any?) code changes. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 and ntor (question wrt node_id)
On Mon, 02 Jun 2014 16:12:03 +0100
George Kadianakis wrote:
> Yep, that's what I gathered too.
>
> Unfortunately, the server-side obfs4 might not have access to its
> address/port (it normally knows that it has to bind to 0.0.0.0:,
> not the actual external IP address).
>
> So we were considering whether generating a random nodeid would be OK
> for security.
> Or even omitting the nodeid completely, and just using the public key
> B in its place (since \hat{B} is just used as an one-to-one map to a
> B) Or does this complicate the security proof?
Unless I'm horrifically mistaken, a random nodeid is fine as it is just
as arbitrary as the current node ID. Since there isn't any tight
coupling between pluggable transports and the remote bridges they
connect to, the bridge fingerprint currently in use is also a "random
nodeid", at least as far as obfs4 is concerned (The fact that it
coincidentally happens to be the bridge fingerprint has no effect on
the obfs4 protocol itself).
Regards,
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] GSoc update #2 - Stegotorus security enhancement
On Mon, 23 Jun 2014 21:04:25 -0500 Noah Rahman wrote: > - implemented the Elligator handshake on a circuit level. I need to > look into implementing it on a connection level to add greater > security, as well as adding OCB encryption (does anyone know for sure > whether this is in OpenSSL now? I can't seem to find out) As far as I know, "no, it is not". Even if it were, depending on it to be present would probably be a bad idea as there are systems in the wild that ship older versions of OpenSSL. Rogaway's page has a link to Krovetz's implementation that can use OpenSSL for certain internals, it would probably be easiest to look at that, and use it if suitable. Out of curiosity, from what I have seen of the code, there's already code that uses GCM, I'm sort of curious as to why you believe OCB would be better. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] What little-t-tor bridge features/issues we should address?
On Mon, 14 Jul 2014 12:30:06 -0700 Kevin P Dyer wrote: (This is orthogonal to the bridge code, but since you asked...) > I would like to be able to bind to privileged ports when running a > PT-enabled bridge in managed mode --- will any changes to > little-t-tor be required for this feature? (Assuming Lenooks for the sake of discussion.) At the dev meeting I was talking to dgoulet about having tor do the appropriate work to preserve the CAP_NET_BIND_SERVICE when dropping root so all PTs transparently get this capability. He mentioned difficulties with our python PTs, probably because the ServerTransportPlugin line was pointing directly at the script and it was getting invoked via the #! handler in the kernel. It may be possible that this "just works" if the ServerTransportPlugin line pointed at the python interpreter instead, but if it does not, this will probably require a kernel patch, that won't ever get accepted upstream. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] DEFAULT_ROUTE_LEN [was: Silly (or not so silly) question]
On Thu, 24 Jul 2014 16:48:21 -0400 grarpamp wrote: > On Wed, Jul 23, 2014 at 6:34 PM, Roger Dingledine > wrote: > > On Wed, Jul 23, 2014 at 11:24:47PM +0100, Noel David Torres Taño > > wrote: > >> What would happen if a Tor node changes behaviour and uses four or > >> five relay steps instead of three? > > At around DEFAULT_ROUTE_LEN 8 or above I get a lot of these, with > EXTEND being shown in various command locations, and no connectivity > to hidden services. Lower values or 4 or 5 probably work just fine > but I didn't bother testing more than a couple clearnet and onion > circuits since it's not yet a controller/config tunable and thus takes > edit/compile/run time. So even my test of 9 > 5 > 7 > 8 take with > salt. Don't know if this likely represent a bug to test more, or just > timeouts... the circuits that did work setup in times not feeling > much more than time/3*LEN. I'd suggest an undocumented tunable and > unit test if it's worth research/statistic/function_checking purpose. > > > relay_send_command_from_edge_(): Bug: Uh-oh. We're sending a > RELAY_COMMAND_EXTEND cell, but we have run out of RELAY_EARLY cells on > that circuit. Commands sent before: > (unrecognized),(unrecognized),(unrecognized),(unrecognized),EXTEND,EXTEND,(unrecognized) This is working exactly as specified, and despite the error message, is not a Bug. The number of hops each circuit can extend to is limited by the number of RELAY_EARLY cells allowed per circuit (8), as EXTENDs that are not contained in RELAY_EARLY are dropped. Roger linked prop 110, but this is also documented in the tor-spec (section 5.6). Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
On Fri, 25 Jul 2014 10:00:01 +0200 Lunar wrote: > isis: > > > We can't just make Tor Browser stop accepting obfs2 because some > > > people are using obfs2 bridges right now. But we shouldn't add > > > more people to the set of users of a broken protocol. > > > > Obfs3 is also "broken", it's just that we haven't yet seen a DPI > > box do it IRL. > > That's news to me. Any pointers? Well, the protocol is ok, but it is vulnerable to active probing (eg: See something they don't recognize, flag the destination IP/Port, call back later). Doing so on a mass scale is *quite* expensive since the obfs3 handshake isn't exactly cheap, but probably is in the reach of a nation-state adversary (China springs to mind). There also are a few interesting statistical attacks that are possible vs the obfs3 protocol if you make guesses about the inner payload, but such things are unnecessary for obfs3 (and ScrambleSuit/obfs4 both have some defenses against those, although not all are enabled as a performance tradeoff). Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
On Fri, 25 Jul 2014 13:25:31 +0200 Lunar wrote: > isis: > > > We can't just make Tor Browser stop accepting obfs2 because some > > > people are using obfs2 bridges right now. But we shouldn't add > > > more people to the set of users of a broken protocol. > > > > Obfs3 is also "broken", it's just that we haven't yet seen a DPI > > box do it IRL. If you want me to only hand out the holy grail, I'm > > never going to hand anything out. > > The holy grail will never exist, indeed. I fail too see why this would > be a reason to continue giving out solutions that are known to be bad > when they have suitable replacement. For what it's worth, the official plan is to kill off obfs2 once we figure out how we want to handle deprecating old transports. https://trac.torproject.org/projects/tor/ticket/10314 Personally I think when we deploy the next round of transports (meek, and either ScrambleSuit or obfs4) would be the right time to revisit this, and I can't think of a good reason to keep obfs2 around beyond "there are bridges that only support obfs2" which is a fairly terrible reason keep distributing the protocol to new users. My other objection to the idea a while back was that Orbot only supported obfs2, but that's been fixed for a while now. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
On Fri, 25 Jul 2014 22:19:40 + isis wrote: > > Personally I think when we deploy the next round of transports > > (meek, and either ScrambleSuit or obfs4) would be the right time to > > revisit this, and I can't think of a good reason to keep obfs2 > > around beyond "there are bridges that only support obfs2" which is > > a fairly terrible reason keep distributing the protocol to new > > users. > > Scramblesuit is "deployed", if you ask me... We've got roughly 2221 > scramblesuit supporting bridges. Kind of. TBB/Orbot and the FirefoxOS code all need to move to 0.2.5.x for those bridges to actually be useful which I belive is Real Soon Now. Just having bridges that only people that build stuff on their own can connect to is a bit silly. > > My other objection to the idea a while back was that Orbot only > > supported obfs2, but that's been fixed for a while now. > > So... I'm going to wait for an update from the Huggable Transport > folks, telling me to phase out obfsXYZ, whenever that happens. Until > then, obfs3 is still the default transport distributed. > > Does this sound okay to everyone? Otherwise you're shoving me back > into the hell where I get yelled at if I don't make a unilateral > decision, and also get yelled at if I do make a decision. It's kind > of annoying to get yelled at all the time. :( That's fine by me. I belive obfs3 should be ok for a while, and there are easier ways to identify bridges via active probing than doing on obfs3 handshake anyway (Fixing such things is also on my TODO list). Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] (meek|flashproxy)+(obfs3|fte|scramblesuit|...)
On Sat, 26 Jul 2014 15:08:38 +0100 Kevin P Dyer wrote: > Are there any roadblocks that prevent us from doing the following? > > 1. Remove the hard-coded bridge_prefs.js in the TBB. Ok. > 2. Set meek as the default pluggable transport in the TBB. Sure that's also fairly easy. > 3. Use meek to acquire an up-to-date bridge_prefs.js from, say, > torproject.org. Whowa, what? I get (from other parts of the thread) that there are compelling reasons for this, but I can think of at least two reasons why I would be massively against this. a) Who is going to pay for this? The amount of data transferred will grow to be non-trivial rather quickly because each user that ends up doing this will do the full bootstrap. Granted, this will be a one time thing per bundle release (and a one time thing over the lifespan of the client in some magical world where TBB has an update mechanism), so the economic side in the future isn't quite as dire, but still. b) Giving anyone a list of a subset of our users (and a particularly vulnerable subset at that, since they need to use PTs), seems dangerous at best. Going from "all meek users need to trust $CDN" to "the default behavior is to give $CDN a list of anyone trying to use PTs" at first glance seems like something that will only end badly. > 4. Use the information from the acquired bridge_prefs.js to connect > to Tor as normal. No clue as to how hard this is. > Ostensibly, this doesn't do a better job of hiding bridge addresses. > However, it allows us to modify bridge addresses without releasing a > new TBB. I don't see that as being a sufficiently compelling reason to give a third party the ability to enumerate (a unknown fraction of) the PT user base (while making them rich at the same time). Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PKCS#1 ASN.1 Public Key Encoding
On Sun, 17 Aug 2014 16:19:56 +0100
Gareth Owen wrote:
> I'm trying to generate the fingerprint given just the pubilc key in
> Java and after almost a whole day I'm about to give up. Does anyone
> have a sample PKCS#1 encoded public key that is used immediately
> before SHA-1 to generate the fingerprint? e.g. a hex string is what
> I'm after.
Both descriptors and microdescriptors contain this in the appropriate
format (albeit Base64 encoded and with a PEM envelope). Check the data
directory of a running tor instance and look at
cached-microdescs(.new), which will have onion-key entries for all the
relays.
> It seems there are subtle ways that an PKCS#1 can vary while encoding
> the same information which affects the hash, Java seems to be doing
> it one way, OpenSSL another, an example on stack overflow adds an
> extra field, etc.
The way that you care about (that matches how tor does it) is specified
in RFC 2313.
7.1 Public-key syntax
An RSA public key shall have ASN.1 type RSAPublicKey:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e }
(This type is specified in X.509 and is retained here for
compatibility.)
How to do this in Java depends on which crypto API you are using, look
at oracle.security.crypto.asn1 or org.bouncycastle.asn1. Additionally
this (http://lapo.it/asn1js/) will probably be useful.
Regards,
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] obfs4 test bundles
Hello all, So after a brief pause in my productivity due to the dev meeting and some IRL things, I'm back in the swing of development and have been working on getting obfs4 ready for development. I've recently mostly finished a fairly large cleanup/refactor of the obfs4 codebase and dusted off the Tor Browser build integration patch. Test bundles signed with my PGP key are available at: https://people.torproject.org/~yawning/volatile/tor-browser-obfs4-20140820/ Some quick notes: * The bundles are alpha. DO NOT USE THEM IF YOU REQUIRE STRONG ANONYMITY OR SECURITY. * While it is possible to pull out the obfs4proxy binary from the bundle and use it to run a bridge, that will be a *terrible* idea because the bundles are missing some logging related fixes. * The Windows and OSX bundles are entirely untested, because I do not have access to either platform. The Linux bundle appears to work. * Using obfs2/obfs3 will also exercise new code (obfs4proxy instead of obfsproxy). * I'm not uploading a 32 bit linux bundle for now. * The one obfs4 test bridge is mine, and is the one I posted to tor-dev@ (port is different, bridge parameters are the same). If you wish to follow obfs4 deployment the bug associated with this task is #12130. Questions, comments, feedback welcome. -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 test bundles
Hello everyone, I just uploaded a new set of obfs4 test bundles to: https://people.torproject.org/~yawning/volatile/tor-browser-obfs4-20140829/ I forgot to change the file names (oops), but that shouldn't affect the bundles and regenerating them just to rename/reversion would take quite a while, so I'll pass on doing so. Changes since the last version: * obfs4proxy * obfs4proxy -v will print versioning information. * Bridge side logging will sanitize golang networking errors unless the log scrubber is disabled. * Bridge lines now use Base16 instead of Base64 to work around bugs in the pt bridge args processing. * A dumb bug that was causing TYPE_PRNG_SEED frames to be silently ignored was fixed. * Bridge lines now have "iat-mode" which controls Inter-Arrival Time obfuscation. This is done so the bridge administrator can specify client behavior (Default is to disable IAT obfuscation). * There is now an optional paranoid IAT obfuscation mode, which disables optimizations made around bulk data transfer for additional obfuscation. This has a major impact on bulk data throughput and is not recommended. * Bundling * The #12535 patch is integrated into the goptlib build process, and go based pluggable transports will use SOCKS5. Eventually the patch will be merged into goptlib proper. * The default test bridge was updated to the new bridge line format, and includes the "iat-mode" argument. * The obfs4proxy and Go licenses are now included in the bundle. I have verified that the linux64 and windows (thanks to a friend) bundles appear to be functional. If you wish to follow obfs4 deployment the bug associated with this task is #12130. Questions, comments, feedback welcome. -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 test bundles
Hello everyone, I just uploaded a new set of obfs4 test bundles to: https://people.torproject.org/~yawning/volatile/tor-browser-obfs4-20140926/ Changes since the last version: * obfs4proxy * Updated to 0.0.2 (Most of the changes are related to packaging and a minor bridge side quality of life feature, no real functional changes since the last version from a client perspective.) * Bundling * Rebased my integration branch on Tor Browser 4.0-alpha-3. * I backed out the goptlib SOCKS5 code since I changed the patch a bunch. IPv6 obfs2/3/4 bridges will probably not work because of this, but that is a know issue, and the patch is sitting in a branch awaiting review and a better opportunity for systematic testing. To be perfectly honest not much has changed to the point where it really warrants another release, but apparently people are still using my old snapshots, so here's a new set for those people that folds in all the changes that went into the Tor Browser side of things. As far as the roadmap for full fledged deployment goes, it's at the "get enough bridges" point, with the step after that being "getting the Tor Browser folks to merge my branch". I have verified that the linux64 and windows (thanks to a friend) bundles appear to be functional. If you wish to follow obfs4 deployment the bug associated with this task is #12130. Questions, comments, feedback welcome. -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] tor-fw-helper redux
Hello, "You are in a maze of twisty little firmwares, all terrible". I'm at the point where the new and improved firewall helper could use some additional testing by various users, though there's some issues with the design that still need to be resolved. But not being one to keep issues inherited from the original from stopping progress... Code: https://github.com/yawning/go-fw-helper Bug: https://trac.torproject.org/projects/tor/ticket/13338 Yes, it's another Go app. It should work both as a helper for tor (PortForwardingHelper in the torrc), and for flashproxy. I am currently only concerned about the latter use case since it will immediately make flashproxy more useful in various environments, and I'm not sure people that can't setup port forwarding should be running relays in the first place. How to test it: $ go build github.com/yawning/go-fw-helper One of: * Play with it by hand. "-h" dumps usage. * Edit the torrc-defaults file shipped with Tor Browser to have flashproxy use the helper. On the Linux bundle the file in question is located at tor-browser_en-US/Browser/TorBrowser/Data/Tor The flashproxy ClientTransportPlugin line should look something like: ClientTransportPlugin flashproxy exec ./TorBrowser/Tor/PluggableTransports/flashproxy-client --port-forwarding-helper=/path/to/go-fw-helper --register :0 :9000 You *can* edit where it says "9000" to use a different port, but having it auto assigned will lead to it being harder to remove when done. * Try running a tor relay using PortForwardingHelper. I personally don't recommend this, and haven't tested it at all, but there's no reason why it won't work unless the tor side of the code rotted (unlikely?). Caveats: * Not sure which version of the Go compiler/runtime this requires. Development was done on 1.3.3. It probably requires 1.2.x but it may work on older versions (Not a bug/WONTFIX). * UPnP discovery requires being able to listen on a UDP traffic and accept incoming packets. Your local firewall may prevent this. (Not a bug/WONTFIX). * flashproxy does not know how to deal with mappings expiring, so things will stop working after 2 hours if NAT-PMP is used. * Neither flashproxy nor tor know how to use go-fw-helper to delete mappings, because tor-fw-helper did not have such a thing. WARNING: If UPnP is used as the protocol, mappings are indefinite. You will need to use the router's admin interface or "go-fw-helper -d" to remove it. Yes, there is a very good reason why this is like this, despite the protocol on paper having the length as a registration time parameter. Note: NAT-PMP mappings obtained by go-fw-helper last for 2 hours. * go-fw-helper's "-T" option doesn't do everything tor-fw-helper's does. (Meh?) * The UPnP mapping description is hard coded to "Tor relay" to match tor-fw-helper. Useful extensions over tor-fw-helper: Dump all current mappings with: $ go-fw-helper -l Remove mappings with: $ go-fw-helper -d ([]:] Both of those options only work with UPnP because NAT-PMP does not have a method of querying mapping information, and because at least one NAT-PMP implementation deployed on a lot of routers does not handle removal correctly (Bug reported to maintainer, and fixed in master but people do not update router firmware enough. There is a way to force go-fw-helper to let you delete port forwarding entries, but it's intentionally undocumented, because I don't want to support it.) Force a certain protocol (Case sensitive): $ go-fw-helper --protocol=NAT-PMP ... $ go-fw-helper --protocol=UPnP ... Tested on: * 64 bit Linux * 64 bit FreeBSD 9.3 * 32 bit Windows 7 Need testing on: * Darwin (esp with NAT-PMP) * With more routers than the 2 I have immediate access to. If something breaks "-v" gets you debug output. Questions, Comments, Feedback appreciated, -- Yawning Angel pgpWsPVIzWZO3.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor-fw-helper redux
On Sun, 26 Oct 2014 02:07:26 -0700 David Fifield wrote: > On Sun, Oct 26, 2014 at 08:41:08AM +0000, Yawning Angel wrote: > > Hello, > > > > "You are in a maze of twisty little firmwares, all terrible". > > > > I'm at the point where the new and improved firewall helper could > > use some additional testing by various users, though there's some > > issues with the design that still need to be resolved. But not > > being one to keep issues inherited from the original from stopping > > progress... > > > > Code: https://github.com/yawning/go-fw-helper > > Bug: https://trac.torproject.org/projects/tor/ticket/13338 > > This is great. Is there any reason not to call it tor-fw-helper, and > replace/deprecate the existing src/tools/tor-fw-helper? No particular reason for the former. This could even be done at the packaging step since I kind of don't want to move the repo. I think, assuming people like my stab at this, that having it live in it's own space under git.tp.o somewhere would be best. > I'm thinking that as a conservative step, we should first deploy > using a static external port for flash proxy. An ephemeral port is > better for scanning resistance, but there is also the risk of poking > long-lasting holes in firewalls and overflowing port forwarding > tables in these shoddy routers. Indeed. It has no external dependencies so adding it to the build process should be trivial, just not something I've bothered with yet. > We need at least to add a loop to where flashproxy-client calls the > port forwarding helper. Ideally we would also try to remove the > mapping before exiting. We could do it in the first SIGINT > handler--though we know that SIGINT handling doesn't work on Windows > because tor immediately zaps you with TerminateProcess. We could do > something like we do with terminateprocess-buffer and > meek-client-torbrowser, and add an --exit-on-stdin-eof option to > flashproxy-client so that it can detect when it is supposed to shut > down gracefully. I'm not sure it's worth it though, especially if > unmapping ports is unreliable. I would think it's worth trying to do so, particularly if ephemeral ports are used. NAT-PMP mappings (the one that has routers that have trouble unmapping), have a sane lifespan (currently 2h, but changing this is trivial). As far as I know removing UPnP mappings should always work, and that's the protocol that needs infinite duration mappings due to firmware badness. There's no harm in trying to unregister mappings. Unless the undocumented flag is set, go-fw-helper will just fail to remove NAT-PMP mappings with an internal error. I changed the reporting for the deregistration process to mostly match the registration as well, so automating this is straight forward. I may reconsider disallowing NAT-PMP deregistration since the router side implementation where I found the bug supports both UPnP and NAT-PMP, and so in such environments UPnP should be used anyway due to how the code is setup. > We'll need a tor-browser-bundle branch that builds go-fw-helper and > adds it to the ClientTransportPlugin line. I'll look at adding the > flashproxy-client loop. > > > * The UPnP mapping description is hard coded to "Tor relay" to > > match tor-fw-helper. > > Is there any way to omit it or leave it blank? I thought there was a > ticket somewhere about "Tor relay" making Tor use more conspicuous, > but I can't find it now. It's a constant in the UPnP code. This is also trivial to omit/change, if people want it to be different, but having it well defined makes the admin side of things easier. NAT-PMP doesn't have a description field. As a side note, before I sent the e-mail, I was browsing the web for a bit with flashproxy configured to use the helper, so at least in my test environment things work as expected. -- Yawning Angel pgpVJ0UyNHcWA.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Vidalia Relay Bundle(win) Tor version, obfs4proxy package in deb.tp.o
On Sun, 26 Oct 2014 17:16:46 +0200 s7r wrote: > 3. Last thing, the page https://bridges.torproject.org/ does not > contain obfs4 in the drop-down list where the user needs to select the > pluggable transport. It only allows requests for obfs2, obfs3, > scramblesuit and fteproxy bridges. Don't know about fteproxy, but > shouldn't obfs2 be deprecated or is it still working/used? A note on this (I don't handle packaging, sorry). obfs4 propbably should be added to the dropdown once there is a critical mass of bridges in the database, and when obfs4 is in official Tor Browser builds. As far as I am aware, the official integration (as opposed to my obsolete not-really-working-anymore snapshots) is scheduled to happen in the next alpha series. Regarding obfs2, it still "works" in some environments if the DPI used by the censor is not particularly sophisticated (not targeted specifically at detecting obfs2). I personally think that it should be deprecated sooner rather than later, but others have disagreed with me on this. Hope that helps, -- Yawning Angel pgpRkxhRUfSjM.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Understanding Tor and SOCKS
On Sun, 26 Oct 2014 14:34:59 +0100 Rob van der Hoeven wrote: > So, the SOCKS protocol supports redirection to another SOCKS server. > An all-zero address/port simply means: use the server/port that you > are currently connected to. That's a really interesting way of interpreting that part of the RFC. The reason why BND.ADDR and BND.PORT are supplied in a SOCKS5 response is to provide the client with the information equivalent to calling getsockname() on a non-proxied socket. In the context of tor, the reason why BND.ADDR and BND.PORT are all NUL bytes is because the RELAY_CONNECTED cell does not propagate BND.PORT backwards to the client from the exit. BND.ADDR could technically be filled in (since the tor client knows where it is exiting from), but I don't see much point (and this information is useless at best in the context of HSes). Regards, -- Yawning Angel pgpGA5tzki8YH.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Hidden Service authorization UI
On Sun, 9 Nov 2014 16:19:24 + Andrea Shepard wrote: > How would Tor Browser learn about this reason for not being able to > connect/ tell Tor the authentication info? This is starting to sound > like wanting SOCKS5 extensions to indicate different causes for > connection failures in #6031 did. Well prop 229 is on my todo list, though it's not very high up. The last time I spoke to people about this, it seemed like a nice to have but not massively important sort of thing, but I'd be more than happy to rearrange things in that department. Especially as my tenative plans for obfsng (aka obfs6 depending on how long it gets stuck in design and deployment) involves 1 KiB keys... Regards, -- Yawning Angel pgp1Omyydtsp8.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Pluggable transports meeting tomorrow (16:00UTC Wednesday 19th of November 2014)
Hello! just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks for your attention! -- Yawning Angel pgp17oIBtS3qf.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 questions
On Fri, 28 Nov 2014 13:08:04 + Michael Rogers wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > In the obfs4 spec I couldn't find a description of how the secretbox > nonces for the frames are constructed. A 16-byte nonce prefix comes > from the KDF, but what about the remaining 8 (presumably > frame-specific) bytes? It's a simple 64 bit frame counter (Big endian, starts at 1). Guess I never bothered to copy the relevant information from the gigantic comment in framing.go into the spec, oops. The code cuts the connection if the counter would wrap though that's unlikely at any sort of realistic data rate given the use case. > If an attacker changes the order of the secretboxes so that the > recipient tries to open a secretbox with the wrong nonce, is that > guaranteed to fail, as it would if the secretbox had been modified? I > can make a hand-wavy argument for why I think it will fail, but I > don't know whether the secretbox construct is designed to ensure this. Yes, the poly1305 verification will fail. > Any particular reason for using two different MACs (HMAC-SHA256-128 > for the handshake, Poly1305 for the frames) and two different hashes > (SHA-256 for the handshake, SipHash-2-4 for obfuscation)? No particular reason beyond "historical". Ntor is specified to use HMAC-SHA256, ScrambleSuit used HMAC-SHA256-128. I briefly toyed with sending 2 secretboxes one with the length, one with the payload, but that was kind of heavyweight, so I went with something lighter (Thus SipHash). I may go back to the two box design if I do an obfs5, not sure about that yet. Regards, -- Yawning Angel pgpgvpPIf0y5d.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 questions
On Fri, 28 Nov 2014 14:47:29 + Michael Rogers wrote: > I believe so too, but is it stated anywhere that this is a guaranteed > property of crypto_secretbox? The Poly1305 authenticator is calculated based on the payload and the nonce. In the case of the NaCL secretbox construct, 32 bytes of zeroes encrypted based on a one time key/counter derived from the actual key and the nonce. If the frames are reordered, the derived authenticator would be different. So yes, it is a property of crypto_secretbox because that's how Poly1305 works. It wouldn't be a workable AEAD mode if nonces (which usually are transmitted in the clear) could be modified undetected by attackers either. For more details see the original poly1305 paper[0] (nb: specified in terms of using AES for the nonce->16 byte string mapping, but that is arbitrary). > >> Any particular reason for using two different MACs > >> (HMAC-SHA256-128 for the handshake, Poly1305 for the frames) and > >> two different hashes (SHA-256 for the handshake, SipHash-2-4 for > >> obfuscation)? > > > > No particular reason beyond "historical". Ntor is specified to > > use HMAC-SHA256, ScrambleSuit used HMAC-SHA256-128. I briefly > > toyed with sending 2 secretboxes one with the length, one with the > > payload, but that was kind of heavyweight, so I went with something > > lighter (Thus SipHash). I may go back to the two box design if I do > > an obfs5, not sure about that yet. > > Interesting, thanks. Would SHA-256 be too slow for obfuscation? It > just seems like a lot of dependencies for a simple protocol. Probably not, but at that point, 2 boxes is also likely fine since it wasn't unusably slow. > For what it's worth, we're using the two-box approach for the next > version of the Briar transport protocol. I'm concerned about the > possibility of an attack conceptually similar to [1] against an > unauthenticated length field, even though that specific attack > wouldn't apply. This was brought up by phw during the obfs4 design phase. The code randomizes the length if it is invalid as per one of the suggested countermeasures in section 6 of the paper (So an identical failure to a modified plaintext/tag is observed). Regards, -- Yawning Angel [0]: http://cr.yp.to/mac/poly1305-20050329.pdf pgpD4SkRCdRkT.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 questions
On Fri, 28 Nov 2014 15:37:06 + Yawning Angel wrote: > The Poly1305 authenticator is calculated based on the payload and the > nonce. In the case of the NaCL secretbox construct, 32 bytes of > zeroes encrypted based on a one time key/counter derived from the > actual key and the nonce. If the frames are reordered, the derived > authenticator would be different. Ugh, I did a terrible job of explaining that, sorry to reply to myself. A one time poly1305 key is calculated for each box, based on 32 bytes of zeroes encrypted with a one time Salsa20 key/counter derived from the nonce and the box key. You can view the use of Salsa20 there as an arbitrary keyed hash function (in the case of the original paper, AES was used). Hope that clarifies things somewhat, -- Yawning Angel pgpxgTHsGjhbQ.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 questions
On Fri, 28 Nov 2014 17:57:26 +
Michael Rogers wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 28/11/14 15:50, Yawning Angel wrote:
> > A one time poly1305 key is calculated for each box, based on 32
> > bytes of zeroes encrypted with a one time Salsa20 key/counter
> > derived from the nonce and the box key. You can view the use of
> > Salsa20 there as an arbitrary keyed hash function (in the case of
> > the original paper, AES was used).
> >
> > Hope that clarifies things somewhat,
>
> Thanks - this is similar to the argument I came up with. I called my
> argument hand-wavy because it relies on HSalsa20 and Salsa20 being
> PRFs, and I don't know how big an assumption that is.
For what it's worth "7 Nonce and stream" both support using a counter
here as the nonce, and refers to 'The standard ("PRF") security
conjecture for Salsa20". IIRC the security proof for the extended
nonce variants also hinges on the underlying algorithms being PRFs as
well, so it's something I'm comfortable in assuming.
http://cr.yp.to/highspeed/naclcrypto-20090310.pdf
Regards,
--
Yawning Angel
pgpVJBifs9PS3.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Git hosting changes, git:// support discontinued
On Sun, 30 Nov 2014 17:32:05 -0500 Jason Cooper wrote: > > It is unauthenticated and you probably shouldn't use it if at all > > possible. > > How does that matter? All of the tags are signed by Nick Mathewson. > This allows the server *and* the path to be untrusted. What about intermediary commits between tagged releases? Yes, signing each commit is possible, and probably even a good idea, but it's not currently done. Regards, -- Yawning Angel pgpBtpnfUsqCQ.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Git hosting changes, git:// support discontinued
On Sun, 30 Nov 2014 19:19:58 -0500
Jason Cooper wrote:
> On Sun, Nov 30, 2014 at 11:55:31PM +0000, Yawning Angel wrote:
> > On Sun, 30 Nov 2014 17:32:05 -0500
> > Jason Cooper wrote:
> > > > It is unauthenticated and you probably shouldn't use it if at
> > > > all possible.
> > >
> > > How does that matter? All of the tags are signed by Nick
> > > Mathewson. This allows the server *and* the path to be untrusted.
> >
> > What about intermediary commits between tagged releases? Yes,
> > signing each commit is possible, and probably even a good idea, but
> > it's not currently done.
>
> git uses chained hashes so that verifying the integrity of the tagged
> commit also verifies the integrity of the previous commits between the
> prior tag and the current one (Actually, across the entire history,
> but once I've cloned and validated, I'm primarily concerned with
> commits from subsequent pulls).
So, I didn't communicate that well, so I'll try again:
Assuming people use the unauthenticated git protocol, and want to
clone a copy of master, maint-0.2.4 or maint-0.2.5, how do they ensure
that the copy they received is correct?
So "intermediary commits" as in "stuff that happens between releases,
with the next release having not happened yet" ('interim' would have
been a better word to use in hindsight). Sure you can validate up to the
last tag, but for all the commits that follow, there's no magic PGP
signed tag that covers those.
I don't see any reason to allow a unauthenticated protocol when
authenticated alternatives exist and are well supported in the first
place, but that's just me.
Regards,
--
Yawning Angel
pgpsUCIBbLyRC.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Pluggable transports meeting tomorrow (16:00UTC Wednesday 3rd of December 2014)
Hello! just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks for your attention! -- Yawning Angel pgpgttQ9aqVoM.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] basket: More eggs in the Guard basket.
Hi all, For several reasons I've been working on a bit of code that I named "basket". It's almost at the point where the brave members of the general public should be aware that it exists as a potential option in the privacy toolbox, though using it in any capacity beyond testing on a loopback device IS CURRENTLY ACTIVELY DISCOURAGED unless users are comfortable debugging it (This means, DO NOT USE IT. I will likely break backward compatibility in the future, and you will be sad.). "basket" is my stab at designing something that significantly increases Tor's resistance to upcoming/future attacks, by providing a link layer cryptographic handshake that uses post-quantum cryptographic primitives and defenses against website fingerprinting (and possibly e2e correlation) attacks. For the ease of development it is in the form of a pluggable transport with the expected tradeoffs (you must absolutely trust your Bridge, since both features only run to the Bridge). It is worth noting that it is anything but subtle, and it is blatantly obvious that a given connection is speaking "basket" as no attempt was made to obfuscate the handshake. The link layer handshake works roughly like thus: Setup: * Bob generates a long term SPHINCS256 keypair s,S used to sign responses. The handshake: 1. Alice generates a Curve25519 keypair x,X and a NTRUEncrypt EES1171EP1 keypair n,N. 2. Alice sends X | N to Bob. 3. Bob generates a Curve25519 keypair y,Y, and calculates Curve25519(y,X) as the shared secret. 4. Bob sends NTRUEncrypt(N,Y) | S | SPHINCS256(s, ntru_ciphertext | S) to Alice. 5. Alice verifies the SPHINCS256 signature (Alice's copy of S is saved/trusted in a Trust-On-First-Use manner), and decrypts the NTRU ciphertext to obtain Y. 6. Alice calculates Curve25519(x,Y) as the shared secret. NB: Some details omitted for brevity. Passive attackers see Alice's Curve25519 public key, Alice's NTRUEncrypt public key, Bob's SPHINCS256 public key, a NTRUEncrypt ciphertext, and SPHINCS256 signature. Obtaining the link's ephemeral session key requires decrypting the NTRUEncrypt ciphertext (to obtain Bob's Curve25519 public key), and reversing the scalar base multiply on one of X and Y. Active man-in-the-middle attackers need to be able to forge SPHINCS256 signatures to substitute their own NTRUEncrypt-ed payload to mount an attack (Alice's request is also validated/protected but it's one of the details omitted, read the code). As NTRUEncrypt is patent encumbered, there also is a handshake mode that removes the experimental post-quantum cryptography and uses Ed25519/Curve25519. The fingerprinting defenses are in the form of the CS-BuFLO algorithm in CTST (Client total, Server total) mode, without the application level hinting based optimizations to reduce bandwidth consumption (See: http://www3.cs.stonybrook.edu/~rob/papers/csbuflo.pdf). As a minor implementation refinement, "basket" uses the kernel information as described in the KIST paper to be more responsive to changing network conditions. Most of the CS-BuFLO parameters were adjusted in an attempt to compensate for the lack of said application level hinting, but "basket"'s CS-BuFLO implementation is still a lot more expensive than the one presented in the paper. The code: http://github.com/yawning/basket Notes: * The PQ crypto primitives used are ports to Go by yours truly based on the reference implementations. It is both possible and likely that I messed something up, so users should decide between trusting my implementations and using a handshake based on classical algorithms. * The "basket" handshake consumes a non-trivial amount of CPU on the server side due to the SPHINCS256 implementation being relatively unoptimized. * CS-BuFLO is EXTREMELY BANDWIDTH INTENSIVE, and if adversaries can observe the Bridge's upstream, it likely can be broken, especially if the Bridge is only servicing a handful of users. Running the defense end-to-end (or even to the middle relay) is *extremely* non-trivial, though that would be required if something more comprehensive is desired. * The KIST code is platform specific, and I only wrote the Linux version. If this ends up being useful to people, support for other platforms is possible. * "basket" was never written to be a general use transport, though it sits somewhere between obfsproxy-wfpadtools (a pure research framework) and obfs4proxy (something that is intended to be used in production) in terms of completeness. Thanks to Marc Juarez (KU Leuven) and Mike Perry for inspiration to write the CS-BuFLO component of "basket". Questions, comments, feedback appreciated as always, -- Yawning Angel ps: Seriously, unless you are a developer or researcher, you REALLY SHOULD NOT use
[tor-dev] Pluggable transports meeting tomorrow (16:00UTC Wednesday 17th of December 2014)
Hello! Just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks for your attention! -- Yawning Angel pgpmwTq6Jwj11.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] basket: More eggs in the Guard basket.
On Wed, 17 Dec 2014 13:51:02 -0500 Nick Mathewson wrote: [snipity] > Should the handshake also a signature by Bob of (X|N), and should > maybe the shared secret also include a digest of all the other parts > of the communication? Hmm, maybe I shouldn't have left bits out, and I really do need to document the handshake component of the protocol. The former is actually done, a BLAKE-256 digest of the entire client request is included in Bob's response and is covered by the signature. The client verifies that Bob received a unmodified request, after checking the signature. There's no reason why the signature can't just include the entire request here if that's better. Including a digest of everything sent as part of the shared secret seems like a good idea, so I shall revise the protocol to do that (digesting < 50 KiB of data isn't that big of a deal given how heavyweight the other crypto bits are). Regards, -- Yawning Angel pgpI20qKE8Gnl.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] N reasons why the spooks love Tribler (Number N' will surprise you)
% (2^128) This is fatally broken and insecure on several fronts. a) "StrongRandom" is Mersenne Twister seeded once via os.urandom(). What little "StrongRandom" actually resembles something that is "Strong" and "Random" is due to the Python developers, though in practice it is neither. b) The GMP LCG is seeded with 32/64 bits of "entropy", where "entropy" is Mersenne Twister output. c) GMP's LCG is used for key generation. * How not to do Diffie-Hellman: key = pow(dh_received, dh_secret, DIFFIE_HELLMAN_MODULUS) This is relatively minor since recovering the secret key is trivial via PRNG attacks, so the fact that the modular exponentiation is not constant time matters less. * How not to do RSA: def rsa_encrypt(key, element): assert isinstance(element, (long, int)), type(element) _element = mpz(element) return long(pow(_element, key.e, key.n)) def rsa_decrypt(key, cipher): assert isinstance(cipher, long), type(cipher) _cipher = mpz(cipher) return long(pow(_cipher, key.d, key.n)) RSA being implemented without blinding, using GMP's modular exponentiation, and without OAEP is something I pray that I never see again. Things not covered: * How the intro point/rendezvous system works, including peer discovery and etc (Assuming it is trivial to obtain lots of ECElgamal keys/IP address:Port combinations of endpoints, it appears that it is possible to use the CREATE/CREATED response to mount an UDP amplification attack. But I did not check how easy this would be to mount in practice.) * The bittorrent bits. * The "dispersy" component beyond "ok, at least the ECElgamal key generation uses M2Crypto, assuming the horribly broken keygen code (community.privatesemantic.crypto.ecelgamal.ecelgamal_init()) is dead like I think it is". Recommendations: * For users, "don't". Cursory analysis found enough fundamental flaws, and secure protocol design/implementation errors that I would be reluctant to consider this secure, even if the known issues were fixed. It may be worth revisiting in several years when the designers obtain more experience, and a thorough third party audit of the improved code and design has been done. * For the developers: * Use a CSPRNG when doing key generation. Neither GMP's LCG nor Mersenne Twister are CSPRNGs, even if they are seeded from "StrongRandom" that actually is a "StrongRandom" (rather than a horrible misnomer). * Add a construct similar to RELAY_EARLY. * Add authenticated encryption to cell payload. This will break wire compatibility. * Use constant time modular exponentiation. As a matter of fact, don't include your own implementations of ECElGamal, RSA, and Diffie-Hellman. Use well tested/known secure library code instead. * Blind RSA operations, use padding as appropriate. * Fix the symmetric encryption somehow, after obtaining a in-depth understanding of what things break security of the mode you wish to use in various ways (Eg: IV/Nonce reuse). See: http://web.cs.ucdavis.edu/~rogaway/papers/modes.pdf * Instead of a DH + ElGamal handshake, consider Ntor. Even with GMPY, doing modular exponentiation is relatively CPU intensive, and there is the threat of CPU exhaustion attacks here. * Clean out all the dead code, after printing out copies to use to scare small children. Eg: Tribler/community/privatesemantic/crypto/elgamal.py Most of the fixes require major revisions to the wire protocol. As it appears that there is no versioning, how that will be done is left as an exercise for the student. Alternatively, rebase the system on I2P. Regards, -- Yawning Angel pgpGSqhEPfHVU.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor BSD underperformance (was [Tor-BSD] Recognizing Randomness Exhaustion)
On Thu, 1 Jan 2015 14:19:08 +1100 teor wrote: > On 1 Jan 2015, at 07:39 , Greg Troxel wrote: > > Tor 0.2.6.2-alpha (just in the process of being released) has some > changes to queuing behaviour using the KIST algorithm. > > The KIST algorithm keeps the queues inside tor, and makes > prioritisation decisions from there, rather than writing as much as > possible to the OS TCP queues. I'm not sure how functional it is on > *BSDs, but Nick Mathewson should be able to comment on that. (I've > cc'd tor-dev and Nick.) I don't think we merged that branch yet, since it's not ready for general use. Additionally, it's not currently functional on the *BSDs. The KIST code last I checked only is used under Linux. While the full portability story is in #12890 it looks roughly like: * Linux - Supported. * Windows - Possible, needs code in tor. * Darwin - Possible, uses interfaces marked as undocumented/internal. * FreeBSD - Requires a trivial kernel patch (interface is there, information exposed is incomplete). * Other BSDs - Requires a kernel patch, which is more involved than the FreeBSD one (implementing the required interface vs exposing more information). The patch is still trivial for anyone that's familiar with the TCP/IP code. I don't think we should be in the business of maintaining kernel patches either, so I'm not sure what the right thing to do would be for non-Darwin *BSD. Regards, -- Yawning Angel pgpus7JlLTwWJ.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] gettimeofday() Syscall Issues
On Thu, 01 Jan 2015 23:42:42 -0500 Libertas wrote: > The first two account for the bulk of the calls, as they are in the > core data relaying logic. > > Ultimately, the problem seems to be that the caching is very weak. At > most, only half of the calls to tor_gettimeofday_cached_monotonic() > use the cache. It appears in the vomiting print statements that > loading a single simple HTML page > (http://www.openbsd.org/faq/ports/guide.html to be exact) will cause > >30 gettimeofday() syscalls. You can imagine how that would > >accumulate for an exit carrying 800 KB/s if the caching > doesn't improve much with additional circuits. So while optimization is cool and all, I'm not seeing why this specifically is the underlying issue. Each cell can contain 498 bytes of user payload. Looking at things simplistically this is 800 KiB/s -> 1644 cells/sec, leaving you with approximately 608 microseconds of processing time per cell. On my i5-4250U box, gettimeofday() takes 22 ns on Linux, and 2441 ns on FreeBSD. I'm not sure how accurate the FreeBSD results are as it was in a VirtualBox VM (getpid() on the same VM takes 124 ns). If someone has a OpenBSD box they should benchmark gettimeofday() and see how long the call takes. Taking the FreeBSD case (since we know that tor works fine on Linux), a single gettimeofday() call takes approximately, 0.39% of the per-cell processing budget. For reference (assuming gettimeofday() in *BSD really is this shit performance wise), 7000 calls to gettimeofday() is 17.09 ms worth of calls. The clock code in tor does need love, so I wouldn't object to cleanup, but I'm not sure it's in the state where it's causing the massive performance degradation that you are seeing. Regards, -- Yawning Angel pgpN7QOVVGLMt.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] gettimeofday() Syscall Issues
On Fri, 2 Jan 2015 23:18:16 +1100 teor wrote: > IPredator has complained that tor on Linux spends too much time > calling time() when pushing 500Mbit/s, which is an issue for them > under 3.x series kernels, but not kernel 2.6. > > https://ipredator.se/guide/torserver#performance I really don't understand this, unless my benchmark methodology is overly naive. time() in a trivial benchmark takes roughly 3 ns per call. Linux doesn't even do a real syscall for gettimeofday() due to vDSO... > I just reviewed my profiling of an exit relay running chutney verify > with 200MB of random data. This is on OS X 10.9.5 with tor > 0.2.6.2-alpha-dev running the chutney basic-min network. > > The three leaf functions that take the most time in the call graph > are: > * channel_timestamp_recv > * channel_timestamp_active > * time > > Each of these functions takes around 16% of the execution time, the > next nearest function is sha1_block_data_order_avx on 4%. > > While I understand that OS X, BSD, and Linux syscalls aren't > necessarily identical, we now have results for the following > platforms suggesting that calling time() too often has a performance > impact: > * Linux kernel 3.x > * OpenBSD > * OS X 10.9 > > My results suggest a maximum performance improvement of 15% on OS X > if we reduced the calls to time() to a reasonable number per second. I'm still skeptical, but hey, the code needs love in general. Maybe nickm/dgoulet have more insight into this than I do, and this would also be a good opportunity to switch more things over to monotonic time. Regards, -- Yawning Angel pgpyHZsfFsxzw.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Fwd: gettimeofday() Syscall Issues
On Fri, 2 Jan 2015 18:15:06 -0500 grarpamp wrote: > On Fri, Jan 2, 2015 at 12:24 PM, Konstantin Belousov > wrote: > > On Fri, Jan 02, 2015 at 09:09:34AM -0500, grarpamp wrote: > >> Some recent FreeBSD related questions in this app area. > >> > > What is the question ? > > > > As a background, I can repeat that FreeBSD implements syscall-less > > gettimeofday() and clock_gettime() for x86 machines which have > > usable RDTSC. The selection of the timecounter can be verified > > by sysctl kern.timecounter.hardware, and enabled by default fast > > gettimeofday(2) can be checked by sysctl > > kern.timecounter.fast_gettime. > > > > On some Nehalem machine, I see it doing ~30M calls/sec with enabled > > fast_gettime, and ~6.25M calls/sec with disabled fast_gettime. This > > is measured on 2.8GHz Core i7 930 with > > src/tools/tools/syscall_timing. > > > > Check your timecounter hardware. Since it was noted that the tests > > were done in VM, check the quality of RDTSC emulation in your > > hypervisor. This all is kind of a moot point because even if the relevant time calls did take ~2 usec it still doesn't explain the performance issues, and my curiosity is close to being exhausted. But, for what it's worth. Forcing the timecounter hardware source to "TSC" in my VM results in a saner value (~45 ns). That said, I'm not sure if the clock source is actually sane. A quick skim through the code suggests that there's a decent number of things that would keep the TSC from being used, though VirtualBox supports the P-state invariant TSC cpuid bit (Linux picks it up), so why I'm seeing this behavior eludes me. Curiosity exhausted at this point, -- Yawning Angel pgp7pv29CGVwL.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Pluggable Transports 2.0, draft 1 Specification
On Mon, 27 Mar 2017 04:03:47 -0500 Brandon Wiley wrote: > I am familiar with the dual stack problem generally, where servers > have both IPv4 and IPv6 IP addresses. I was not involved in any > conversations regarding the dual stack problem for Pluggable > Transports specifically. If you could point me to any documentation > on this issue, that would be helpful. Alternatively, if you could > explain what the issue is and what possible solutions you'd like to > see in a future Pluggable Transports specification, that is something > we could make happen in future specifications revisions. None of the things I've mentioned are new concerns, and I brought all of them up (and more) a long time ago back when I was giving thought to the PT spec. I've basically given up at this point, and to be honest I gave up shortly after I initially started making noises about improving the spec because it was clear that while I was trying to improve the existing interface while preserving the overall architecture, everyone else was far more interested in "lets make everything into a bunch of library code". https://lists.torproject.org/pipermail/tor-dev/2015-September/009432.html https://trac.torproject.org/projects/tor/ticket/21261 https://trac.torproject.org/projects/tor/ticket/11211 Regards, -- Yawning Angel pgp_mZKMWdACY.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Control-port filtering: can it have a reasonable threat model?
x can get certain information about what firefox is doing, if the user configures it that way, otherwise, all it can do is repeatedly NEWNYM" is what I think I ended up with. Though I have the benefit of being able to force all application network traffic through code I control, which makes life easier. Regards, -- Yawning Angel pgptOXuQ3TKU8.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Comments on proposal 279 (Name API)
On Fri, 7 Apr 2017 11:44:03 +0100 Alec Muffett wrote: > If I was in charge, I would say that we risk overthinking this, and it > would be better to: > >- mandate use of fully DNS-compliant syntax, including but not > limited to: acceptable max length, max label length, charset and > composition Fully DNS-compliant only limits max length and max label length, unless there's something that supersedes RFC 2181. I'm fine with both of those restrictions. >- declare a registry of short, valid labels, in the > second-from-right position in the name >- reserve "tor" and "name" in that registry (ie: *.tor.onion, >*.name.onion) >- park the entire issue for 12 months I intentionally left a lot of this unspecified because one of the use cases I envisioned was an "/etc/hosts" analog that lets users easily: * Stick all their hidden services under their own name hierarchy. eg: git.yawning -> .onion * Increase mobile quality of life by aliasing their HSes to addresses consisting entirely of emojis. eg: 💯👏💩👏🖕.😫 -> .onion * Force redirect any site to anything else, really. eg: git.example.com -> .onion banner.ads.and.malware.example.com -> 127.0.0.1 social.spacebook.trackers.example.com -> 127.0.0.1 I could do this with MapAddress, but a plugin would make my life easier, especially since it beats editing multiple torrc files. (Going further into this rabbit hole, I assume most exits won't resolve the OpenNIC TLDs... What do I do if I want to view `example.pirate` or whatever over Tor?) > Hence "parking" the issue because this is all meaningless until > prop224 addresses ship, and there should be plenty of time in the > next 12 months for people to think about how to fill the usability > space with $PET_IDEA, and to my mind the changeover period between > 80-bit and 256-bit addresses should be long enough that nobody need > fret about it right now. IMO the existing onion addresses already are a usability disaster. It should be easy for researchers to experiment with designs to solve the problem *now* before prop224 addresses make a bad situation worse. There's also a world of difference between implementing/shipping the capability to override the name resolution via plugins, and "Shipping the YawningCoinNamezTLD plugin with Tor Browser, enabled by default". Regards, -- Yawning Angel pgpcFgEVzbcBe.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Comments on proposal 279 (Name API)
On Sat, 8 Apr 2017 08:47:51 +0100
Alec Muffett wrote:
> However: on this conference call it was made abundantly clear to all
> present - one could almost hear fingers being wagged - that it would
> be a bad thing for Onion addresses to (1) contain anything other than
> alphanumerics and non-leading-hyphens, (2) collide with IDNs and
> PunyCode.
>
> Now: I flatly do not know where this is documented; it may possibly
> be some intersection of DNS and HTTP RFCs, and if we want to take the
> approach that "everything should be permitted unless it is explicitly
> forbidden!" then yes we should go chase those documents down so that
> we have rationales for our self-imposed bondage.
Ironically, I struggled with this a bit when I pushed for making tor
clients reject "obviously malformed" destinations right when they hit
the SOCKS server.
From what I remember/can tell, RFC 1912 has the rules on what a valid
`hostname` is, RFC 2181 suggests that DNS server implementations should
not enforce restrictions on what a valid `hostname` is, and from
experience enforcing strict RFC 1912 on the real internet breaks
`nytimes.com`.
RFC 6125 mandates "LDH Lables" (RFC 5890), but is only applicable to
TLS.
> However if we want to seek the path of least resistance and effort,
> the answer is obvious to any seasoned network administrator:
>
> * alphanumeric
> * (whatever DNS label length)
> * (whatever DNS overall length)
> * single, and only single, dots at label separators
> * single, and only single, hyphens as spacers
> * (i'm trying to think if there are any more obvious constraints, but
> can't)
>
> ...which will traipse merrily through any system one cares to name.
tor currently enforces most of those (label length is notably not
checked), and also allows:
* `_` because `core3_euw1.fabrik.nytimes.com` despite what the RFCs
say.
* Trailing `.` used sometimes to make it explicit that the domain is
absolute.
See: https://gitweb.torproject.org/tor.git/tree/src/common/util.c#n1080
> That's a lovely idea; one more to add to the mix is the process
> documented at:
>
> https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md
>
> ...of hijacking addresses out of the DHCP network space and using
> them to configure interfaces with genuine, resolvable Onion names.
> It makes SSH and Apache configuration really clear when you can use
> the genuine onion address in configuration ("Listen") directives, etc.
>
> But then that's /etc/hosts - that's *not* what goes to a Certificate
> authority to be signed, and it's the latter that the committees get
> exercised about.
Sure.
> Hyphenation, readability studies, boutique & frou-frou name schemes
> invented at the Tech University of Mercedes-Benz, and other shooting
> ourselves in the foot can, and should, come later. :-)
I'd be ok with, and would likely even advocate for "If you want your
naming system to be shipped with Tor Browser, it should follow certain
guidelines, including mandatory syntax, a label registry, and etc",
which is a matter of policy.
But that to me is orthogonal to "there should be a flexible way to
offload name resolution" (a matter of implementation).
In practical terms the tor code would need modifications to allow
anything super exotic anyway, and I doubt anything will actually get
shipped with Tor Browser[0] till long after prop 224 is fully
implemented.
Regards,
--
Yawning Angel
[0]: As much as I hate the fact that port 80 and 443 are basically the
only things that matter, that's basically the situation.
pgpmAOpHG284K.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Control-port filtering: can it have a reasonable threat model?
On Mon, 10 Apr 2017 19:35:24 +0400 meejah wrote: > Obviously as per my other post I agree with fragmented / limited views > given to "real" applications of the control-port. However, personally > I don't see the point of implementing this in 'tor' itself -- existing > control-port filters are "fairly" limited code, typically in "safer > than C" languages anyway. So then you have the situation where > there's a single trusted application (the filter) conencted to the Tor > control-port. I agree with this, because it's basically required to do certain things, and for certain adversarial models. > Ultimately, it would probably be best if there was "a" robust > control-port filter that shipped as part of a Tor release. So if that > means "must implement it in C inside Tor" I guess so be it. I moderately disagree with this. It's not clear to me if a one size fit's all solution (that supports all "first class platforms" and use cases) would be easy to develop initially, and it will take continuous love and care to support everything that people want to do. By "first class" platforms in this context (since it's more client facing) I'll start off with "Whatever Tor Browser happens to be packaged for" as a first pass narrow definition. Even if this was shipped, I'm trying to keep the external dependencies required for correct sandbox functionality to a minimum, and something that's part of the bundle it downloads/auto updates doesn't feel great to me. > Maybe this would be a good target for "experiment with Rust" if > anyone's excited about writing control-port code in Rust...? I disagree with this, but since it'll never be used by the sandbox, my disagreement shouldn't stop anyone. -- Yawning Angel pgpEwYYfnw948.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: sandboxed-tor-browser-0.0.5
Hello, I just tagged sandboxed-tor-browser 0.0.5. Binaries will be built when the next Tor Browser build happens (soon). Astute readers will notice that I skipped the release announcement for 0.0.4, which was tagged yesterday. This is due to changes related to e10s being enabled in the next alpha release, that were caught after the 0.0.4 tag was created. Changes in version 0.0.5 - 2017-04-13: * Bug 21764: Use bubblewrap's `--die-with-parent` when supported. * Fix e10s Web Content crash on systems with grsec kernels. * Add `prlimit64` to the firefox system call whitelist. Changes in version 0.0.4 - 2017-04-12: * Bug 21928: Force a reinstall if an existing hardened bundle is present. * Bug 21929: Remove hardened/ASAN related code. * Bug 21927: Remove the ability to install/update the hardened bundle. * Bug 21244: Update the MAR signing key for 7.0. * Bug 21536: Remove asn's scramblesuit bridge from Tor Browser. * Fix compilation with Go 1.8. * Use Config.Clone() to clone TLS configs when available. The main major change is the eradication of support for the `hardened` series, as the Tor Browser team will be dropping it starting from the next release (#20814). The impact on `sandboxed-tor-browser` + `hardened` users is thus: * (< 0.0.4) Will not correctly transition to the alpha channel. Sorry. The bundle may or may not be rendered non-functional by the transition update, I don't have a good way to test the Tor Browser auto update infrastructure with updates that haven't been released yet. * (>= 0.0.4) When `sandboxed-tor-browser` is launched, it will detect the `hardened` bundle and force a reinstall. This will eradicate the existing bundle directory obliterating user customization, bookmarks, and downloads (unless the download directory is overridden). A warning dialog box is displayed prior to booting the user back to the installation screen. Known issues: * Sending SIGINT to `sandboxed-tor-browser` (or likely otherwise killing the process) will leave the firefox process running on ESR52 + e10s builds, *unless* bubblewrap is version 0.1.8 or newer. Exiting firefox normally works as intended. Regards, -- Yawning Angel pgpHTTlzoNyE4.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Pluggable Transports 2.0 Specification, Draft 2
On Tue, 20 Jun 2017 14:07:39 -0400 Brandon Wiley wrote: > Attached is the second draft of the Pluggable Transport 2.0 > Specification. If you have feedback on this draft, please send me > your comments by July 20. I'll raise this because it bothers me, but maybe the other people who drafted the original document don't care as much as I do. I find the attribution in the acknowledgments section entirely inadequate. I explicitly credited all previous authors when I last rewrote the specification for a reason. Regards, -- Yawning Angel pgpgdLflv6ASe.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Pluggable Transports 2.0 Specification, Draft 2
On Tue, 20 Jun 2017 21:27:35 -0700 David Fifield wrote: > Even closely affiliated projects like Orbot haven't been able to use > pluggable transports strictly according to the spec, because of the > various constraints on mobile platforms. This is basically totally and utterly wrong. https://gitweb.torproject.org/orbot.git/tree/orbotservice/src/main/java/org/torproject/android/service/TorService.java#n1691 (The extra acrobatics are for programatically generating the config to handle the binary's install path being system dependent, which is beyond the scope of the PT spec itself.) Orbot can use normal Pluggable Transports just fine, and has at various points in time used: * obfsproxy (C) * obfsclient (C++) * obfs4proxy All basically exactly as specified by the Pluggable Transports spec. The only problem in this regard has been "Python on Android was a nightmare" which precluded the deployment of obfsproxy (Python). This has little to nothing to do with the Pluggable Transport spec itself. Perhaps you mean iOS? In which case, yeah, implementing something that's based around fork + exec, on an OS that doesn't allow that, is difficult, go figure (https://github.com/mtigas/iObfs for how it's done). > The API of the 2.0 spec is based on the internal architecture of > obfs4proxy, which is de facto the main implementation of most of > Tor's pluggable transports. I don't think that's a good idea, because the API was written by me, for me, to fit my use-cases (and I'm more and more dissatisfied with Go, to the point where all my new "for fun" code is going to be in C++ or D). But if it works for them, great I guess. I didn't use the API when I was working on basket2, so this has 0 impact on anything I will be doing, or anything that I've written. > But it failed in being "pluggable" in another sense: it's not easy to > share common transport modules beyond Tor (in either direction). It > would be great if the new spec can realize that second sense of > pluggability. I still don't understand what was so hard about implementing the old API, on anything but iOS. The "2.0" spec still doesn't have any provisions for using AF_LOCAL instead of the loopback interface, go figure. It's not as if I bring it up every time this topic comes up or anything right? Regards, -- Yawning Angel pgpAUxpskG3Pw.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Names for your onions
On Sun, 25 Jun 2017 10:42:51 +0200 heddha wrote: > -BEGIN PGP MESSAGE- > > hQIMA+0TUowTVIVZAQ//aBI9TzgVTB3R7DIMVB1JL7TzSMOanIjSJkNfDNKI15kC > 4sX6k0hJdBgIcELuqc9qmUYR0AfkZ+aJz1bPLETrv1IMCa/cB8ymDZreINJhk7BI > Qk6UM3PcutB7neTH3FR7DkVtSi23AOfOmlf0kNTSRZuMMB4gZO3KfZXGRWq1+FJ3 > [snip] Why are you sending PGP encrypted e-mail to a public mailing list. -- Yawning Angel pgpqOKwG4UPWF.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PQ crypto updates
On Sat, 19 Aug 2017 04:11:16 - ban...@openmailbox.org wrote: > Boom headshot! AEZ is dead in the water post quantum: > > Paper name: Quantum Key-Recovery on full AEZ > > https://eprint.iacr.org/2017/767.pdf ... I'm not seeing your point. Even prior to that paper, AEZ wasn't thought to be quantum resistant in anyway shape or form, and providing quantum resistance wasn't part of the design goals of the primitive, or really why it was being considered at one point for use in Tor. Regards, -- Yawning Angel pgpKHB9bVRRUJ.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PQ crypto updates
On Sun, 20 Aug 2017 16:32:17 + Taylor R Campbell wrote: > > ... I'm not seeing your point. Even prior to that paper, AEZ > > wasn't thought to be quantum resistant in anyway shape or form, and > > providing quantum resistance wasn't part of the design goals of the > > primitive, or really why it was being considered at one point for > > use in Tor. > > I would expect AEZ to have essentially the same post-quantum security > as, e.g., AES or any other symmetric crypto -- square root speedup by > Grover. Yes and? My point was that quantum speedups that existed prior to the paper alone, were sufficient to render the primitive insecure in a post quantum setting. Something that's broken being more broken is non-interesting, in particular when the impetus for even considering the something (as is the case for AEZ and Tor), had nothing to do with PQ cryptography in the first place. > However, this paper is not about the conventional notion of > post-quantum security -- what is the cost, to an adversary with large > a quantum computer, of breaking ordinary users of the cryptosystem? -- > but a radically different notion of security for users who > inexplicably choose evaluate AEZ in a quantum superposition of inputs > and reveal that superposition to an adversary. Believe it or not, I did read the paper. > It is not surprising that when users abuse their crypto primitives in > an astoundingly bizarre way, to reveal quantum superpositions of > outputs, the original security claims of the classical crypto > primitives go flying out the window! I'm having trouble parsing that, perhaps my English is failing me. Ultimately none of this matters because Prop. 261 is dead in the water. Assuming people want the new cell crypto to be both fragile and to resist tagging attacks, Farfalle may be a better choice, assuming there's a Keccak-p parameterization such that it gives adequate performance. Regards, -- Yawning Angel pgp8RMxKugm9s.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PQ crypto updates
On Tue, 22 Aug 2017 20:47:06 +0200 Peter Schwabe wrote: > Yawning Angel wrote: > > Hi Yawning, hi all, > > > Ultimately none of this matters because Prop. 261 is dead in the > > water. Assuming people want the new cell crypto to be both fragile > > and to resist tagging attacks, Farfalle may be a better choice, > > assuming there's a Keccak-p parameterization such that it gives > > adequate performance. > > At what number of cycles/block on what architecture(s) would you call > the performance "adequate"? Note, I'm not hating on Farfalle, I need to look at it more, and the last time I gave serious thought to this question in a Tor context was back around the time Prop 261 was being drafted. The answer to this from my point of view is "not slow to the point where the network falls over", which I'll admit is extremely handwavy, but truth be told, I have no idea what fraction of the relays are on what micro architectures these days. Looking at the Farfalle and Kangaroo 12 papers, Kravette may be ok with AVX2 assuming I'm extrapolating correctly. But, while it's probably reasonable to assume that all the fast existing relays have AES-NI, I do not know what fraction of those predate AVX2. Part of me thinks that focusing on raw primitive performance is a bit silly (even though I'm the one that brought it up), because just about anything will likely deliver adequate performance if the cell crypto used more than one core[0]. Sorry I don't have anything more concrete. :( Regards, -- Yawning Angel [0]: And another part of me kind of wants to say "eat the overhead of a MAC per hop and use AES-GCM-SIV or something". pgpMDM6QwTKuq.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PQ crypto updates
On Sun, 17 Sep 2017 21:04:28 -0400 Nick Mathewson wrote: > I think the first step here is to instrument relays to figure out what > fraction of their cryptography is relay cell cryptography: this could > tells us what slowdown we should expect. (It _should_ be about a > third of our current cell crypto load, but surprises have certainly > been known to happen!) I'd also argue that instrumenting an high traffic client is important (if only so that there aren't unpleasant surprises later in the form of the clients hosting spacebookgopheri.onion or whatever exploding). There was some discussion about obtaining profiler output for this particular case, but AFAIK nothing really happened[0]. > The current performance we have is much faster than 13 cpb -- we're at > approximately one AES, plus one third of a SHA1. (The "one third" is > because only clients and exits do the SHA1 step.) I wonder how many of the relays have support for hardware assisted SHA. (nb: I don't have access to ARMv8, Ryzen or a sufficiently new Intel system, so I don't know how good the implementations are) Regards, -- Yawning Angel [0]: And depending on the sort of traffic the HS is serving, this may/will be dominated by public key cryptography... pgpgYWUPh3W_D.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port
On Tue, 7 Nov 2017 12:20:15 -0500 David Goulet wrote: > > This might need a couple more details; as-is ADD_ONION can take > > "NEW:BEST" (which should now return a v3 service?) or > > "NEW:ED25519-V3" for explicitly asking for a V3 key, or > > "ED25519-V3:<56 base32 chars>" for adding an already-existing v3 > > service. > > Oh good point! I failed to notice that "RSA1024:" was even > possible. Actually, it is not specified in the spec but the code > expects this: > > "RSA1024:" - Loading a pre-existing RSA1024 key. Huh? It *is* specified, both as "intentionally opaque" and as a detailed explanation of what the code actually expects, like thus: (The KeyBlob format is left intentionally opaque, however for "RSA1024" keys it is currently the Base64 encoded DER representation of a PKCS#1 RSAPrivateKey, with all newlines removed.) > Ok fun! I'll add this. Good catch! And control-spec.txt should be > updated. > > To be consistent then we could ask for a as well: > > "ED25519-V3:" > > ... which contains the ed25519 private key. If it were up to me, I'd spec the blob as opaque, and then actually use something that's sensible and consistent with the torrc and on disk files for easy interoperability like Base64 of the private key (I haven't check to see what encoding is used for on disk EdDSA keys, I assume PEM). Regards, -- Yawning Angel pgpvlIcp7_OOf.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 284: Hidden Service v3 Control Port
On Thu, 9 Nov 2017 10:13:45 -0500 David Goulet wrote: > > > Ok fun! I'll add this. Good catch! And control-spec.txt should be > > > updated. > > > > > > To be consistent then we could ask for a as well: > > > > > > "ED25519-V3:" > > > > > > ... which contains the ed25519 private key. > > > > If it were up to me, I'd spec the blob as opaque, and then actually > > use something that's sensible and consistent with the torrc and on > > disk files for easy interoperability like Base64 of the private key > > (I haven't check to see what encoding is used for on disk EdDSA > > keys, I assume PEM). > > Unfortunately not, it is custom to tor I believe with this 32 bytes > header: > > "== ed25519v1-secret: type0 ==\0\0\0" > > ... followed by the private key (64 bytes). See > crypto_write_tagged_contents_to_file(). > > Not sure we can change that within the 032 freeze. So the approach > would be to Base64 the raw bytes of the key (excluding the header). > Using tor HS key file, it would be something like: > > $ tail -c+33 hs_ed25519_secret_key | base64 -w 0 > > Considering the current situation with the encoded file on disk of > the key, I think this is kind of the simplest approach? Yeah. Just the Base64ed private key (excluding that header and things) seems reasonable. -- Yawning Angel pgpRS2OrGZWk9.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 286: Controller APIs for hibernation access on mobile
On Thu, 30 Nov 2017 07:55:49 -0500 Nick Mathewson wrote: > Filename: 286-hibernation-api.txt > Title: Controller APIs for hibernation access on mobile > Author: Nick Mathewson > Created: 30-November-2017 > Status: Open [snip] Is this a general call for feedback/questions? If so, what do you have in mind for Pluggable Transports? Currently I can count on zero fingers, the number of PTs that honor hibernation state, or that have provisions for something like a hibernation state. I assume that if this was to be solved, the hibernation code would need to tear down/respawn PTs, or someone needs to design an out of band IPC mechanism between tor and PTs that can signal hibernation status. The current approach to this problem involves toggling `DisableNetwork`. See: https://trac.torproject.org/projects/tor/ticket/13213 Regards, -- Yawning Angel pgpNsBQxLDZgm.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Prop-279 for Onion Alternative Name Representations (Re: Error-Correcting Onions with Bech32)
I commented on the ticket but I'll do it here for completeness sake: On Sun, 31 Dec 2017 10:12:53 + nullius wrote: > I also proposed changes to permit the UTF-8 characters required for > representing names in languages other than American English, and some > other technical improvements. I added status code 5 to support > plugins which can discern when a name is in a recognized format, but > is intrinsically invalid e.g. due to checksum failure; and I expanded > the description of status code 2, for plugins which do not have TLDs > but do recognize a definite syntax. This is pointless because internationalized domain names are standardized around Punycode encoding (Unicode<->ASCII), and said standard is supported by applications that support IDN queries. I am firmly against this change, and I'm not particularly thrilled by the thought of homograph attacks either. > Given appropriate prop-279 changes, I won’t need to draw a proposal. > I’ll simply write code! It's worth keeping in mind that no one to my knowledge has implemented prop 279 in the tor code itself, though there is (IIRC) a python kludge that kind of allows development. Regards, -- Yawning Angel pgpEeie9zpgdb.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Prop-279 for Onion Alternative Name Representations (Re: Error-Correcting Onions with Bech32)
On Mon, 1 Jan 2018 08:45:57 + nullius wrote: > On 2017-12-31 at 10:48:52 +0000, Yawning Angel > wrote: > >This is pointless because internationalized domain names are > >standardized around Punycode encoding (Unicode<->ASCII), and said > >standard is supported by applications that support IDN queries. > > > >I am firmly against this change, and I'm not particularly thrilled > >by the thought of homograph attacks either. > > Happy New Year, Yawning; and apologies for the delayed reply. I > thought I’d best work up some code for an object demonstration of why > I urge the importance of UTF-8 (and also embedded spaces, which I > forgot to mention explicitly). I'm aware of the use cases for IDNs. > As for Punycode vs. UTF-8: > > Homograph attacks are not “solved” by Punycode any more than they > would be fixed by base64ing all addresses. Punycode is not a > security feature; to the contrary! CVE-2013-7424, CVE-2015-8948, > CVE-2016-6261, CVE-2016-6262, CVE-2017-14062 Need I say more? Sigh, the problem is encoding format agnostic. My point was, by allowing non-ASCII characters the onus is on *someone* to solve the problem of homograph attacks (which admittedly is a bit of a tangent). I'm painfully aware that all browsers, including Tor Browser have utterly inadequate solutions here. > I know that as you say, applications which handle a string as a > “domain” will Punycode it before Tor even sees it. But my thinking > from the beginning was not in terms of DNS names. One of my > constructive criticisms of prop-279 is that it makes that assumption. It makes that assumption because it is an entirely reasonable thing to do in the context of Tor. > Dare to dream outside the quasi-DNS box about how .onion addresses > can be represented! I will quote Alec Muffet here: > a) if Onion addresses suddenly stop looking very-similar-to DNS > addresses, Tor risks returning to a world where special expertise is > necessary to build software for it, thereby harming growth/adoption The current proposal can get "very similar-to DNS addresses" IDNs by using the same encoding format that DNS uses. Regards, -- Yawning Angel pgpy2ZSIgrhQ_.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] No Control Socket when DisableNetwork 1
On Fri, 19 Jan 2018 23:22:00 + iry wrote: > According to the Tor manual: > https://www.torproject.org/docs/tor-manual-dev.html.en > > > DisableNetwork 0|1 When this option is set, we don’t listen for or > > accept any connections other than controller connections, and we > > close (and don’t reattempt) any outbound connections. Controllers > > sometimes use this option to avoid using the network until Tor is > > fully configured. (Default: 0) > > However, it seems when DisableNetwork is set to 1, > /var/run/tor/control does not exist anymore making us cannot get a > controller from socket file. > (stem.control.Controller.from_socket_file() is affected in this case: > https://stem.torproject.org/api/control.html#stem.control.Controller.fro > m_socket_file) I'm fairly certain you are doing something wrong, because I'm using a tor process that was launched with DisableNetwork set to 1 in the torrc, and toggled to 0 via the ControlPort right now to browse the web (Tested with the copy of 0.3.1.9 that is distributed with Tor Browser). https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/tree/data/torrc https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/tree/src/cmd/sandboxed-tor-browser/internal/tor/tor.go#n342 To reproduce this working, if anyone out there still uses the sandbox I wrote, and can get a working browser without using an external tor instance, ta dah, it's working. Normal Tor Browser has a similar launch process, and can even be coaxed into using AF_UNIX sockets (though it's utterly pointless to do so). nb: It can take a while for the control port to actually be available after the tor daemon is spawned. The best way I found to deal with this is via using `ControlPortWriteToFile` since the file gets created after the control port listener is created. You could also use something like inotify on Linux, but that's non-portable. Regards, -- Yawning Angel pgpbZpZhxZdpl.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] No Control Socket when DisableNetwork 1
On Sat, 20 Jan 2018 04:40:53 -0500 Roger Dingledine wrote: > My second suggestion would be to get a Tor binary and run it yourself, > not as part of a package. If it works there, then you know that your > next steps are to figure out why your package isn't working for you. With a torrc that looks like this: DataDirectory /tmp/tor ControlPort unix:/tmp/tor/control.sock SocksPort unix:/tmp/tor/socks.sock DisableNetwork 1 Running 0.3.1.9 I got from my distribution's package manager: Jan 2013:31:28.986 [notice] Opening Control listener on /tmp/tor/control.sock And a trivial test that exercises the control port works: amiens :: ~ % nc -U /tmp/tor/control.sock PROTOCOLINFO 250-PROTOCOLINFO 1 250-AUTH METHODS=NULL 250-VERSION Tor="0.3.1.9" 250 OK So digging into this further probably requires the "next steps". I still recommend a bit of a wait for tor to open the AF_UNIX socket. While it usually is nearly instantaneous on modern systems, I had intermittent problems with "the socket isn't there" related to trying too fast. Regards, -- Yawning Angel pgpQp7PSFkFus.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Pluggable transports research
On Wed, 24 Jan 2018 16:42:52 -0800 Jodi Spacek wrote: > I'm a master's student at the University of British Columbia > (Vancouver, Canada) where I'm primarily researching anonymous systems > and censorship. I would be delighted to contribute to pluggable > transports. > > Of particular interest is image and audio data stenography - is > anything is in the works for this or is it outdated? My aim is to add > this functionality while fully testing and evaluating it as part of > my thesis project. I refer to the list of idea suggestions here: > https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/ideas As far as I am aware (nb: haven't been keeping up with research in this area), no one has come up with a good solution to the issues mentioned in: Geddes, J., Schuchard, M., Hopper, N., "Cover Your ACKs: Pitfalls of Covert Channel Censorship Circumvention". https://www-users.cs.umn.edu/~hoppernj/ccs13-cya.pdf Regards, -- Yawning Angel pgpzXR9N4Leyb.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] permission denied when running snowflake-client with debian-tor user
On Mon, 11 Jun 2018 13:24:19 -0400 Arlo Breault wrote: > When you launch the client binary without providing a broker url > it tries to create a named pipe (mkfifo) to do signalling. > > https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/rendezvous.go#n161 The PT spec explicitly forbids this behavior, to avoid this problem. https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt#n188 > "TOR_PT_STATE_LOCATION" > > Specifies an absolute path to a directory where the PT is > allowed to store state that will be persisted across > invocations. The directory is not required to exist when > the PT is launched, however PT implementations SHOULD be > able to create it as required. > > PTs MUST only store files in the path provided, and MUST NOT > create or modify files elsewhere on the system. > > Example: > > TOR_PT_STATE_LOCATION=/var/lib/tor/pt_state/ Regards, -- Yawning Angel pgpmVyAiuBs22.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Sandboxed Tor Browser should be officially developed
I wasn't going to reply to this because the last time I posted to this list, I got flooded with spam, but fine. On Sat, 16 Jun 2018 18:01:04 +0200 juanjo wrote: > I do not understand why Sandboxed Tor Browser is now deprecated when > it should be the new thing in security features. It works well and > stopped already some 0days in the past and today I see that not only > is officially "*WARNING: Active development is on indefinite hiatus"* > (https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux), > the last commit is from 3 months ago, but still it works well. And > today I see that for the Firefox 60 ESR this support will be removed > (https://gitweb.torproject.org/builders/tor-browser-build.git/commit/?id=dc355882e235178d0a1889a7d96c5721faad2716). Because there was no funding for development. > Is there a hidden agenda to allow LEA/governments to exploit Tor > Browser users easily? Because I don't think maintaining the sandboxed > version is that much work and it is a great protection for many users. LOL. > So please, make Sandboxed Tor Browser an official thing. Fuck you, pay me. Regards, -- Yawning Angel pgpG9InkdTvYV.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Sandboxed Tor Browser should be officially developed
[Well, I already got my first bit of automated spam from the last post, so I might as well reply again.] On Sat, 16 Jun 2018 20:34:03 -0700 Chelsea Holland Komlo wrote: > As you pointed out, this project is no longer being actively > maintained. While someone on the Tor Browser development team can > answer more thoroughly, my understanding is that the original > maintainer moved on from working on this project. The Tor development > teams are quite small, so (like many open source projects) there are > more projects than people to support them. Essentially, yes. TLDR: I do not have the resources to dedicate to maintaining this, and in the long term the project should be replaced by a correctly re-designed Tor Browser that can sandbox itself anyway. In a more concrete terms, the "correct" thing to do would be for a non-trivial amount of work to be put into making Tor Browser support better isolation and sandboxing on it's own, rather than someone be stuck with trying to retrofit it to do things that the current design and architecture are ill suited to doing. Till something like that happens, a large amount of time, effort and code will be spent on replicating existing functionality such as the launcher, updater and configuration interface. This requires extensive changes to the existing Tor Browser design. As an example of what would be required, M. Finkel's design proposal[0] describes the steps required to change the Tor Browser architecture to something that is less nightmarish to sandbox, and provides better component isolation. As far as I am aware, there is no one working on that either. There are other fundamental unresolved questions specific to Linux sandboxing (eg: X11, D-Bus) that need to be resolved in a user-friendly manner (eg: blocking all of D-Bus a la `sandboxed-tor-browser` is unacceptable for mass adoption), but the better isolation brought on by the architectural change on it's own would be an improvement over a vanilla Tor Browser install, and it would let whoever is working on such things, focus on such things, rather than being forced to re-implement large parts of Tor Browser. Regards, -- Yawning Angel [0]: https://lists.torproject.org/pipermail/tbb-dev/2018-January/000743.html pgp4CNrRmOJJf.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] WTF-PAD and the future
On 08/02/2018 08:26 PM, Mike Perry wrote: > Should we consider recommending basket2 also? No. > Is anyone running bridges with it? Probably not, I guess :/. No one should be, it is incomplete, buggy, and needs a re-design. As a side note, I question the utility of a PT that has the AGPL3 network interaction requirement, though there is an exception for bridges distributed via BridgeDB and those shipped with Tor Browser. Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: obfs4proxy-0.0.8
Hello all, I just tagged obfs4proxy-0.0.8. This includes a few minor bugfixes in an official tagged release, and changes the primary upstream repo to one hosted on gitlab. Moving forward issues and patch merge requests should be filed on the gitlab issue tracker. While I will attempt to examine other existing locations for such things, response may (will) be delayed. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.8.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.8.tar.xz.asc Changes in version 0.0.8 - 2019-01-20: - Bug 24793: Send the correct authorization HTTP header for basic auth. - (meek_lite) Explicitly set Content-Length to zero when there is no data to send. - Added optional support for building as a Go 1.11 module. Patch by mvdan. - Change the canonical upstream repo location to gitlab. Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] RFC: Using `utls` in meek_lite.
Hello, I just pushed a change to obfs4proxy master to use `utls` to mask the ClientHello signature (currently Chrome 70.x). https://gitlab.com/yawning/obfs4/commit/4d453dab2120082b00bf6e63ab4aaeeda6b8d8a3 I understand that this is being worked on for the original meek (see: https://bugs.torproject.org/29077), but I felt inspired and it was relatively easy to get something working. Caveats: * This is only lightly tested, and may be doing something wrong or distinct. It seems to work well enough to watch videos over it. YMMV. * Azure uses HTTP 2. Not really a problem. * `utls.HelloFirefox_Auto` will fail to handshake with Azure due to an incompatible group being negotiated. * `utls.HelloChrome_Auto` ironically fails to handshake with `google.com` in a standalone test case for me. * `utls.HelloIOS_Auto` seems to work in all cases, so I may switch to that before I tag. Questions, comments, feedback appreciated, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Using `utls` in meek_lite.
(Whoops I sent my last reply directly instead of to the list. It wasn't all that important for the general public, and lists.tp.o has been flaky for me recently anyway.) On 1/21/19 5:22 PM, David Fifield wrote: > As for the TODO, my plan was was to expose a "utls" SOCKS arg to make it > configurable per bridge, and just reuse the utls Client Hello ID names: > utls=HelloChrome_Auto Done. https://gitlab.com/yawning/obfs4/commit/e4020b18f7aaafe9f4cb345630bfe18a5e44a8d2 As long as there's enough bridge line interoperability between implementations, I'm not particularly bothered if other people actually do use utls.HelloGolang or not, I'm choosing not to. As a side note: Implementing support for the missing DH groups in utls is likely trivial (assuming you don't care that it's vartime, extremely bad for actual TLS, fine for meek_lite) and would increase compatibility a good amount. That said HelloChrome_Auto and HelloIOS_Auto both work fine against the Azure bridge, so it might not be worth the effort. Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] using obfs4 to tunnel to a SOCKS proxy server
On 1/23/19 10:42 AM, Hans-Christoph Steiner wrote: > uniqx got the setup working with obfs4 connecting to a port on the > server side, like a webserver. Weŕe trying to figure out a way to make > this obfs4 setup to behave like an SSH port forward, but weŕe banging > our heads against the concept. You don't/can't, with mainline obfs4proxy. > For example, could the obfs4 server side provide a generic SOCKS proxy? There is no functionality for doing such a thing in mainline obfs4proxy. What currently will work is any one of: * Stick a proxy server of your choice behind the obfs4proxy server. From the application end it will essentially be connecting to a (for example) SOCKS5 proxy over another SOCKS5 proxy. * Connect the obfs4proxy server to a load-balancer or reverse-proxy that re-dispatches requests to the correct location based on the SNI block or `Host` header (depending on how you want to treat TLS). Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Using `utls` in meek_lite.
On 1/24/19 6:47 AM, David Fifield wrote: > // This also assumes that req.URL.Host will remain constant for the > // lifetime of the roundTripper, which is a valid assumption for > meeklite. > > Am I wrong, or is the actual restriction less strict? You can reuse the > roundTripper for different hosts--the ServerName is taken from the addr > argument to dialTLS--but only if those different hosts negotiate the > same ALPN, because the choice of http.Transport or http2.Transport is > made only once and persists for the lifetime of the roundTripper. The lock protecting `roundTripper.initConn` is only held in `dialTLS`, and the `roundTripper.transport` is not protected by a lock at all. If the target host changes and there is simultaneous access (two threads call into `roundTripper.RoundTrip` right after initialization simultaneously), there is no guarantee that the connection used to create the inner `http.RoundTripper` instance will be passed to the correct thread. Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Using `utls` in meek_lite.
On 1/24/19 7:38 AM, David Fifield wrote: > I see, you're right. It has to do with the reuse of the initConn. A proper "general" solution that solves that problem and the ALPN issue is to have a `initConn` and `http.RoundTripper` instance per destination host, and some additional locking. With more implementation cleverness this could be brought down to two `http.RoundTripper` instances, and a host -> pointer + net.Conn map, and some locking. But for something like meek_lite where the number of destination hosts is not large, the existing wrapper works fine and I don't see much reason to over engineer it. Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: obfs4proxy-0.0.9
Hello all, I just tagged obfs4proxy-0.0.9. The main features of this release are primarily related to improving the behavior of the `meek_lite` transport. Since some of the changes are major, I will expand on them separately from the brief summary given in the ChangeLog. * A forked version[0] of https://github.com/refraction-networking/utls is now used to mask the TLS signature. This results in a ClientHello that should resemble modern versions of Firefox by default. While the utls profile is named `HelloFirefox_63`, a cursory examination leads me to believe that there are no differences in FF 65. The bridge line option `utls=` will allow specifying the behavior, with (case-insenstive) string representations of the utls fingerprint names. `none` will revert to the previous behavior. Not all fingerprints were tested and or are guaranteed to work. Development was primarily done with `HelloChrome_70, `HelloFirefox_63`, and `HelloChrome_71` (experimental). While I can not vouch for the mimicry accuracy of every single profile, all of the profiles that attempt to mimic browsers should function fairly well[1], though this partially depends on the the configuration of the host doing the fronting. * meek_lite now has HPKP[2] style public key pins for all of the Microsoft CA certs that are used to sign Azure leaf certificates. This is only enabled when `utls` is being used, because I'm lazy. If Microsoft happens to change their CA certificates prior to the next release, 2024-05-20, or you are ok with being actively man-in-the- middled for some reason, adding `disableHPKP=true` to the bridge line will disable certificate pin validation. HPKP headers in HTTP responses are ignored, only the static pin list is consulted. * Due to a shift in my philosophy, portions of the new code are released under the GNU General Public License v3. Exceptions to the viral nature of the license will be considered on a case-by-case basis. Contact me for more details. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.9.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.9.tar.xz.asc Changes in version 0.0.9 - 2019-02-05: - Various meek_lite code cleanups and bug fixes. - Bug 29077: uTLS for ClientHello camouflage (meek_lite). - More fixes to HTTP Basic auth. - (meek_lite) Pin the certificate chain public keys for the default Tor Browser Azure bridge (meek_lite). Regards, -- Yawning Angel [0]: obfs4proxy WILL NOT build with the upstream version of the library, and the Firefox fingerprint will not function with Azure using the upstream version. [1]: For "I can watch Eluveitie music videos on youtube over it" definitions of "fairly well". [2]: Yes, the HPKP spec is rather dead in the wild with a lot of people giving up on it. It is my opinion that in this context having such a mechanism makes sense. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: obfs4proxy-0.0.10
Hello, I just tagged obfs4proxy-0.0.10. The primary changes are a minor fix to the meek_lite behavior when using `utls` as the TLS implementation, and a series of updates (primarily following upstream) to the `utls` library. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.10.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.10.tar.xz.asc Changes in version 0.0.10 - 2019-04-12: - Disable behavior distinctive to crypto/tls when using utls. - Bump the version of the utls fork. Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Release: obfs4proxy-0.0.10
On 5/3/19 1:48 PM, Steve Snyder wrote: > FYI, obfs4proxy no longer recognizes address:port in this form: > > ServerTransportListenAddr obfs4 [000.000.000.000]:443 > > Note the square brackets. Tor 0.3.5.8 / 0.4.0.5 still parses this > syntax, and obfs4proxy used to too. As of 0.0.10 it no longer does. Odd. None of that code, both in obfs4proxy and goptlib, has changed for years. I'll look at it when I have a moment. Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: obfs4proxy-0.0.11
Hello, I just tagged obfs4proxy-0.0.11. The primary changes are an alteration to how the obfs4 transport handles connections after the handshake failed, based on a report and assistance from Sergey Frolov. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.11.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.11.tar.xz.asc Changes in version 0.0.11 - 2019-06-21: - Update my e-mail address. - Change the obfs4 behavior for handling handshake failure to be more uniform. Thanks to Sergey Frolov for assistance. - Bump the version of the utls fork. Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
