Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
Hello all, Just a quick heads up for where this is going: * 'GET_ONIONS' was changed to be 'GETINFO' subcommands for consistency. * Code is in 'needs_review', for the 2nd round. As a proof of concept I wrote: https://github.com/Yawning/onionwrap It's a dumb quick and dirty hack that works like this: $ TOR_CONTROL_PORT=9251 ./onionwrap -port="80,8080" godoc -http=%TADDR INFO: Created onion: 5rn73le64hri2zmp.onion:80 -> 127.0.0.1:8080 [onionwrap blocks till killed] The %TADDR notation is a convenience thing for automation, there's also %TPORT, and %VPORT that get rewritten as appropriate. The onionwrap code is still incomplete, so I wouldn't recommend using it quite yet, especially since it: * Only supports creating one shot Onion Services. * Should support talking to the real server over AF_UNIX. * Needs documentation. * Requires a really experimental branch based on tor's master. * Maybe should use stem/txtorcon instead of bulb[0]. But as a proof of concept and a demonstration of the feature, I think it gets the point across. Thanks to special for inspiring me to write this. Regards, -- Yawning Angel [0]: Which is another quick and dirty hack I wrote, so I could write things like this. pgpEG1HqWaqA8.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] Are DAC_OVERRIDE & CHOWN capabilities required for ControlSocket?
On Sun, 12 Apr 2015 12:46:26 +
Nusenu wrote:
> tor will fail to startup with the current systemd service file [1]
> if your torrc makes use of the ControlSocket feature.
>
> To work around the issue one has to additionally allow the following
> capabilities:
> CAP_DAC_OVERRIDE
> CAP_CHOWN
> since the socket file is create as root and then changed to the tor
> user (chown).
>
> Is it possible to change this to not require
> CAP_DAC_OVERRIDE and CAP_CHOWN capabilities anymore?
I bet using the AF_UNIX SocksPort stuff will break as well, since the
code is common. All of the listeners are launched before switching
uid/gid and dropping privileges since it's common code.
The way to fix this would be to change retry_listener_ports and
retry_all_listeners code to additionally allow only launching service
ports (< 1024), and staging the listener launch process on config
(re)load to something that looks like:
1. Launch listeners that require elevated priviledges
(CAP_NET_BIND_SERVICE).
2. Drop priviledges and switch the uid/gid.
3. Launch the rest of the listeners, including all of the AF_UNIX
based ones (as the runtime tor user, so neither privilege is
required).
Patches accepted.
--
Yawning Angel
pgpCrZZmkj5AW.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: Orbot v15 RC3... now with x86/ATOM-power!
On Mon, 13 Apr 2015 10:14:43 -0400 Nathan Freitas wrote: > One interesting issue is that GoLang 1.4.1, which we are using to > cross-compile the Meek and Obfs4 pluggable transports to Android, only > supports targeting Android ARM for right now... I assume that will > change soon, but if not, we may have to add Obfsclient back into Orbot > for supporting x86 devices. Hmm, maybe I should add obfs4 support to obfsclient. I have code for all of the crypto I would need to add. Regards, -- Yawning Angel pgpROO5FvVuvJ.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: obfs4proxy-0.0.5
Hello all, I just tagged obfs4proxy-0.0.5, this time with improvements for both clients and servers. All users are recommended to upgrade. Special thanks to mvdan for various code cleanups. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.5.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.5.tar.xz.asc Changes in version 0.0.5 - 2015-04-15: - Go vet/fmt fixes, and misc. code cleanups. Patches by mvdan. - Changed the go.net import path to the new location (golang.org/x/net). - Added limited support for detecting if the parent process crashes. - Support for tor feature #15335 (stdin based termination notification). - Moved the leveled logging wrappers into common/log so they are usable in transport implementations. - Added a DEBUG log level. - Use a bundled SOCKS 5 server instead of goptlib's SocksListener. The big features are: - obfs4proxy now tries really hard to detect if the parent process has crashed, using various system specific hacks (and the new and improved tor assisted mechanism in #15335). This should reduce defunct obfs4proxy processes when tor happens to crash without tearing down the obfs4proxy instance. - Instead of using goptlib's SOCKS4a server, obfs4proxy now includes a SOCKS5 implementation, bringing IPv6 support to clients. Note that running IPv6 bridges has always worked (though dual stack configs are currently somewhat broken due to a tor PT configuration protocol limitation). Notes for packagers: - Like in obfs4proxy-0.0.5, one of the upstream dependency locations has changed. (code.google.com/p/go.net -> golang.org/x/net). As far as I am aware, migrating to the new package immediately is not required though, should be done sooner rather than later due to the impending deprecation of code.google.com. To temporarily continue to build against the old go.net dependency, please revert: aed4b723891db1be34eb866a03c62806b58ac148 - It is *strongly* recommended that packages be built against goptlib-0.4 or newer to work around tor bug #15240. Without this workaround, certain bridges will fail to operate correctly when the ExtORPort is enabled (the Tor side fix is in tor-0.2.6.5-rc and newer). Questions, comments, feedback appreciated, -- Yawning Angel pgpyviXcC_LtQ.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] Release: obfs4proxy-0.0.5
On Thu, 16 Apr 2015 14:03:58 -0400 (EDT) "Steve Snyder" wrote: > The v0.5 binary is substantially larger than the v0.4 binary (7204KB > vs.5408KB, both built with Go v1.4.2). > > Is this expected behavior with the newer version of obfs4proxy? Building on linux/amd64 with 1.4.2 I get: * 0.0.4 7441792 * 0.0.5 7424544 If I strip either binary I get something in the 5 MiB range, so that might be where the difference is coming from, though I would strongly discourage doing so as it is not something that is supported by the toolchain developers[0], and if a binary that has been stripped breaks, I'm not going to do anything about it beyond saying "don't do that". Regards, -- Yawning Angel [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717172 pgp6H1n7luQdM.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's "make test" fails when run on tails
On Mon, 27 Apr 2015 05:49:37 + warms0x wrote: > I am trying to execute tor's tests from git (63a90f2) on tails but the > socketpair_ersatz test keeps failing > > util/socketpair: [forking] OK > util/socketpair_ersatz: [forking] > > FAIL src/test/test_util.c:4212: assert(0 OP_EQ > tor_socketpair_fn(family, SOCK_STREAM, 0, fds)): 0 vs -111 > [socketpair_ersatz FAILED] util/max_mem: OK > > > The failure seems to be in connect(): > https://gitweb.torproject.org/tor.git/tree/src/common/compat.c#n1492 Considering that the error returned is -ECONNREFUSED, this is a reasonable assumption, yes. > armadev said on IRC that he/she could make the tests pass, so I wonder > if there might be some specific behavior on tails that prevents the > test from passing successfully. On a normal system, the tests pass fine, and it would be a bug if they didn't. Did you look at the `tor_ersatz_socketpair()` code at all? It should be obvious why this is failing on Tails. > Is there a suggested workaround? Or perhaps is it possible to easily > ignore this one test? Suggested workaround(s): * Don't use Tails, the tests are written under the assumption that they are running on a normal system that doesn't have a facist firewall preventing connections to things listening on the loop back interface. * Patch the test code to disable that test. * Maybe use torsocks with "AllowOutboundLocalhost", if the version included in Tails supports the option (I'd hope so, I added support for that feature to torsocks specifically for them). Other tests may or may not fail if you chose to go down this path. Regards, -- Yawning Angel pgpf9q_ceZn_j.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] [PATCH] Defences against the recent hidden service DoS attacks
Hello, Some minor notes... On Wed, 20 May 2015 20:03:38 +0100 George Kadianakis wrote: > == Instructions == > > Our patch is not in an official Tor release yet, so you will need to > use an unofficial git branch: > > https://trac.torproject.org/projects/tor/ticket/16052#comment:18 The configuration parameters are now in master (aka 0.2.7.1-alpha-dev). It's likely that a 0.2.6.x backport will happen, but feedback would play an instrumental part in ensuring that happens (either as a reply, or by commenting on the trac ticket). > Next, an operator who wants to deploy this experimental fix, should > first figure out how many simultaneous TCP connections a normal client > would establish. For example, an IRC server would probably not need > more than 1 simultaneous connection per user. A web server, depending > on the use, might need something between 6 to 12 (?) simultaneous > connections. Per discussion with the Tor Browser developers, I have been told that 6 is the correct number for http content, and that if there are any more streams associated with a Tor Browser user accessing a site, it would be a Tor Browser bug. Other browsers/protocols may require a higher or lower limit. A warning is logged periodically (rate limited to avoid log spam/clutter) if circuits exceed the limit, so adjusting the parameter should be relatively straight forward. Regards, -- Yawning Angel pgpEKoiBJTmPv.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] [RELEASE] Torsocks 2.1.0
On Thu, 28 May 2015 14:55:07 +0200 anonym wrote: > On 05/27/2015 09:19 PM, David Goulet wrote: > > - IsolatePID is a new option that will make torsocks set the SOCKS5 > > username and password automatically to provide isolation on Tor > > side. > > > > You can use this with the -i,--isolate command added or > > TORSOCKS_ISOLATE_PID env. variable. > > Perhaps I'm overlooking the purpose of this option, but it doesn't > look like something you can rely on to get stream isolation between > separate torsocks invocations. For instance, on a POSIX-compliant > system a PID can be reused as soon as the process using it has > terminated. This implies that, for any purpose, a PID should only be > used as a unique identifier for the duration of the process using it. > > Assuming the purpose is to provide stream isolation between torsocks > invocations, why not generate a big random numbers for the socks auth > user/password instead? 256 bits should be enough even when taking the > birthday paradox into account. > > In practice PID resuage perhaps isn't a problem for any realistic use > case, making my remarks into theoretical nitpicking, but YMMV. Ah, this is a matter of "the feature is explained in a simple manner in the abbreviated changelog". What the flag actually does is: * Username set to 'torsocks-' PID ':' unixTime * Password set to '0'. (If one day torsocks wants to add something like a signal handler to get tor browser 'new circuit' type behavior, my plan was to increment this, not currently used). While not as great as 256 bit random numbers, PID reuse within the same second is rather unlikely, at least under Linux PIDs are only recycled when the pid wraps (/proc/sys/kernel/pid_max), I assume most other Unixes follow similar behavior. The identifier was chosen such that it would be blatantly obvious in circuit listings as to which torsocks instance things belong to. There is space in the username field, so appending a hexdecimal large random number or something is certainly possible and quite trivial. Regards, -- Yawning Angel pgpAXdf3KDOMa.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] Tor Browser IsolateSOCKSAuth behavior questions.
Hello, I've been working on a dumb hack that lets me do things like this: https://imgur.com/3mah244 (Yes, that's a single Tor Browser instance, separate windows used for illustrative purposes.) It's still very raw and doesn't do everything I want it to do, so I'm not really releasing the code yet, but I have some questions regarding how Tor Browser behaves when setting the SOCKS username for isolation purposes. Ideally I want my shim to enforce isolation between the various upstreams (Tor, I2P, whatever) correctly to avoid cross-protocol probing (and to shield the I2P administration interface from eeevil websites). This appears to be straight forward if the application is Tor Browser because IsolateSOCKSAuth is always used at first glance (I will assume for now that if users decide to use things like torsocks that do not use isolation this way that they know what they are doing). My question is, what causes Tor Browser to set the SOCKS username to "--unknown--" and what the behavior should be in that case if: * The destination is a ".onion" address. * The destination is a ".i2p" address. * The destination is the I2P management console. I'm fairly sure this should be "deny". * The destination is any other address (will be dispatched over Tor if running, I don't think I will attempt to support I2P outproxies because they suck). (I think allow because things break otherwise?) For destinations that are ".onion"/".i2p", I plan to be fairly strict about making sure the SOCKS5 target and the username matches (I need to be more relaxed for sites on the regular intertubes since cross-site resources are loaded (I may make this behavior configurable...). Is this dumb? Is it common for "foo.onion" to load resources off "bar.onion"? How about in I2P land? The final form of my shim will support running with any combination of "nothing" (Tor Browser just for the "privacy benefits", probably unsafe, I may reconsider this), I2P, and Tor (Though the most useful configuration is probably I2P + Tor). Thanks in advance, -- Yawning Angel pgp4CFhRjXQuC.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 Browser IsolateSOCKSAuth behavior questions.
On Mon, 01 Jun 2015 07:43:50 + Georg Koppen wrote: > > My question is, what causes Tor Browser to set the SOCKS username to > > "--unknown--" and what the behavior should be in that case if: > > Ideally, "--unknown--" would only be used for requests originating > from privileged browser code and not belonging to a website/resource > a user requested. This would encompass things like extensions update > requests, browser update requests, blocklist checks, requests issued > by installed extensions to name just a few. In reality, however, we > are not there yet (see e.g. #13670, #15599, #1, #15569 + plus > there is at least one bug I have not filed yet). Ah ok. That explains why I saw "--unknown--" when browsing reddit with my shim running. > > * The destination is a ".onion" address. > > #15499 should give you an idea (although I am not sure whether that > ticket is still valid) I think spacebook uses subdomains, but in the .onion space, so suffix based validation (socks username, and the requested destination both end in ".onion") is sufficient here. > > * The destination is a ".i2p" address. > > I don't know. Maybe we/you should coordinate that with the I2P folks? I'm fairly sure just matching on suffix is also ok here. > > * The destination is the I2P management console. > > > >I'm fairly sure this should be "deny". > > Sounds good. This is the only way I'm messing with/using the Isolation information currently. The management console appears to work. > > * The destination is any other address (will be dispatched over > > Tor if running, I don't think I will attempt to support I2P > > outproxies because they suck). (I think allow because things break > > otherwise?) > > I am not sure, honestly. What do you have in mind? > > [snip] > > > The final form of my shim will support running with any combination > > of "nothing" (Tor Browser just for the "privacy benefits", probably > > unsafe, I may reconsider this), I2P, and Tor (Though the most useful > > configuration is probably I2P + Tor). > > Sounds useful, indeed. But I think we should make clear to users that > this will not be a proper Tor Browser replacement as you need > knowledge of the browser state to make correct assumptions on whether > to put requests into the "--unknown--" bucket or not. And I currently > don't see how your shim is able to accomplish that. Well, it's real Tor Browser, just talking to an intermediary SOCKS proxy rather than the one exposed by Tor. I currently propagate the SOCKS username/password if possible (it's not for I2P, and no analog to the isolation exists, so stuff like new identity/new circuit will be a lot of work). Behavior without I2P running (or browsing stuff I dispatch to Tor) is identical to normal Tor Browser, given certain limitations[0]. Tor Browser already does the work of placing requests in the correct bucket for me, I'm just trying to use the work Tor Browser does to prevent cross protocol probing/attacks. Maybe the right thing to do here would be to dispatch based on the isolation info and not the destination, since that doesn't give away the presense of the shim: * If the socks username ends in ".i2p" send it to I2P regardless of destination. * If the socks username ends in ".onion" send it to Tor regardless of destination. * Otherwise send it to the default upstream provider (Tor in most cases). (Note: The I2P management interface is special cased, and always will be special cased, since it's extra sensitive.) But yeah. There will be tons of warning labels. Just trying to figure out a good way to get I2P and Tor to co-exist in a single Tor Browser instance while being relatively safe[1]. Regards, -- Yawning Angel [0]: The code assumes it's talking to a system tor instance (it doesn't launch Tor for you), my control port filter is present so circuit display is broken intentionally, etc. [1]: User safety is the #1 goal here, but I know my first stab at this probably won't be perfect. I think it will still be an improvement over "install foxyproxy with a bunch of regexes" since I do have the option of peeking at the isolation. pgp_2hNyAkk5U.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] Quick logjam/Tor analysis.
On Wed, 3 Jun 2015 00:43:50 +1000 teor wrote: > (Mac) OS X Yosemite 10.10 and earlier ship with OpenSSL 0.9.8 and > 0.9.7. > > [snip] > > While it's possible to build or install OpenSSL 1.0 or 1.1 on OS X, > it's not the default. > > How does this affect Tor and/or Tor Browser on OS X? Tor Browser builds/includes it's own copy of OpenSSL, so there is no impact there. As of a little while ago on master, tor requires OpenSSL 1.0.0 with ECDH support at build time. AFAIK this breaks the build with OSX, FreeBSD 9.x, and certain (Old) versions of Centos/RHEL when compiling against the vendor's OpenSSL. The only resolution is "Too bad, so sad, install a modern OpenSSL". See #16034 and #16040 for details. -- Yawning Angel pgp01DoAVjA4U.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] Dumb or-ctl-filter tricks (Was: [tor-talk] SOCKS proxy to sit between user and Tor?)
Hello, I just pushed a fairly large update to or-ctl-filter, that lets you do lots of interesting things, most of them probably unsafe. In particular or-ctl-filter now ships with a SOCKS5 client/server implementation and a stub control port implementation. A picture is worth a thousand words: https://raw.github.com/Yawning/or-ctl-filter/screenshots/or-ctl-filter-tor-i2p.png What it does: * Filters the control port exposed to Tor Browser for things that (IMO) the browser has no business knowing just in terms of attack surface. In particular this intentionally breaks the circuit display feature as part of 4.5.x. * Allows easy integration of Tor Browser with a system tor service (NB: I run a system tor service with the Tor Browser circuit lifespan patch, if you do not, you will get behavior that is different from other users. You have been warned.) * Supports transparently redirecting ".i2p" requests to an I2P instance. Tor does not need to be running for this. * Enforces isolation to attempt to guard the local I2P web server and management interface from cross protocol trickery, evil Javascript and whatnot. * Supports running without Tor or I2P at all, essentially changing Tor Browser into Firefox with a bunch of patches. Limitations: * NEWNYM does not affect I2P tunnels. * "New Tor Circuit For This Site" does not affect I2P tunnels either. * Only cookie authentication is supported because I'm lazy, and it is the superior authentication method. * Launching Tor/I2P is not or-ctl-filter's problem and will never be part of the feature set. I have systemd for that. Warning(s): * Very alpha. It is entirely possible that I screwed up enforcing isolation. You can hard disable access to locally hosted i2p services like the management console in the config file. It is still probably 3 million times better than using privoxy/random sketch addons to do something like this because I actually do look at circuit isolation from Tor Browser and propagate it to Tor (or enforce it as best as I can otherwise). * If you enable logging, it will happily splatter destinations, authentication credentials, and everything else to the log, because it is a debugging feature, so don't. * If you enable the option named "UnsafeAllowDirect" and disable Tor, it will happily connect directly to the internet, destroying your anonymity. * Untested on Windows. Should work, don't care if it doesn't. Patches will sit in my INBOX forever; ignored, and unloved, just like the operating system they target. The same goes for OSX.[0] Code: https://github.com/Yawning/or-ctl-filter/tree/master -- Yawning Angel [0]: Honestly, I'll merge trivial things, but I won't bust out my windows box to test/debug this, and I don't have an OSX box. pgp4kvHS2QXRf.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] How bad is not having 'enable-ec_nistp_64_gcc_128' really? (OpenBSD)
On Mon, 22 Jun 2015 18:36:19 +0200 nusenu wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi, > > since enable-ec_nistp_64_gcc_128 is > disabled by default on OpenBSD due to compiler bugs [1] > I wanted to ask how bad is it (in relay context) to ignore the usual > tor log entry: > > > We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, > > but with a version of OpenSSL that apparently lacks accelerated > > support for the NIST P-224 and P-256 groups. Building openssl with > > such support (using the enable-ec_nistp_64_gcc_128 option when > > configuring it) would make ECDH much faster. > > Tor's changelog "highly recommends" it [2]. > > Can this be "translated" to something like > > "the relay's bandwidth usage and usefulness will be reduced" > > "latency will be higher" > > "security will be degraded due to fallback to DH-1024" > ? It's exactly what it says on the tin. Your relay will burn more CPU doing ECDHE as part of TLS, but it will have no security impact unless there is a bug in the non-optimized ECDH code. "TLS connections will take longer to be established, because the key exchange takes longer, but once connected there is no further impact". -- Yawning Angel pgpcUut7LjOJp.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] How bad is not having 'enable-ec_nistp_64_gcc_128' really? (OpenBSD)
On Mon, 22 Jun 2015 15:55:59 -0400 "l.m" wrote: > Last I heard NIST groups are rubbish. You're better off without them > for security. Am I wrong? DHE is worse (logjam being a recent high profile example), and is far slower. It's important to remember that TLS being broken while far from ideal is insufficient for adversaries since they will need a Curve25519 break as well to actually get plaintext. It is worth noting that as of 0.2.7.x, tor will *require* OpenSSL with ECDH support, and one of P-244 or P-256. There is an IETF draft circulating for standardizing other curves (Ed25519, Ed448) which hopefully will see uptake in the longer run, but ECDHE with the NIST curves is the current "least bad" choice. Regards, -- Yawning Angel pgptam3OkluOA.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] Performance testing using chutney (was Re: Env variables for chutney)
On Sun, 05 Jul 2015 10:20:50 -0700 Cory Pruce wrote: > Dude, thanks a bunch for you help. I'm really excited to start :D I'm > going to read through the initial design and the code to see what > functions/structures/constants/etc. need to be changed. Let me know > when you release #14175 and I'll be happy to be the test guinea pig > =-) Maybe look at these for a start. It's something that's on my TODO list, but I wouldn't complain if someone else happens to do it before I do, and it would help HS scalability considerably[0]. https://trac.torproject.org/projects/tor/ticket/13737 https://trac.torproject.org/projects/tor/ticket/13738 (If you happen to be more interested in making non-HS use cases faster, then look elsewhere. :P) Regards, -- Yawning Angel [0]: I do have a branch that makes circuit build crypto substantially faster that I've been poking at so the situation will be better in 0.2.7.x, but it's not via threading... pgpGJcZNgu2hr.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] BOINC-based Tor wrapper
On Wed, 22 Jul 2015 01:06:41 +1000 teor wrote: > > > On 20 Jul 2015, at 11:11 , Serg wrote: > > > >> How do you plan to map ports on NAT devices? > > > > If it can't be done automatically using UPnP, This must be done > > manually. No alternative cases. > > Our experience is that most routers' UPnP / NAT-PMP implementations > don't work well with (our) automated tools. So this would have to be > done manually, significantly reducing the pool of available > volunteers. Just chiming in here. This may well work for a good number of users, but the support overhead for when it fails is utterly gigantic because certain brands of consumer routers have extremely poor UPnP/NAT-PMP implementations. The usual symptom of a poor implementation is "the router crashes" but certain other behaviors have been documented in the past by people trying to use UPnP in ways that are spec compliant such as "the router crashes and requires a NVRAM reset", "random port mappings get obliterated", "the UPnP/NAT-PMP stack on the router crashes" etc. A bigger issue is that a lot of consumer grade routers have a very limited amount of NAT session tracking space (in terms of absolute number of connections), which makes machines behind such devices extremely poor Tor relays (and even worse Guards)[0]. -- Yawning Angel [0]: In an ideal world every relay should be able to handle having a TCP connection open to any other relay simultaneously, plus connections from clients if they are guards, since relays do not get to choose their peers. Relays that fail to meet this criteria are (IMO) harmful to the health of the network. pgp1htVb98QWE.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] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
On Tue, 21 Jul 2015 11:38:00 -0400 Nick Mathewson wrote: > Yawning's mail below reminds me: I am considering removing the C > implementation of tor-fw-helper from the tor distribution, and > recommending Yawning's pure-Go implementation instead. But before I > do this, I'd like to get some sense of whether folks are shipping > tor-fw-helper today, or using it in practice. On this note, should I move my tor-fw-helper rewrite from github to git.torproject.org? It hasn't had commits for a while, but it's not the kind of code that really rots (and it is complete/portable). Regards, -- Yawning Angel pgptxSAf8ktjE.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] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
On Thu, 23 Jul 2015 16:54:33 + Jacob Appelbaum wrote: > On 7/21/15, Nick Mathewson wrote: > > Yawning's mail below reminds me: I am considering removing the C > > implementation of tor-fw-helper from the tor distribution, and > > recommending Yawning's pure-Go implementation instead. But before > > I do this, I'd like to get some sense of whether folks are shipping > > tor-fw-helper today, or using it in practice. > > Does the pure-Go implementation support NAT-PMP or just UPnP? It supports both, though NAT-PMP is limited to Linux, Windows, and *BSD (including Darwin), due to the need to query the routing table to obtain the IP address of the default gateway. It's easy-ish make the new code's NAT-PMP support other platforms (implement one function), but since the existing support covers what's needed I haven't gone and hunted down more obscure things. > I still use tor-fw-helper when I hand compile Tor on obscure systems. > Generally this means a Novena board when I need a newer version of Tor > than is already packaged. > > Also - does this mean that after many many years... that this new > version of tor-fw-helper be enabled by default at build time? Pretty > please? :-) Unlikely, AFAIK the general plan was to have it as a separate package. -- Yawning Angel pgplUoRJtq2TV.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] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
On Thu, 23 Jul 2015 18:26:33 + Jacob Appelbaum wrote: > >> Also - does this mean that after many many years... that this new > >> version of tor-fw-helper be enabled by default at build time? > >> Pretty please? :-) > > > > Unlikely, AFAIK the general plan was to have it as a separate > > package. > > > > That is really a major bummer if so - we should be shipping this code > and enabling it by default. If a user wants to run a relay, they > should only have to express that intent with a single button. The problem with this (and why we're not shipping it in Tor Browser, even if it would make flashproxy actually usable/useful to a large number of users) is because there is no one that is willing/able to deal with every single instance of: * "My router crashed" * "My router crashed and I had to factory reset it" * "Why do I need to open a UDP port on my computer's firewall for uPnP/NAT-PMP to work, and how do I do that?" * "Random unrelated port mappings got blown away" * "My router's NAT TCP session table filled up" * "My ISP is complaining that I'm on some random asshole's blacklist because they include every single Tor Relay" * "Sites that used to work no longer work because some random asshole's blacklist includes every single Tor Relay" * etc, etc, etc, etc And I certainly can't deal with "my router has a strange idea of what the uPnP spec actually says, and it fails to port forward" (unless they have/know how to use wireshark). I'm as unhappy at the general situation surrounding the codebase as anyone else, and if I thought deploying it would be a good idea, I'd be strongly pushing for it, since I think the new code I wrote will work for a lot of people. But we have a gigantic userbase, and playing "consumer router support technician" for all of the ones that ship with broken uPnP/NAT-PMP implementations does not fill me with warm fuzzy feelings. Regards, -- Yawning Angel pgpoHkfbE2rHa.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] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
On Thu, 23 Jul 2015 19:18:34 + Jacob Appelbaum wrote: > Why are we avoiding allowing users to make this choice because of the > above reasons? If a user wants to run a relay or a bridge, we should > make it easy. We don't answer the above questions when it is hard - > are we really off the hook there? It just seems ridiculous. Do users know that their router's implementation of NAT-PMP/uPnP is shit? It's more a uPnP issue, but I found bugs in at least one NAT-PMP implementation when writing the code (fixed in upstream, don't know how many people are running the newer code). Utterly horrific behavior especially in uPnP implementations is a well known and well documented problem. Eg: * http://www.upnp-hacks.org/annoyances.html * https://tools.ietf.org/html/rfc6886 (Sec. 9.5) * https://community.rapid7.com/servlet/JiveServlet/download/2150-1-16596/SecurityFlawsUPnP.pdf While the situation has probably improved over the years, having users use a feature on their router that should be off until the router firmware is known not to be horrible (See the report on RCE vulnerabilities) doesn't feel great to me. How many average users keep their router firmware up to date? [snippity] > > But we have a gigantic userbase, and playing "consumer router > > support technician" for all of the ones that ship with broken > > uPnP/NAT-PMP implementations does not fill me with warm fuzzy > > feelings. > > I think this is a weird analysis. How many of those people even try to > be a relay or a bridge? Do we have numbers on that? Does the support > team object or are you objecting on their behalf? It just seems too > hand wavy for too many years to punt on dealing with NAT properly. I briefly spoke to Lunar about this at Valencia when I was asked why, given a rewrite exists that it's not being shipped with flashproxy. I was less focused on the relay side of things and more on flashproxy specific issues, which I'm still convinced will be Not Fun to support. If they think they can/want to support this sort of thing, then they can say so, and I'll do the integration work on the Tor Browser side, and write the required flashproxy changes to make it work for more than ~2 hours when using NAT-PMP. > I admit, I am pretty frustrated that we implemented it, shipped the > code for years and I'm probably the only person who really used it > because of what feels like fear, uncertainty and doubt. Some of the > concerns makes sense but it mostly just strikes me as a farce at this > point. We can always make it harder later but we haven't really tried > to make it easier, ever. Part of this sounds like a documentation issue. > Any user that can compile a Go program can probably just do the NAT > punching on their own anyway... $ go get github.com/yawning/tor-fw-helper $ $GOPATH/bin/tor-fw-helper There are no dependencies beyond what is provided by the Go compiler, so it's the easiest thing to package ever. If someone wants to package binaries for it, I don't care. I'll even add a manpage for it once the upstream git repo is move to git.torproject.org, tag/sign releases, and keep tarballs around if that's what people want. However, if it breaks, my response will be "patches accepted" for all but the most trivial bugs since it's not realistic for me to own every single router ever made. And more importantly, compromised routers due to shitty/out of date uPnP implementations are Not My Problem. Regards, -- Yawning Angel pgpphKdsowO7U.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] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
On Thu, 23 Jul 2015 12:50:29 -0700 David Stainton wrote: > >> But we have a gigantic userbase, and playing "consumer router > >> support technician" for all of the ones that ship with broken > >> uPnP/NAT-PMP implementations does not fill me with warm fuzzy > >> feelings. > > > > I think this is a weird analysis. How many of those people even try > > to be a relay or a bridge? Do we have numbers on that? Does the > > support team object or are you objecting on their behalf? It just > > seems too hand wavy for too many years to punt on dealing with NAT > > properly. > > If I understand things correctly the uPnP/NAT-PMP is in fact not the > proper way to solve this problem because of the reasons Yawning > mentioned. IPFS (interplanetary filesystem) currently solves this > problem via some complicated protocol with the selection of a > rendezvous server... similar to Tor hidden services. Clearly this is > the correct way to solve the NAT problem. Am I wrong about this? NAT-PMP (aka PCP) is less awful than uPnP is, may actually be ok (as long as you don't try to remove port mappings due to a bug in older miniupnpd), but is primarily an Apple-ism limiting it's usefulness. OTOH, the far more widely supported/deployed uPnP, on consumer routers at least, should be disabled and treated with extreme suspicion till proven otherwise. Regards, -- Yawning Angel pgpyEKzNPX65d.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] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
On Thu, 23 Jul 2015 23:46:26 + Jacob Appelbaum wrote: [snip] > > Do users know that their router's implementation of NAT-PMP/uPnP is > > shit? > > Who knows better than the user? And who better than the user to take > an action and to learn it? At this point with all the resources available, I will guess that if the user needs something like tor-fw-helper, they probably have no idea what router firmware is. Eg: https://portforward.com [snip] > I don't even understand why this is part of the discussion? Why is > this our problem? Or put differently - sure, people don't patch their > stuff - are we really making the problem worse? Wouldn't it make them > more likely to interact with their router and perhaps apply patches to > it? Dunno. Considering there was a bunch of fuss in the media about "you should disable UPnP to increase security" a while ago, we could be making things worse. Eg: http://www.forbes.com/sites/andygreenberg/2013/01/29/disable-a-protocol-called-upnp-on-your-router-now-to-avoid-a-serious-set-of-security-bugs/ And again, no. If they need tor-fw-helper, I doubt they know what firmware is in the first place. [snip] > > If they think they can/want to support this sort of thing, then they > > can say so, and I'll do the integration work on the Tor Browser > > side, and write the required flashproxy changes to make it work for > > more than ~2 hours when using NAT-PMP. > > > > That seems awesome - I guess I'd ask - does it need to be on by > default? I'm not actually advocating for using it by default - I am > advocating for shipping some NAT punching tool that can be used at > all. tor-fw-helper never shipped as compiled code to end users which I > found to be extremely demotivating. For flashproxy to work, yes, it would need to be on since flashproxy currently requires NAT traversal. WebRTC will also fix this, but a version of flashproxy that uses WebRTC does not exist yet. [snip] > >> Any user that can compile a Go program can probably just do the NAT > >> punching on their own anyway... > > > > $ go get github.com/yawning/tor-fw-helper > > $ $GOPATH/bin/tor-fw-helper > > > > I can't tell if you're agreeing with me here or if you are suggesting > that people who have trouble configuring a program to use to a SOCKS > proxy will be able to build and use a commandline tool. I assure you - > nearly anyone who can use `go get` will be able to configure their NAT > manually. For everyone else, we need some usable automation. A bit of both. In my opinion, people that can't setup port forwarding by hand shouldn't be running a Tor relay in the first place. > > There are no dependencies beyond what is provided by the Go > > compiler, so it's the easiest thing to package ever. If someone > > wants to package binaries for it, I don't care. I'll even add a > > manpage for it once the upstream git repo is move to > > git.torproject.org, tag/sign releases, and keep tarballs around if > > that's what people want. > > Seems reasonable. I had hoped it would be part of the default Tor > build process - so anyone with a Tor can be a NAT punching relay or > bridge or pluggable transport. We were very close to this with > tor-fw-helper but never flipped the switch. It would be pretty sad if > we went even further away from this much needed ability. I guess that > is the direction of travel though. :( > > > > > However, if it breaks, my response will be "patches accepted" for > > all but the most trivial bugs since it's not realistic for me to > > own every single router ever made. And more importantly, > > compromised routers due to shitty/out of date uPnP implementations > > are Not My Problem. > > If we shipped it, I'd say we're still improving on nearly every front > over the C tor-fw-helper situation. If that's what people want to do. They should let me know so I sign/tag releases and add the documentation. Unless someone from the support people tells me they're ok with dealing with supporting users when this fails, I won't do the flashproxy work, but someone else is more than welcome to do it. Regards, -- Yawning Angel pgplTso9cEf2L.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] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
the uPnP table starts to get full, which is presumably not a concern for the bridge/relay use case (Since like aliens from the planet Zeist, "There can be only one"). * If this is deployed to users, they should know that historically a lot of routers have had hilariously broken/insecure uPnP implementations (Documentation issue). * As far as support/bugfixes/maintenance from my end, there's a limit to what I can do for quirky/broken routers, and in a lot of cases this will end up as "patches accepted". I hope this clarifies things. Regards, -- Yawning Angel pgpIdmA2SmBnG.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] curve25519_donna vs. crypto_scalarmult_curve25519?
On Tue, 4 Aug 2015 17:55:51 -0400 (EDT) "Steve Snyder" wrote: > Given a contemporary release of Tor with a contemporary version of > OpenSSL, under what circumstances is the intrinsic curve25519_donna() > preferred over the libsodium/NaCl crypto_scalarmult_curve25519(), or > vice versa? A quick peek at the libsodium code reveals that it uses curve25519-donna (64 bit targets), and ref10 (32 bit targets?). Standard Tor uses curve25519-donna for both. I *think* donna's 32 bit code should out perform ref10, so libsodium is pointless. djb's NaCl might have assembly versions that are faster, but the difference doesn't look massive. http://bench.cr.yp.to/impl-scalarmult/curve25519.html > Does it come down to 32-bit vs. 64-bit? Or CPU instruction sets > detected at build time? > > Or has libsodium/NaCl been deprecated altogether and just not removed > from the configure script? I think mostly this, at this point. Deprecating it might make sense, since libsodium is basically never going to outperform donna, and it's not practical to use libsodium/NaCl for Ed25519 due to Tor specific changes that would be required. > I'm trying to determine if installation of libsodium in a Tor build > environment will yield a "better" Tor binary. If libsodium, then no. If djb's NaCl then *maybe*, but the difference in practice will probably be fairly negligible (NB: discussing 64 bit platforms. 32 bit platform performance is somewhat non-interesting to me, so I haven't measured things in depth). I'm planning on revisiting this issue at some point, but last I looked into it, using an assembly optimized Curve25519 implementation was potentially a 7-10% gain (but is neither from libsodium nor djb NaCl). https://trac.torproject.org/projects/tor/ticket/8897 -- Yawning Angel ps: 0.2.7.2-alpha and later already does ntor ~25% faster, due to a faster basepoint multiply being used in the key generation step. pgpbYaJ7YxFMb.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] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
Just to touch base on this, and to give a rough status of where things are. The tor codebase no longer includes the C tor-fw-helper as of: d2cb92332009567ae778b3570e8fd3420c207446 Closes https://trac.torproject.org/projects/tor/ticket/13338 The new (Go based code) now lives at: https://gitweb.torproject.org/tor-fw-helper.git/ I changed the import paths and what not so that: $ go get git.torproject.org/tor-fw-helper.git/tor-fw-helper $ $GOPATH/bin/tor-fw-helper Does the right thing, at least on my box. In theory as long as the toolchain is properly setup, this will work on Linux, *BSD, OSX, and Windows, though it has been a while since I tested non-Linux (no major functional changes were made so I expect it to still work). If people don't like Go for some reason, they can write a functional replacement in $languageOfChoice, though unless they use library code, it is Not Very Fun. On Tue, 28 Jul 2015 01:18:07 + Jacob Appelbaum wrote: > > * I still intend to move the new code from github.com to git.tp.o, > > and am willing to provide things like signed release tags, and > > tarballs of releases if that will make packaging it easier, but I > > won't be the one making packages (unless I happen to get bored > > enough to put it in AUR). > > > > That sounds fine by me - I think that if that other stuff is done - > it is easy to package it. I don't quite have time to do the man page at the moment, but once that is done, I'll tag, and put signed tarballs up somewhere sensible. Since there are no dependencies required beyond a new-ish Go compiler, this should be utterly trivial to package. I'll try to do this sooner rather than later, but no promises since IRL stuff is on fire for the remainder of the week. Regards, -- Yawning Angel pgpwTfSMGIG6Q.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] "Seeing through Network-Protocol Obfuscation"
NB: quickly responding before I go to bed. On Wed, 19 Aug 2015 14:13:03 -0400 Philipp Winter wrote: > <https://kpdyer.com/publications/ccs2015-measurement.pdf> > > They claim that they are able to detect obfs3, obfs4, FTE, and meek > using entropy analysis and machine learning. Not surprised for obfs3/4 since they're mounting an entropy attack which is explicitly outside of the stated threat model for both protocols. The FTE semantic attack they presented isn't the easiest one I know of (the GET request as defined by the regex is pathologically malformed). Haven't looked at the meek portion of the paper. > I wonder if their dataset allows for such a conclusion. They use a > (admittedly, large) set of flow traces gathered at a college campus. > One of the traces is from 2010. The Internet was a different place > back then. I would also expect college traces to be very different > from country-level traces. For example, the latter should contain > significantly more file sharing, and other traffic that is considered > inappropriate in a college setting. Many countries also have popular > web sites and applications that might be completely missing in their > data sets. Dunno. Others probably have a better idea on what average internet traffic looks like these days. > Considering the rate difference between normal and obfuscated traffic, > the false positive rate in the analysis is significant. Trained > classifiers also seem to do badly when classifying traces they weren't > trained for. The authors suggest active probing to reduce false > positives, but don't mention that this doesn't work against obfs4 and > meek. Coming up with something better than obfs4/meek would be nice. At this point I'm viewing obfs4 as more of a minimum standard than anything else. It's worth noting that Dust2 (mostly done but not yet deployed) can reduce payload entropy to match a target distribution, but will have issues with protocol whitelist based DPI. Regards, -- Yawning Angel pgpFY2al5Ysy5.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] Hash Visualizations to Protect Against Onion Phishing
On Thu, 20 Aug 2015 17:02:24 +0300 George Kadianakis wrote: > Jacek Wielemborek writes: > > > W dniu 20.08.2015 o 15:49, George Kadianakis pisze: > >> Some real UX research needs to be done here, before we decide > >> something terrible. > > > > Just curious, has anybody seen any cognitive studies on the SSH > > randomart visualisation? I always found them impossible to remember. > > Perhaps adding a bit more color could help... > > > > Hm. Indeed. > > I can remember the general shape and edges of my SSH server's key, > but not any details. > > I doubt I would remember the randomart of like 10 onion websites, > especially if I didn't visit them regularly. But maybe I would > remember the randomart of my webmail better than my SSH server's. What would be useful here is the number of onion addresses an average user visits. If it's small, something like this would probably be sufficient: 0. Browser generates/stores a long term salt. 1. On onion access, calculate SHAKE(salt | onion address) map that to a poker hand (5 card draw). P(52,5) = 311,875,200 C(52,5) = 2,598,960 2. Goto 1. Benefits: 0. Collisions between addresses are unlikely and don't weaken the scheme (though it will be confusing to the user that does encounter the situation). 1. Brute-forcing is mitigated via the per-client salt. 2. Incomplete recall still useful (User needs to forget all of order, suite, and card value). 3. Easy to memorize. 4. Easy to extend up to a point. 5. Can probably display it with fonts present on the system (or the one that will be bundled). Cons: 0. Having to propagate the salt value if the user uses multiple boxes is somewhat annoying. 1. May get confusing to remember lots and lots of onions->hand mappings. 2. No "canonical" visualization that can be shared across users. 3. Something Yawning randomly made up before going to bed. Regards and good night, -- Yawning Angel pgpm_xywJhZs5.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] Hash Visualizations to Protect Against Onion Phishing
On Thu, 20 Aug 2015 11:00:51 -0400 Ian Goldberg wrote: > On Thu, Aug 20, 2015 at 02:41:51PM +0000, Yawning Angel wrote: > > What would be useful here is the number of onion addresses an > > average user visits. If it's small, something like this would > > probably be sufficient: > > > > 0. Browser generates/stores a long term salt. > > > > 1. On onion access, calculate SHAKE(salt | onion address) map that > > to a poker hand (5 card draw). > > > > P(52,5) = 311,875,200 > > C(52,5) = 2,598,960 > > > > 2. Goto 1. > > The per-browser salt is a good way to prevent similar-hash attacks, > but of course will go astray if the user reinstalls her Tor Browser > or has multiple devices. Yeah, that's a downside. I suspect it can be fairly short but I don't have a solid basis for that suspicion, and it also provides the property of being able to semi-arbitrarily increase the brute forcing difficulty at a latter date. > I'd caution about the poker hand, though. One year when I taught > first-year undergraduate CS, we included an assignment that had to do > with decks of cards and card games. A surprising number of people had > never seen decks of cards before, and were unfamiliar with the > concept. I did not observe whether the (un)familiarity was correlated > with what part of the world they came from. It was a hypothetical example. If we're willing to go with the visual equivalent of key poems (which is what my suggestion roughly corresponds to) with a per-client secret to prevent brute forcing, then there's no reason why we couldn't let the user choose a visual representation they're most comfortable with. (My initial example was going to use mahjong tiles. >.>) > Perhaps a notification "You've never visited this site before" that > pushes down from the top like some other notifications might go a long > way? People would likely complain about storing "did access foo.onion in the past" type information to disk. I could argue for/against "well, use a per-client keyed bloom filter, false positive rate", but depending on the adversary model, people will probably (rightfully) be uneasy at the thought of persisting even that. The moment people are willing to store "I accessed this onion in the past", I'm inclined to think "this is functionally equivalent to the user bookmarking said onion". Regards, -- Yawning Angel pgpukHV5j3ArQ.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] Hash Visualizations to Protect Against Onion Phishing
On Fri, 21 Aug 2015 04:39:14 +1000 teor wrote: [snip] > Visual schemes are only helpful to users who have the appropriate > level of visual ability or processing: > * as has already been mentioned, colouring schemes are not as useful > to the colourblind; > * facial recognition schemes are useless to the face-blind (including > many autistic people); and any visual scheme would need to have a > text alternative for screen readers or other tools used by the > visually impaired. [snip] > If we choose a list of English words, is that going to cause > recognition issues for people who are non-native English speakers, or > whose native script is a non-Latin script? (We could test this out.) As much as all of these are important issues, if we search for a solution that works for absolutely everyone, then we will never implement anything, because IMO no such thing exists. I sort of have mixed feelings about this in general, but since enough people seem to think it's a good idea, what appears to be the obvious way forward is: * Come up with a well defined interface for "take an opaque blob, present it to the user". * Implement the underlying firefox glue. * Test deploy a few user select-able representation modules. Without doing so, trying to hash out any sorts of design(s) will likely end badly, and going with "write the framework that lets us do UX testing" will let us get a better handle on the problem[0]. Regards, -- Yawning Angel [0]: And who knows, an enterprising student may discover that the "One Universal Onion Representation For Purposes of Quick Verification" is "Onions As Interpretive Modern Dance, Music, and Tactile Sensations Conveyed Via A Force Feedback Joystick", and write the appropriate plugin. Personally, I'm done with this subject and I'll stick to using bookmarks. pgpB6q_HC8tpD.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] Number of directory connections
On Fri, 21 Aug 2015 12:45:05 -0400 tordev...@safe-mail.net wrote: > I can't think of a good reason for that behavior. Is there a valid > security issue using an old consensus to fetch the current one from > the entry guard? Your entry guard being rejected as malicious by the DirAuths in the intervening time period. Regards, -- Yawning Angel pgpkGFnUn8J6o.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] "Seeing through Network-Protocol Obfuscation"
On Fri, 21 Aug 2015 17:51:20 -0700
Kevin P Dyer wrote:
> On Wed, Aug 19, 2015 at 11:58 AM, Yawning Angel
> wrote:
>
> > [snip]
> >
> > The FTE semantic attack they presented isn't the easiest one I know
> > of (the GET request as defined by the regex is pathologically
> > malformed).
> >
>
> Very interesting! This is news to me. I'm assuming I did something
> silly. (Even though I tested it against bro, wireshark, etc.)
Huh. I brought it up in conversation with a few people and was under
the impression it was passed on. I probably should have e-mailed you
about it or something.
> How is it pathologically malformed?
"manual-http-request": {
"regex": "^GET\\ \\/([a-zA-Z0-9\\.\\/]*) HTTP/1\\.1\\r\\n\\r\\n$"
},
No "Host" header. All complaint requests MUST include one per RFC
2616, and all compliant servers MUST respond with a 400 if it is
missing.
Since requests of that sort should invoke the error path on RFC
compliant servers it's a really good distinguisher since legitimate
clients will not do such a thing. Existing realistic adversaries
already have "identify 'suspicious behavior', call back to confirm"
style filtering in production, so false positive rate can be reduce to
0 if needed.
Regards,
--
Yawning Angel
pgpt9GOPQh8Cr.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] "Seeing through Network-Protocol Obfuscation"
On Fri, 21 Aug 2015 17:46:39 -0700 Kevin P Dyer wrote: > > The authors suggest active probing to reduce false > > > positives, but don't mention that this doesn't work against obfs4 > > and > > > meek. > > I don't want to get too off track here, but do obfs4 and meek really > resist against active probing from motivated countries? Don't we > still have the unsolved bridge/key distribution problem? meek does because the entry point into the Tor network is a well known high traffic CDN platform. So an adversary can see that there is a meek instance running on a given CDN (since it's not a secret), along with content that people want to see, so distinguishing between normal traffic/meek traffic requires a TLS break or statistical attacks. I personally hold distribution to be orthogonal to circumvention protocol design in the context of obfs4 (scramblesuit, fte, and other bridge based circumvention protocols), because if someone breaks the bridge distribution mechanism, the protocol is irrelevant since the attackers win by virtue of having the IP address/Port of the obfuscated server[0]. Assuming all the adversary sees is the obfs4/scramblesuit stream, then both are active probing resistant, because it requires compromising a separate system to be able to generate a valid handshake for probing. Active probing attacks should be able to defeat a scenario like: "I setup a unlisted bridge, firewall off the ORPort and GPG e-mail/OTR/Pond a series of bridge lines to a collaborator in China." The adversary gets to see the IP address/Port of the obfuscated server, and can send traffic as they see fit. Note: There's a few other things an adversary can do under the assumption that whatever is speaking obfs4 is probably a Tor client/bridge pair. But those are attacks against either the Tor network, or limitations of the tor implementation itself[1]. Regards, -- Yawning Angel [0]: Distribution still is an important problem that needs to be solved, and maybe linking it closer to the protocol design is something that is required. Open research questions are open. [1]: Likewise this stuff is important and should be/will be fixed, but they are Tor issues and not "obfs4/fte/whatever" issues. pgpqGWuRU9dnE.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] "Seeing through Network-Protocol Obfuscation"
On Sat, 22 Aug 2015 14:40:08 -0700 Kevin P Dyer wrote: > Ah, gotcha. It's not RFC compliant. RFC2616 was created in 1999 and > there are tons of HTTP-like implementations since then that, > ostensibly, don't need to follow it. (e.g., an HTTP-like > client/server that only talk to each other.) A network monitor must > deal with these cases too, and they'll broadcast HTTP/1.1 in their > headers. > > This [1] paper is a bit dated (2007) but my intuition is that > real-world implementations have drifted even further from the RFC > over the last 8 years. I swear there's a more recent paper on this > topic, but I couldn't find it... I'd be surprised if there were lots of clients that advertise HTTP/1.1 that don't include a Host header, since clients that are broken in that manner will not be able to talk to apache/ngnix/tomcat/etc[0]. Then again, fteproxy is an example of such a thing, so I may be rather sad at the results of an actual survey. > > Since requests of that sort should invoke the error path on RFC > > compliant servers it's a really good distinguisher since legitimate > > clients will not do such a thing. Existing realistic adversaries > > already have "identify 'suspicious behavior', call back to confirm" > > style filtering in production, so false positive rate can be reduce > > to 0 if needed. > > > > Based on our exploration of data, we found there's a wide range of > implementations and most of which have non-RFC-compliant behaviors. > See Section 4 of our paper for more details. For that reason I'd be > very surprised if a host-header-check could result in a 0 FP rate. The point isn't to use non-compliance as the sole discriminator (since people do write broken code), but to cut down the candidate IP/Port list down to something that's reasonable for whatever active probing infrastructure that exists to manage. From there, delta-T later with separate infrastructure attempt a full FTE + Tor handshake, and blacklist/RST inject/etc target candidates that succeed. The second step gets to 0 FP, and precisely this sort of thing is how China currently handles obfs3. The delay (anecdotal) is about 10 mins. Intuitively I think that "missing Host header" will be extremely rare but I don't have a way to get traces to prove/disprove it. > With that being said, I'll add the host-header-check to the list of > experiments that we want to do for the full version of our paper. > Would be interesting to learn what the data tells us. I would be interested in seeing the results. -- Yawning Angel [0]: Ngnix supports hooking the error handler rather easily, apache less so. pgpufIOwlRYHG.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: Single onion services
On Fri, 4 Sep 2015 15:31:15 -0600 John Brooks wrote: [snip] > > > > Have you considered all the implications? > > Maybe we’ve missed some - what implications are you thinking of, that > aren’t addressed in the proposal? I have two objections to this, one political, one technical: * (The political objection) While this is "cool" and probably(?) "funded", it seems like a poor thing to work on in terms of developmental priority when there are other things Hidden Service related that need a lot of developer attention, primarily in making the existing HSes more resilient against Nation State level adversaries (Eg: Prop. 224). * (The technical objection) It is overly easy for assholes[0] to censor Single Onion Services due to: it’s possible for the previous relay to guess the service you’re connecting to While such a censor would only be able to deny service to clients as a fraction of their relay(s) consensus weight, it's still something that probably should get consideration. Regards, -- Yawning Angel [0]:https://lists.torproject.org/pipermail/tor-dev/2014-July/007167.html pgpGe9WwNRTrz.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] fteproxy depends on obfsproxy...
On Mon, 7 Sep 2015 14:37:07 -0700 Kevin P Dyer wrote: > ...and it shouldn't. > > Fortunately, the dependency is isolated to a single file. See [1]. > > My understanding is that pyptlib [2] is no longer maintained. It isn't? It hasn't gotten any updates because nothing broke and the pt spec is relatively static (for now, eventually it'll change and pyptlib will get a flurry of updates as needed). > wiley/asn/etc. - What's the proper way to remove this dependency, but > make it easy for fteproxy to be a PT? There isn't an easy way beyond "reimplementing all the functionality currently provided by obfsproxy". It probably won't be overly hard to do but implementing yet another socks 5 server is likely to be tedious and annoying. Regards, -- Yawning Angel pgpez_6JGENFX.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] Towards a new version of the PT spec...
So, we currently have a Pluggable Transport (PT) spec, and it kind-of sort-of works (The documentation is a mess that I'm working on cleaning up, but it's an orthogonal issue for how well it works). There are a number of problems with the current PT spec that require breaking backward compatibility to fix, so eventually I would like to do so. I'm soliciting input on what people would also like to see in a (currently hypothetical) PT spec 2.0 beyond what I already have in mind: MUST haves: * Support dual stack Bridges correctly (Multiple server endpoints per transport) * Increase the argument space beyond 510 bytes (Prop. #227). * Mandatory ExtORPort support (currently optional, but metrics are good). * Centralized logging by the calling process (Probably via stderr). * AF_UNIX support where sensible for better sandboxing. MIGHT haves: * Rename the env vars to not start with "TOR_PT". Some people claim that this is a good idea (I think it is stupid and cosmetic). * Ability to force at least clients to stop network activity without tearing the PT down. * Deprecate SOCKS4a, and make SOCKS5 mandatory for clients. UNLIKELY: * Specify an interface for where fork()/exec() isn't possible (iOS). I don't think this is makes sense because it is probably too platform/caller specific. * Allow operating both as a client and a server simultaneously. I don't see a problem with running 2 copies of something for this use case. I probably missed some things. If people have strong opinions about this, do reply, otherwise I *will* design something that I like, which will not include what other people want. Regards, -- Yawning Angel pgpk_4mdbY6Vi.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] fteproxy depends on obfsproxy...
On Mon, 7 Sep 2015 17:03:00 -0700 Kevin P Dyer wrote: > Response inline. > > On Mon, Sep 7, 2015 at 3:29 PM, Yawning Angel > wrote: > > > On Mon, 7 Sep 2015 14:37:07 -0700 > > Kevin P Dyer wrote: > > > > > ...and it shouldn't. > > > > > > Fortunately, the dependency is isolated to a single file. See [1]. > > > > > > My understanding is that pyptlib [2] is no longer maintained. > > > > It isn't? It hasn't gotten any updates because nothing broke and > > the pt spec is relatively static (for now, eventually it'll change > > and pyptlib will get a flurry of updates as needed). > > I was speaking to Brandon Wiley about this last week. I don't want to > speak for him, but I remember him saying that it's no longer being > developed. > > Either way, does pyptlib help solve this issue? It somewhat reduces what you'll need to re-implement but not significantly since you'd still need to re-implement all the stuff that touches the network. -- Yawning Angel pgpWch1oFN68d.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] Towards a new version of the PT spec...
On Tue, 8 Sep 2015 17:39:58 +1000 Tim Wilson-Brown - teor wrote: > > > On 8 Sep 2015, at 08:45, Yawning Angel > > wrote: > > > > So, we currently have a Pluggable Transport (PT) spec, and it > > kind-of sort-of works (The documentation is a mess that I'm working > > on cleaning up, but it's an orthogonal issue for how well it works). > > > > There are a number of problems with the current PT spec that require > > breaking backward compatibility to fix, so eventually I would like > > to do so. > > > > I'm soliciting input on what people would also like to see in a > > (currently hypothetical) PT spec 2.0 beyond what I already have in > > mind: > > > > ... > > > > UNLIKELY: > > * Specify an interface for where fork()/exec() isn't possible > > (iOS). I don't think this is makes sense because it is probably too > >platform/caller specific. > > I imagine that this would require a PT-as-thread(s) interface, which > is out of scope, as iOS is a single platform. It seems to me that > using a PT on iOS could be done in a similar way to using tor. (That > is, if you can’t fork tor from an iOS app, then forking PTs is the > least of your worries.) I was thinking PTs as a shared object of some sort with presumably but not necessarily lots of threads under the hood. But I marked this as UNLIKELY precisely because it's a lot of effort for a single platform (however important) that isn't targeted by an official Tor anything at this point. It also is a platform I don't have access to, and never will, so unless someone is willing to chime in on how to properly support this sort of thing in a way that doesn't clutter up the PT spec and implementations with a lot of extra stuff it won't happen. > I’m hoping someone has developed a generic way of doing this, at > least for network apps. What are the ChatSecure people doing for > their XMMP + Tor chat accounts? Launching pthreads? Don't know, don't care at this moment since it's totally orthogonal to drafting a new Pluggable Transports spec (That doesn't mean that it isn't important, just trying to keep discussion on track.). Regards, -- Yawning Angel pgptXr0MPflc5.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] Reproducibility of Pluggable Transports python.msi
On Wed, 9 Sep 2015 17:20:11 -0400 Brandon Wiley wrote: > Thanks David, great info! Last time I checked, I think the C > implementation was also still shipping with something, I think Orbot > for Android. Perhaps this is also for either flash proxy or FTE > support, since Python is not the best option on Android. Orbot used to use obfsproxy (C), migrated to obfsclient (C++) and the main build uses obfs4proxy (Go) these days. I heard that Android x86 might still need to use the C++ code, but I'm not sure. > From the graphs it looks like FTE is still in use, but that flash > proxy seems to no longer be used. It wasn't really every used due to NAT related issues. WebRTC may be the way forward here but it will be an entirely different codebase. > If I recall correctly, the core FTE code is actually written in C and > is just using the Python PT implementation with Python-C bindings to > the FTE library. So a port of the FTE PT to the Go PT implementation > seems possible. The core FTE code was originally in C++, but IIRC it's in python now. FWIW, I don't particularly think that there must be One True PT language[0], I just recommend Go over the other alternatives due to it being both memory safe and easy to build on mobile. If someone writes a new PT in Python, I don't consider it a deal breaker, though it won't be as useful due to the difficulty of mobile support. All of this sort of ties into the other thread where people are talking about buffing up pyptlib (might make sense), and further deprecating obfsproxy (Python). I don't particularly see a reason to do either things, though the Debian people apparently see obfsproxy as the program and not a library, when it's both. Regards, -- Yawning Angel [0]: MUST be able to be built deterministically. SHOULD be memory safe. Past that, people can do what they want. If they ignore the SHOULD clause, the code needs to undergo more thorough auditing before it will be deployed into production. pgpiHqLAfVSiX.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] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests
On Thu, 10 Sep 2015 07:01:58 + isis wrote: > 3. Should we change how the BridgeAuthority tests Bridge ORPort > reachability? If so, how? > > 4. If I'm going to refactor all of this, are there other (future) > things I should take into account? > > For example, if self-testing is disabled for Bridges, and, due to > #7349, [2] the BridgeAuthority isn't testing reachability either, > then how will the BridgeAuthority know if (any of) the Bridge's PTs > are reachable? (One solution might be to, in that case, have the > BridgeAuthority lie and tell BridgeDB that such Bridges were > reachable, letting BridgeDB do the PT reachability testing.) All of this seems to me like we need to sit down somewhere (in meatspace or online), map out how the current system of: * Clients * Bridges * Bridge Guards * The Bridge Authority fits together, and figure out how it can be redesigned in a way that is more inline with how things work now/need to work now (PTs were not a thing when this started being one of the bigger stumbling blocks). Regards, -- Yawning Angel pgpNTCxTZUKfj.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] Reproducibility of Pluggable Transports python.msi
On Thu, 10 Sep 2015 10:20:59 -0400 Brandon Wiley wrote: > I'm not advocating that the various PT implementations be abandoned, > just that we have a common implementation across products when > possible. If I recall correctly, there was a time when TBB, Tails, > and Orbot were all shipping different implementations. I think the > current state of PT implementation deployment is the following: > > TBB: Go, Python > Tails: Go > Orbot: Go, C++ (on x86) That's correct. It's worth noting that the Python component of TBB is almost entirely FTE that hovers around ~200 users. Out of those, I am unsure how many use FTE because it is the only thing that works in their environment. > The benefit of having the Go implementation ship with all products is > that PT authors can target one implementation and achieve deployment > across all of the products. Sure. Go would be a fine choice for people, but I'd like it to be explicit that I'm open to more options, even if it means reducing the deployment base if that's what it takes for people to write something (I'd rather see more circumvention methods, than fewer). > As far as reproducibility of builds goes, if a reproducible Python > build is a challenge, an alternative is to port FTE to Go and retire > flashproxy. Or port both to Go (flashproxy would be easy)/deprecate both. Regards, -- Yawning Angel pgpeJvU5SJO1N.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: End-to-end encrypted onion services for non-Tor clients
On Mon, 14 Sep 2015 16:12:23 + Donncha O'Cearbhaill wrote: > I have been thinking about ideas to make Tor hidden services more > available and secure for non-Tor users. Inline I've included a draft > proposal which describes an end-to-end encrypted Tor2Web-like system. > > I'm really interested in hearing any suggestions, comments or > criticism about this proposal. In particular I'd like to know if the > trust requirements for the entry proxies and resolvers seem > reasonable? Does this proposal make sense and is it something worth > implementing? I don't understand the use case for this, given the design presented. If the HS operator is willing to register a domain, run a public name server, and pay for a CA cert, why host the actual content on a Tor HS? It should be emphasized that the user has absolutely zero anonymity under this scheme, in that anyone tapping the link between the user and the proxy can see what domain the user is trying to view. Anyone with the capability to inject RSTs can censor on a per-site basis as well. Regards, -- Yawning Angel pgpDz8wgITs4p.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] Towards a new version of the PT spec...
On Mon, 14 Sep 2015 16:14:41 -0400 Brandon Wiley wrote: > It is my understanding that a sponsored project is coming up to work a > pluggable transport 2.0 specification and implementation. I've also > heard that the first step for this is to have a meeting where we get > together with people that either use pluggable transports or > implement them, for the purpose of soliciting feedback on the > existing specification and gathering design requirements for 2.0. So > perhaps the drafting of a new specification should be deferred until > this is organized. Although of course any feedback gathered in this > email thread can also be presented at the meeting. This would be the first I heard of either. Till someone tells me details about this, I think the sensible thing to do would be to discuss it here... It's not as if lots of people seem interested in giving feedback anyway at present so I'll probably end up drafting something that does what I want it to do (which fixes the major current shortcomings of the interface from my POV), at which point all the other people will appear to complain. Regards, -- Yawning Angel pgpcmJoDQOZYh.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] Towards a new version of the PT spec...
On Thu, 17 Sep 2015 14:28:24 -0400 Adam Pritchard wrote: > At Psiphon we often discuss (and get asked about) using Tor's > pluggable transports directly. The cost/benefit balance hasn't yet > been in favour of doing this, but if there's discussion of a big PT > revamp... maybe Psiphon should indicate how the cost side of the > balance could come down for us. > > We're obviously not a priority for what Tor does with PTs, but there's > surely no harm in us mentioning our wishlist. So... > > What would be best for us is if PTs were written in Go and implemented > the net.Conn[1] interface. We have had good results with the > composability of net.Conn implementations: an obfuscated SSH net.Conn > on top of a meek net.Conn[2] on top of a upstream proxy net.Conn[3] on > top of a TCPConn net.Conn[4]. Layering in a PT net.Conn would be sane > and clean and reasonably easy. > > Conversely: Python is difficult-to-impossible due to runtime > distribution. Separate executables are difficult-to-impossible due to > Android PIE requirements and distribution size bloat. The Guardian project people seem to manage to handle distributing multiple separate executables (tor, meek, obfs4proxy). I do not know what they do, maybe they just take the size hit. > Anyway, if this is of any interest we can discuss it further. I'm interested in hearing what people want but: * I personally am against forcing any particular language on people, since the point of PTs is that they are easy for interested parties to write. * Pluggable Transport implementations sharing address space with the Tor binary is basically never going to happen due to security concerns (iOS may do weird things, but iOS is not an officially supported target). The revamp is more of a "keeping the current model the same (ie: fork/exec a helper process with a known external interface), how can we make said external interface better" than "change the entire Pluggable Transport concept". > (Note: Probably Lantern people are reading this too. And probably they > would benefit from the same things we would, since their architecture > is similar to ours.) Now despite all of this, the obfs2/3/4 and ScrambleSuit implementations I did for obfs4proxy do in fact implement a net.Conn interface[0] and always have[1]. Regards, -- Yawning Angel [0]: https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/transports/base/base.go [1]: I reserve the right to implement a hypothetical `obfs5` in something that is not Go, depending on the availability of required libraries/primitives, my mood, the phase of the moon, and planetary alignment. pgpwFNWoJiMAq.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] Desired exit node diversity
On Wed, 23 Sep 2015 06:18:58 + Virgil Griffith wrote: > * Would the number of exit nodes constitute exactly 1/3 of all Tor > nodes? Would the total exit node bandwidth constitute 1/3 of all Tor > bandwidth? No. There needs to be more interior bandwidth than externally facing bandwidth since not all Tor traffic traverses through an Exit (Directory queries, anything to do with HSes). The total Exit bandwidth required is always <= the total amount of Guard + Bridge bandwidth, but I do not have HS utilization or Directory query overhead figures to give an accurate representation of how much less. Regards, -- Yawning Angel pgpRhKLezTcGv.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] Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are blocked by China's firewall.
On Thu, 1 Oct 2015 08:26:50 -0700 David Fifield wrote: > I don't know about a schedule for deploying SkypeMorph and Dust. They > may not help in your case anyway. The GFW is probably blocking the IP > addresses of your bridges, not detecting the obfs4 protocol itself. SkypeMorph: Never. (Licensing issues among other things) Dust: I assume you mean Dust2, the original Dust is not getting deployed. Not sure yet. [Folding in the 2nd reply] > If you know some details of how I2P resists blocking, please add them > to this wiki page: > https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports It doesn't do anything special. The old TCP based protocol (NTCP) is trivially identifiable. Blocking the more modern UDP protocol (SSU) would require looking for high-entropy UDP or doing statistical attacks IIRC. Active probing is possible if they run a node that's part of the network and obtain enough key material (But, I'd need to look at the floodfill system again to figure out how many nodes for how long is realistically required). Regards, -- Yawning Angel pgptgowGyqoHR.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] Another Virtual Network Environment needs your I/O
On Fri, 16 Oct 2015 15:03:49 +0200 Rob van der Hoeven wrote: [snip] > Because the network interception takes place at the IP-level, no > special Tor configuration is needed. In theory all TCP-clients should > now be able to use the Tor network. Cute. The networking part works in a near-identical manner Orbot's Android VPN mode, under the hood, except they opted to use a 3rd party implementation (that bundles lwIP IIRC). Why did you write your own IP/ICMP/TCP (partial) implementations instead of using something like lwip? As your blog post notes "There are still some loose ends", most of these should be known issues (From quickly skimming the code, there is a possibility I've missed things or I'm wrong): * No IPv6. * No congestion control (TCP Tahoe is fairly trivial to implement, and would be more than sufficient). * Things will break/perform poorly if there ever is loss on the TUN interface (Unlikely, I know). * Out-of-order but in window segments are discarded, instead of stashed for use later. * No slow retransmission timer. * The implementation does not ACK enough. Send a dup. ACK when you receive something that's Out-of-order but in window. Probably doesn't matter much since the stack is never exposed to a public network and is only ever within the confines of a single host. > The second question I have is: are there programs / protocols which > should be blocked by avne? For example: I think its a bad idea to > support unencrypted POP3. I think users should be allowed to shoot themselves in the foot if they want to. > Of course I am also interested in bug-reports and your ideas for > improvement. Code looks fairly clean. I'd feel better if it was in a memory safe language, but I like C/C++11 more than all the new popular stuff so I probably would have made a similar decision. Should be easily portable to the U*IXes, Windows will give you pain, but I'm not sure you care. I assume you use version control for the code and are just not exposing it to the world. Regards, -- Yawning Angel pgpa9OE2cELXj.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] Another Virtual Network Environment needs your I/O
On Sun, 18 Oct 2015 13:08:01 +0200 Rob van der Hoeven wrote: [snip] > When I was researching my idea I came across lwIP and was planning to > use it. Unfortunately I could not find documentation. It's not on the > project homepage and the wikia pages were not helpful too. What I > needed was the info provided by the lwIP paper by Adam Dunkel. Found > this paper yesterday trough the wikipedia article about lwIP. > > I always try to understand a technology that I use, even if I use an > implementation by someone else. So I studied the TCP protocol. From > this I got the idea that a full TCP protocol implementation was not > needed to correctly handle *my* tun traffic. Writing a simplified TCP > protocol would give me some major advantages: perfect integration > with my design and no extra external dependencies. Sounds reasonable, and yeah the lwIP documentation isn't great. > > As your blog post notes "There are still some loose ends", most of > > these should be known issues (From quickly skimming the code, there > > is > > Fair enough, the loose ends are: > > - The proxy uses two connections, an upstream connection and a TCP > connection. If one of the two connections closes, the other connection > is closed immediately. There is however a (very?) small change that > there is still data in a buffer that must be written to the open > connection. The open connection should close after this data is > written. Fairly easy. > - Needs more testing. I have tested the program in a loose way. For > hours and hours I have watched YouTube videos, visited nasty websites > (lots of advertisements, scripts and simultaneous connections), and > downloaded very large files using WGET. Everything seems to work, but > *seems* is not enough it most be *proven* to work correctly. > > - No unit tests. > > > a possibility I've missed things or I'm wrong): > > > > * No IPv6. > > * No congestion control (TCP Tahoe is fairly trivial to implement, > >and would be more than sufficient). > > Congestion control is used to prevent dropped segments. This can not > happen on the User Space <-> kernel connection of a tun interface. The > TCP-window flow control prevents this. Hm. Your code never shrinks the advertised window, and ACKs once when data has been added to the receive buffer. As a perfectionist for such things, this makes me really sad, but since it the stack never sees the light of day outside a TUN interface, the behavior is probably ok. As a side note, the TUN driver will happily drop packets once the backlog exceeds 500 or if a skb allocation fails. Both unlikely, both can happen. [snip] > "Want to" implies that the user is aware of the danger. Most users > have no idea about the dangers of using a particular protocol over > Tor. I want to protect these users. Fair enough. I'd suggest this be configurable behavior. See `WarnPlaintextPorts` in the tor manpage for what should be a sensible list. If you want to protect users from danger, you'd probably also want to disallow port 80 and 443 by default, because they're giving up a lot by using what is probably the Wrong Browser[1]. They may even think that viewing Flash/Java content is safe, when neither are because the plugins are all sorts of terrible. > > Should be easily portable to the U*IXes, Windows will give you pain, > > but I'm not sure you care. > > I care, and I think it can be ported to Windows. Since there are no > kernel namespaces, another way to force all traffic through the tun > interface must be found. It can be done by using the Windows firewall > like this: > > https://community.hide.me/tutorials/bind-your-connection-to-vpn-with-windows-firewall.49/ Guess you'll use the OpenVPN TUN/TAP driver? Some more random things: * PSH is set incorrectly. You set PSH when you're ACKing received data (without piggybacked payload). You're supposed to PSH as part of sending data to the peer (See RFC 1112 4.2.2.2). * DNS resolution does not work if /etc/resolv.conf points at 127.0.0.1. This probably is a documentation thing rather than a code thing. * I couldn't figure out how to get X apps to work at all. (Eg: chromium fails with "Gtk: cannot open display: :0") * There should be documentation that this requires a minimum of CAP_SYS_ADMIN (for the various unshare() calls) and CAP_NET_ADMIN (to bring the tun interface up). * The config file load/parse routine has a trivially exploitable buffer overflow. -- Yawning Angel [1]: Tor Browser would be the Less Wrong Browser. pgpbSQfK93qdj.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] Another Virtual Network Environment needs your I/O
On Sun, 18 Oct 2015 19:20:47 +0200 Rob van der Hoeven wrote: > I never adjust the size of the TCP window, that's correct. The code > only sends an ACK for data that is *removed* from the buffer. If data > is added to the buffer, the amount of data the TCP-client is allowed > to send decreases. Eventually becoming zero if no data is removed at > all. Yeah. Since your receive window isn't ever sizable, and the interface is rather reliable, this behavior is probably the simplest. [snip] > > * I couldn't figure out how to get X apps to work at all. > >(Eg: chromium fails with "Gtk: cannot open display: :0") > > Ah, your system probably uses an Abstract Unix Socket for > communication with the X server. Abstract Unix Sockets are created > inside a network namespace, and your X server socket lives inside the > global network namespace. To solve this I have to write proxy code to > create an X server socket inside the network namespace of the TCP > client. Maybe you can temporarily solve the problem by binding your X > server socket to a normal Unix socket? (filesystem Unix Sockets are > not network namespace aware). > > What OS (name+version) are you using? I'm using Debian Wheezy which > does not have this problem. Arch. It's a rolling release system, and it's up to date-ish. It's not a big deal at the moment... > > * There should be documentation that this requires a minimum of > >CAP_SYS_ADMIN (for the various unshare() calls) and > > CAP_NET_ADMIN (to bring the tun interface up). > > AVNE is a suid program at the moment. To do the privileged calls the > program runs (for a while) with root privileges. Oh, well. Using setcap and granting the relevant capabilities also works, though dropping the capabilities requires a bit more work. The elevated capabilities aren't persisted across exec() at least so the child side handling is easy. > I'm going to move to Debian Jessie. This version has a newer kernel > that supports user namespaces. As I understand it (have not played > with user namespaces), these can be used to create programs that can > have full privileges inside the user namespace without having full > privileges themselves. No more suid needed. The downside is that user > namespaces are only available for kernels with versions >= 3.8 Well. Debian requires enabling it by writing to proc (they have a patch for this). Arch flat out doesn't include support for that in the vanilla kernel (https://bugs.archlinux.org/task/36969?project=1), ditto anyone using grsec. It's probably not that much code to support user namespaces, running with just the required capabilities, and running as suid root in the same code base. > > * The config file load/parse routine has a trivially exploitable > >buffer overflow. > > The final config file will be owned by root and stored in /etc. Ah I see (I assume/hope you'll fix this anyway). (Will there also ever be an option for configuring a different tun address?) Neat project. I'll be looking forward to subsequent releases, since this is slick, and I think a better approach than torsocks once it matures a bit. Regards, -- Yawning Angel pgpfz03dZtqv8.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] A layered transport
On Mon, 26 Oct 2015 15:44:59 +0800 Da Feng wrote: > Hi: >I've discovered that the GFW normally doesn't block https > protocols. We can use a https front tier to distribute connections to > actual bridges. The front tier encrypts an internal address identifier > with its private key (no matching public key or public algorithm) and > returns to user the encrypted identifier, part of which also includes > the user's chosen password. Then when submitting requests, the user > encrypt again with his password the items such as his timestamp, > broswer headers. The request line to https server is no different from > an ordinary one and include both the user encrypted item and front > tier encrypted item. After the connection is established, data is > relayed inside https between bridge and user. So... meek (https://trac.torproject.org/projects/tor/wiki/doc/meek), the basis of which will probably also be used for bridge distribution purposes in the future. Regards, -- Yawning Angel pgpYXv2foZmjQ.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 v1 spec rewrite.
Hello all, In an attempt to make Pluggable Transports more accessible to other people, and to have a spec that is more applicable and useful to other projects that seek to use Pluggable Transports for circumvention, I have drafted a re-write of the spec. This is not intended to alter existing behavior, but instead make it clear that the whole "Pluggable Transports" thing isn't just for Tor. Unless people have serious objections, this will replace the existing PT spec, to serve as a stop-gap while the next revision of the PT spec (that does alter behavior) is being drafted/implemented. Regards, -- Yawning Angel Pluggable Transport Specification (Version 1) Abstract Pluggable Transports (PTs) are a generic mechanism for the rapid development and deployment of censorship circumvention, based around the idea of modular sub-processes that transform traffic to defeat censors. This document specifies the sub-process startup, shutdown, and inter-process communication mechanisms required to utilize PTs. Table of Contents 1. Introduction 1.1. Requirements Notation 2. Architecture Overview 3. Specification 3.1. Pluggable Transport Naming 3.2. Pluggable Transport Configuration Environment Variables 3.2.1. Common Environment Variables 3.2.2. Pluggable Transport Client Environment Variables 3.2.3. Pluggable Transport Server Environment Variables 3.3. Pluggable Transport To Parent Process Communication 3.3.1. Common Messages 3.3.2. Pluggable Transport Client Messages 3.3.3. Pluggable Transport Server Messages 3.4. Pluggable Transport Shutdown 3.5. Pluggable Transport Client Per-Connection Arguments 4. Tor Configuration (torrc directives) 4.1. Client Configuration 4.1.1. ClientTransportPlugin 4.1.2. Bridge 4.2. Server Configuration 4.2.1. ServerTransportPlugin 4.2.2. ServerTransportListenAddr 4.2.3. ServerTransportOptions 5. Anonymity Considerations 6. Future Improvements 7. References 8. Acknowledgments Appendix A. Example Client Pluggable Transport Session Appendix B. Example Server Pluggable Transport Session 1. Introduction This specification describes a way to decouple protocol-level obfuscation from an application's client/server code, in a manner that promotes rapid development of obfuscation/circumvention tools and promotes reuse beyond the scope of the Tor Project's efforts in that area. This is accomplished by utilizing helper sub-processes that implement the necessary forward/reverse proxy servers that handle the censorship circumvention, with a well defined and standardized configuration and management interface. Any application code that implements the interfaces as specified in this document will be able to use all spec compliant Pluggable Transports. 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Architecture Overview +++---+ | Client App +-- Local Loopback --+ PT Client (SOCKS Proxy) +--+ +++---+ | | Public Internet (Obfuscated/Transformed traffic) ==> | | +++---+ | | Server App +-- Local Loopback --+ PT Server (Reverse Proxy) +--+ +++---+ On the client's host, the PT Client software exposes a SOCKS proxy [RFC1928] to the client application, and obfuscates or otherwise transforms traffic before forwarding it to the server's host. On the server's host, the PT Server software exposes a reverse proxy that accepts connections from PT Clients, and handles reversing the obfuscation/transformation applied to traffic, before forwarding it to the actual server software. An optional lightweight protocol exists to facilitate communicating connection meta-data that would otherwise be lost such as the source IP address and port [EXTORPORT]. All PT instances are configured by the respective parent process via a set of standardized environment variables (3.2) that are set at launch time, and report status information back to the parent via writing output in a standardized format to stdout (3.3). Each invocation of a PT MUST be either a client OR a server. A
Re: [tor-dev] Pluggable Transports v1 spec rewrite.
On Thu, 29 Oct 2015 10:27:53 -0400 Nathan Freitas wrote: > Any small or big changes to highlight that push us to the more > accessible goal? Well, it emphasizes that it's generic, gives a better view of the architecture, and should be usable by anyone competent (unless my rewrite is bad) to add support for Pluggable Transports to any client/server code base. All the Tor specific stuff is neatly contained in it's own section now that people can be free to ignore. Stuff it still should do: * Fold in the ExtORPort spec since that's useful for people that aren't tor. * Document the tor pt external mode torrc configuration format (In my defense, the current spec doesn't do this either). So, yes? Dunno. There's a limit to how far I can de-torify this sort of document, and I think this is a reasonable step in the right direction. Regards, -- Yawning Angel pgp2LOhKYB67e.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 v1 spec rewrite.
On Thu, 29 Oct 2015 10:04:24 -0500 Brandon Wiley wrote: > Excellent work on the rewrite. To summarize for those that do not > have time to read the whole document, it's the same spec, it's just > been rewritten to read more clearly. I think it's a great improvement > over the previous version. > > I have two suggestions: > > Section 4, "Tor Configuration", I think should be moved into another > document and a reference should be added instead. While it's useful > for developers reading the PT spec to see how to configure their Tor > nodes so they can test their PTs, this information is going to be > used mostly by bridge operators. Bridge operators shouldn't have to > go to the PT spec to figure out how to configure their bridge. PT > developers though will need to configure a bridge anyway, so I think > it's sensible to at the end of the PT spec send them to the bridge > configuration documentation and the PT configuration section > specifically. Ok, I'll carve it off to a different document. To be honest I think it's somewhat redundant to have the documentation at all (since it's just a bunch of torrc directives), and there's better places for configuration documentation (like the man page). > Section 6 "Future Improvements" I think should be moved into a PT > roadmap document. There is a lot to discuss regarding future > improvements. My list for the most part does not overlap with this > list. We could engage in healthy debate over what should go in the > future improvements section, but this seems to me to be something > better done when drafting a roadmap document rather than in the spec. > It would of course be useful to add a reference to any roadmap > documentation at the end of the spec. The things listed there are the things that need to happen from Tor's perspective, and I'm not currently considering a huge "Change All The Things" type of rework if we were to bump the spec version. But I'll remove the section as unnecessary for now. Regards, -- Yawning Angel pgppIEZaPmNQU.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-commits] [tor-messenger-build/master] Bug 17492: Include default bridges configuration
On Fri, 6 Nov 2015 19:29:45 -0800 David Fifield wrote: > > This could be a great opportunity for Yawning's recent meek variant > > that doesn't use an actual browser. (It won't work as well as the > > real meek, but maybe no actual adversaries care about the > > difference quite yet?) > > You can also just run meek-client without the Firefox helper. It has a > standalone mode. Just change the torrc line > > ClientTransportPlugin meek > exec ./TorBrowser/Tor/PluggableTransports/meek-client-torbrowser > -- ./TorBrowser/Tor/PluggableTransports/meek-client > > to > > ClientTransportPlugin meek > exec ./TorBrowser/Tor/PluggableTransports/meek-client > > There's a man page for meek-client: > https://gitweb.torproject.org/pluggable-transports/meek.git/tree/doc/meek-client.1.txt Yeah, the obfs4proxy change is mostly just to save bundle size/disk space for android and the like. Regards, -- Yawning Angel pgpWolTQ8xEgY.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] Proposal: Link Cryptographic Agility
Hello,
There's been talk of moving to a wide block construct for cell crypto
(#5460), and for adding PQ Forward Secrecy to traffic (#17272). To
facilitate this, there needs to be a method for negotiating which
primitives a given relay supports.
To that end, here's the begining of a proposal (tentatively #260) that
adds a `CIPHERSUITES` cell to the version negotiation process which
allows relays to advertise the link cryptography primitives that they
are willing to accept.
TODOs/TBD:
* Should the new cell be variable length? Our development cycle and
how often we switch handshakes/link crypto tells me "No", the
existing "VERSIONS" cell format tells me "Yes".
* We need to revise prop. 249 to add a cell crypto method specifier to
CREATE2V/EXTEND.
* Proposal 249 does not cover changing RELAY_EARLY behavior, which
will potentially cause problems (Eg: Ring-LWE + ntor will require
between 5 to 9 fragments depending on the exact primitives).
* The actual hybrid construct is deliberately left unspecified.
* With runtime negotiation of primitives on a per-circuit basis, we
introduce the possibility of downgrade attacks. We do calculate
the SHA256 digest of VERSIONS/CERTS/AUTH_CHALLENGE cells (which
will become VERSIONS/CIPHERSUITES/CERTS/AUTH_CHALLENGE), so we could
do something like:
auth_input = verify | ID | B | Y | X | SLOG | PROTOID | "Server"
Where SLOG is the digest without too much difficulty...
The alternative to all of this would be something like including
handshake methods/supported link crypto in the descriptors, but that
seems silly.
Regards,
--
Yawning Angel
Filename: 260-cryptography-agility.txt
Title: Link Cryptography Agility
Created: 2015-11-15
Status: Draft
Extends: 249-large-create-cells.txt
1. Overview
This proposal aims to add per-circuit cryptographic agility, such that
the link handshake and cell layer encryption can be specified on au
per-circuit basis.
Once support for the negotiation mechanism in this proposal has been
deployed, it will be possible to introduce support for new circuit
handshake and/or cell encryption methods without the need for further
wire protocol changes.
2. Negotiation Process
The initator and responder MUST negotiate version 5 or higher to indicate
support for the CIPHERSUITES, CREATE2V and CREATED2V cells along with
fragmented EXTEND2 cells.
3. CIPHERSUITES cells.
Upon negotiating version 5 of the link protocol and sending a VERSIONS
cell, the responder sends a CIPHERSUITES cell befor sending the CERTS
cell to indicate which handshake methods, and which link encryption
primitives it supports.
(XXX: Should this be variable length? At the rate that we will change
handshake/cell crypto, I doubt space will ever be a concern, but
VERSIONS is variable length...)
struct ciphersuites_cell_body {
/* Number of supported handshake types */
u16 hlen;
/* Supported handshake types */
u16 handshake_types[hlen];
/* Number of supported cell crypto types */
u16 clen;
/* Supported cell crypto types */
u16 cell_crypto_types[clen];
/* Padding data to be ignored */
u8 ignored[];
};
The initiator then selects the "best" algorithms supported by the peer
as appropriate.
To prevent downgrade attacks, both parties MUST include the contents of
the CIPHERSUITES cell as part of the link handshake calculations, for
example by including the SLOG (AUTHENTICATE cell) SHA256 hash in the
ntor "auth_input" field.
XXX: It occurs to me that we should include a 2 byte cell crypto specifier
in the CREATE2V/fragmented EXTEND2 cells.
4. Cell Crypto Types
The following cell crypto types are defined and reserved:
0x - CTR-AES128 + SHA1 -- the original Tor cell crypto
0x0001 - reserved (AEZ?)
pgpCMw8okYasS.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: Link Cryptographic Agility
On Mon, 16 Nov 2015 21:58:41 + isis wrote: > Hey Yawning, > > I'm generally in favour of merging this, but I'll wait a couple days > to see if anyone has any feedback. Particularly, I'd like to hear if > Nick has any comments. I talked to Nick about this, and now think that adding a line or two to each microdescriptor probably is less painful. So no need to merge this. > What new behaviour do we need from RELAY_EARLY? If I understood > prop#249 correctly, RELAY_EARLY should work as before (in particular > with 8-9 total RELAY_EARLYs allowed per circuit construction), but > that (potentially multipartite) EXTEND2(s) within RELAY_EARLY(s) > should contain variable length authentication data. Are you just > concerned that we'll go over the 8-9 cell limit and open ourselves > back up to infinite circuit attacks? Or am I missing something? Since this is an orthogonal issue... Until the changes that Nick added to #249 last night, RELAY_EARLY behavior was unspecified for fragmented EXTEND cells. The pedantic interpretation could have been "all fragments must be contained in RELAY_EARLY", which wouldn't let you build circuits consisting of more than 1 hop. Since only the first fragment needs to be in RELAY_EARLY now, there's no further issues. I'm gonna poke at some other things (in particular I'm multithreading the rest of our circuit build crypto) for a bit before I come back to this, but I have a rough idea of what I want our PQ options to look like. Regards, -- Yawning Angel pgpqk8e9qQLKD.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] displaying an ed25519 signing key's expiry date
On Thu, 19 Nov 2015 11:42:16 + nusenu wrote: > >> How can a tor relay op display a given signing key's expiry date? > >> > > > I don't think there is an option for this. > > filed a ticket for it: > https://trac.torproject.org/projects/tor/ticket/17639 > > > Is there a custom openssl command to display the expiry date until > this gets implemented in tor? No. The on disk Ed25519 key format is custom to Tor, and the code doesn't use OpenSSL for any of the Ed25519 operations anyway. Someone that wants to work on this should find the relevant data formats documented in prop 220. Regards, -- Yawning Angel pgpJcH4BDshFu.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] Have the Tor daemon use more cores
On Tue, 1 Dec 2015 09:19:45 -0500 Jeremy wrote: > I've been working on the volunteer project described here > https://www.torproject.org/getinvolved/volunteer.html.en#useMoreCores > but can't spend much more time on it. > > Right now, I have refactored circuit_receive_relay_cell() in relay.c > (which calls relay_crypt() and eventually the AES crypt routines) to > use the workqueue.c infrastructure similar to cpuworker.c. > > When the refactored code runs in single threaded mode, all seems > good. Once I activate the thread pool and start sending it work with > threadpool_queue_work(), it Bootstraps 100% okay and runs for several > minutes before crashing on cells it doesn't handle properly. > > I'm happy to share my code with anyone interested. Sure I think I'm the person that used the workqueue stuff last, so I'd be up for doing the rest of the work (nb: I am traveling/in meetings for the rest of the week, so it'll be next week at the earliest that I can really spend quality time). Regards, -- Yawning Angel pgp3QgpFuOMph.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 261: AEZ for relay cryptography
[snipping liberally] On Mon, 28 Dec 2015 17:43:14 -0500 Nick Mathewson wrote: > 3.3. Why _not_ AEZ? > >There are also some reasons to consider avoiding AEZ, even if we do >decide to use a wide-block cipher. > >FIRST it is complicated to implement. As the specification says, >"The easiness claim for AEZ is with respect to ease and versatility >of use, not implementation." > >SECOND, it's still more complicated to implement well (fast, >side-channel-free) on systems without AES acceleration. We'll need >to pull the round functions out of fast assembly AES, which is >everybody's favorite hobby. > >THIRD, it's really horrible to try to do it in hardware. > >FOURTH, it is comparatively new. Although several cryptographers >like it, and it is closely related to a system with a security > proof, you never know. > >FIFTH, something better may come along. SIXTH, using AEZ requires implementing proposal 262. It's a good idea and we should do it anyway, but it is added complexity. > 4.3. Other hashes. > >We could update the ntor definition used in this to use a better > hash than SHA256 inside. We should benchmark HMAC-SHA256 vs SHA3-256 since we have code for both. I think SHA3 is a better hash function over all, so I'd be ok with a minor performance hit here, since this is parallelized already and our threadpool is currently underutilized. Regards, -- Yawning Angel pgpeuZe5Zqzsc.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 262: Re-keying live circuits with new cryptographic material
On Mon, 28 Dec 2015 17:43:57 -0500
Nick Mathewson wrote:
> 2. RELAY_REKEY cell operation
>
>To rekey, the circuit initiator ("client") can send a new
> RELAY_REKEY cell type:
>
> struct relay_rekey {
> u16 rekey_method IN [0, 1];
> u8 rekey_data[];
> }
>
> const REKEY_METHOD_ACK = 0;
> const REKEY_METHOD_SHAKE128_CLIENT = 1;
>
>This cell means "I am changing the key." The new key material will
> be derived from SHAKE128 of the aez_key concatenated with the
> rekey_data field, to fill a new shake_output structure. The client
> should set rekey_data at random.
This should be SHAKE256 to be consistent with our initial AEZ key
derivation. We're squeezing less data than the SHAKE256 rate, and we
need the same number of Keccak calls for either primitive during the
absorb phase, so there is no performance difference.
--
Yawning Angel
pgpeuirnSMomn.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] Quantum-safe Hybrid handshake for Tor
Hello, On Thu, 31 Dec 2015 20:51:43 + isis wrote: [snip] > I feel like there needs to be some new terminology here. It's > certainly not post-quantum secure, but "quantum-safe" doesn't seem > right either, because it's exactly the point at which the adversary > gains appropriate quantum computational capabilities that it become > *unsafe*. If I may, I suggest calling it "pre-quantum secure". :) Post-quantum forward-secrecy is what I've been using to describe this property. [snip] > However, if we were to go the route of using NTRU, we'd likely want > to instead use Dan Bernstein's NTRU Prime parameters, in order to > eliminate some of the inherent algebraic structure of the ideal > lattice which might possibly be exploited. [0] [1] That's a non-trivial amount of work, though I have issues with the parameter selection as well, that the authors of the proposal may be able to qualify. As I recall, the product form parameter sets are extra encumbered. Apart from key/ciphertext size and a minor performance differential, is there any reason to not use one of the X9.98 parameter sets (Eg: EES613EP1) > Also, what is the current state of patents on NTRU? My understanding > is that NTRU is dual-licenced as GPLv2+ and commercial, [2] however, > Tor is currently BSD licenced. Would it be necessary to relicense > Tor as GPLv2+? Will the GPL exceptions continue to be applied to > further patents on optimisations and improvements/protections for > NTRU? There's a FOSS patent grant, and Tim Buktu has a 3BSD NTRU implementation. (NB: The only implementation I looked at in depth is the reference Java code.) https://github.com/tbuktu/libntru It additionally supports deciding how encumbered you want the library to be (support for the product form parameter sets can be disabled at compile time). Note: Debian packaging of the library is stalled due to concerns over licensing, and the bug thread ends in a "take it to legal". https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802259 The worst case here from our perspective depending on what Debian Legal (or Fedora Legal etc etc etc) thinks about the whole thing is that we would need to feature gate (at compile time) NTRU support till 2017/2020 (depending on parameter set choices). > > 2. quantum-safe authentication: there is no quantum-safe > > authentication in this protocol. We believe that authentication can > > wait, as future (quantum) adversary cannot come back to present > > time and break authentication. Hence, we use ntor authentication to > > keep the proposal compact and simple. It will be a future work > > after this proposal. > > Not to delay progress on making Tor post-quantum secure, but if we > tackled both encryption and authentication in parallel, we'd better > able to compare the advantages and disadvantages of schemes, given > that we can take overhead fully into account, e.g. total added > keysize(s). For example, if we were to add something like a McEliese > CFS signature (code-based) or an XMSS signature (hash-based) to add > authentication, on top of already using some lattice-based > cryptosystem like NTRU, we would have two quite large keys, with one > or both needing to be distributed, for each relay. I personally don't think that any of the PQ signature schemes are usable for us right now, because the smallest key size for an algorithm that isn't known to be broken is ~1 KiB (SPHINCS256), and we probably can't afford to bloat our descriptors/micro-descriptors that much. If we decide we want to add PQ authentication with one of the current primitives Right Now, we could do something like: * Add a SPHINCS256 key to "the list of long term relay keys" and distribute it in descriptors/microdescriptors. (~1KiB binary, lots bigger b64ed). * The responder signs all the public parameters with their SPHINCS key as part of the key exchange (Go find the SIGMA paper). (+41 KiB binary, for the signature). But I would view that as premature (there's more important things that need to use PQ signatures first, like the consensus) due to primitive maturity/usability/overhead concerns. Other changes that should/could be made to the proposal: * "For 128 bits quantum security, use NTRU_EESS743EP1." should be "For 256 bits" (Section 2.3). * We have the opportunity (and code in master) to start using the FIPS 202 primitives. Since we need to modify the ntor code to anyway, we should use SHA-3 and SHAKE256 instead of HMAC-SHA256 and HKDF-SHA256 respectively. * Is it worth migrating our ECC to X448? I'll be fleshing out the proposal to specify 0x0103 around newhope, since the hybrid construct would be similar past the details of the key exchange itself. Regards, -- Yawning Angel pgptTYTGEFnsJ.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] Quantum-safe Hybrid handshake for Tor
On Fri, 1 Jan 2016 19:33:31 -0800 Ryan Carboni wrote: > The first step should be replacing the long-term keys with > quantum-safe crypto. Wrong. There are NO usable PQ signature primitives that are suitable for deployment. Adding 1408+ bytes to every single microdescriptor is not a realistic proposition. Signing is also quite expensive unless you have AVX2, and will decimate circuit build performance. Protecting against Quantum Computer equipped active Man-In-The-Middle attacks is the least important thing to do in terms of user safety. By modifying the link handshake to incorporate a PQ key exchange algorithm with ephemeral keys as in the proposal, user data being generated right now will be protected from bulk decryption later, in the event of a Curve25519 break (probably by a large enough Quantum Computer), which is a far more realistic threat to be concerned about. -- Yawning Angel pgpd2rsvSvxx5.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] Quantum-safe Hybrid handshake for Tor
On Sat, 2 Jan 2016 17:18:56 -0800 Ryan Carboni wrote: > And yet the NSA is moving to prime numbers. So? In terms of prioritization, ensuring all existing traffic isn't subject to later decryption is far more important that defending against targeted active attacks that require hardware that doesn't exist yet. > A large public key isn't a very good reason to not adopt quantum-safe > crypto, it just means that it requires having the Tor project to be > able to scale to a larger degree. I suggest hash tables, a percentage > of which are pseudorandomly downloaded. Otherwise the Tor project > won't scale to 10x the relays ... even ignoring quantum cryptography. Nope. Every client needs to know the public key of every relay or we're worse off vs active attackers. To put numbers into things for the bandwidth/storage overhead for having SPHINCS256 keys for every relay, currently the full list of microdescriptors for a consensus is ~3.2 MiB, with 6960 relays. This is roughly 9.3 MiB of extra information that would need to be downloaded in terms directory information, and ~41 KiB per hop of extra traffic as part of the circuit build process. Additionally, without AVX2, signing is glacially slow, clocking in at ~200 ms on an Haswell i5. The same hardware does our existing ntor handshake in ~230 usec. Increasing the amount of work each hop needs to do to establish a circuit by 3 orders of magnitude to the point where a single core on a relatively modern processor can process 5 circuit creations/second would kill the Tor network. (I'm done arguing over this. If you think relays should have PQ signature based identity keys, then feel free to write a patch. I view other things as more important, and will focus my efforts elsewhere.) Regards, -- Yawning Angel pgpqMyparA0Gu.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] Quantum-safe Hybrid handshake for Tor
On Sun, 3 Jan 2016 04:16:17 -0500 grarpamp wrote: > http://safecurves.cr.yp.to/ > > Just another link. None of those algorithms will hold up to a quantum computer, and apart from for TLS (where we use the NIST curves) we already use "safe" Curve/Ed25519. So I don't know why you're bringing it up. This is discussion regarding how to prevent a total disaster in the event of a Curve25519 break. nb: Migrating to X448 would possibly hold up longer than Curve25519 would since it requires a bigger quantum computer. But performance isn't that great without using vectorization. > > Additionally, without AVX2, signing is glacially slow, clocking in > > at ~200 ms on an Haswell i5. The same hardware does our existing > > ntor handshake in ~230 usec. > > Haswell i5 seems to have AVX2, as do all Haswell's, > perhaps you refer to Ivy Bridge i5's which do not... Or, perhaps I meant exactly what I said, because the implementation I happened to benchmark (which I coincidentally, happened to write) does not use AVX2 (it doesn't, since it was written to be portable) and I wanted non-vectorized performance numbers (I did). I know the algorithm is faster when vectorized but that does little good for what I suspect are a substantial fraction of the relays. -- Yawning Angel pgpVHGynyC38h.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] Quantum-safe Hybrid handshake for Tor
(Note: Snipping liberally for brevity) On Mon, 4 Jan 2016 11:56:54 -0500 Zhenfei Zhang wrote: > 2. On NTRU vs NTRU-Prime vs R-LWE and others. > The QSH is modular designed to suite any quantum-safe encryption > algorithm. So we can chose any one we want for trail. And > furthermore, we can also hybrid, say ECC, NTRU and R-LWE, to give a > bit more confidence in case one of the quantum-safe encryption > algorithm turns out to be not quantum safe, or broken. Hybridizing all 3 probably will get somewhat expensive (though not prohibitively so), nickm and I have branches to thread the client side circuit build crypto which will help mask the performance penalty of this proposal in general (not yet merged, shouldn't require changes to your branch). > That been said, we chose NTRU for several reasons. NTRU is more > mature than R-LWE from our point o view. NTRU has a full spec, a > reference implementation, and is standardized by several bodies; > while for R-LWE, since it enables many interesting cryptographic > primitives, such as FHE, there has been many different parameter > proposals, which leads to some kind of confusion as to which one > should reference to. At the current time, if I had to pick one, I'd use the newhope variant of Peikert's KEM scheme (And in fact was going to amend the proposal to specify that as the Ring-LWE primitive). The BCNS proposal has gotten slightly more scrutiny, but it's slower, has larger keys, and provides a lower security level than newhope. > We are happy to roll out any above encryption algorithm as you see > fit. But our proposal is mainly about the QSH approach. I think the > best option for now is to buildin a QSH for Tor, with a flexible > API that allows us to switch between algorithms when fit. And for now > use any quantum-safe encryption algorithm that is ready to be used. > After all, any QS encryption is better than nothing. Agreed. I like the QSH design, though I still want to use FIPS 202 (SHA-3/SHAKE) instead of HMAC-SHA256/HKDF-SHA256, due to "Since we're changing things anyway, we may as well future proof here too". > 3. License > I am sorry I am not familiar with the license. But my general feeling > is that Security Innovation is willing to let Tor to use NTRU for > free. We just need to work out the suitable license to make this > happen. I'm glad to hear that. My main concern here is that if, say Debian Legal thinks that the existing FOSS patent wavier is insufficient to allow NTRU to be included in Debian packages till 2017, this will significantly hamper the relay side uptake of the safer primitives due to the Debian monoculture on our relays. I can do the Ring-LWE work, since the QSH primitive is modular so that there will be options for people that have more stringent license/patent policies than we do. If I were to prioritize handshake selection, I would lean towards NTRU + Ring-LWE, over NTRU, over Ring-LWE based on what the peer supports. > > As I recall, the product form parameter sets are extra encumbered. > > Apart from key/ciphertext size and a minor performance > > differential, is there any reason to not use one of the X9.98 > > parameter sets (Eg: EES613EP1) > > Yes we can use non-product form polynomials, if everyone agrees on it. > Non-product form polynomials will make key generation and decryption > a bit slower, but those cost are on the client side. It has no impact > on the load of server side. Client side for Tor is somewhat deceptive because Hidden Services act as the client when connecting to the Rdv point, so we do care about performance there too. I fully expect that the gains that we will get from separate work due to improved threading will pay for the CPU cost increases here, but I'll need to do some benchmarking to be certain. > > * "For 128 bits quantum security, use NTRU_EESS743EP1." should be > > "For 256 bits" (Section 2.3). > > NTRU_EESS743EP1 provides 256 classical security and 128 bits quantum > security. Please see > https://eprint.iacr.org/2015/708.pdf > for arguments of those security levels. Ah gotcha, I haven't seen that paper and I was going off the initial estimates, thanks for the clarification. Regards, -- Yawning Angel pgpP9Y2gM0JOm.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] Transparent proxying: automagically add firewall rules
On Mon, 11 Jan 2016 16:43:10 + Rene Bartsch wrote: > Hi, > > transparent proxying to TOR Hidden Services is a great feature of the > TOR daemon when it comes to other applications/protocols than HTTP > and surfing. It would also be great with privacy appliances (e.g. > Mailpile using TOR as secure SMTP transport channel). > > John Does have problems with such a setup because of the NAT firewall > rules. > > So I suggest the TOR daemon should automagically set the necessary > NAT-rules on Windows, Linux and BSD when "TransPort" and > "VirtualAddrNetworkIPv[4|6]" are configured in torrc. This is unlikely to happen because the "sensible automagic thing" will probably break on various configurations, and more practically, tor attempts to drop privileges as soon as possible leading it to be unable to alter or clean up said rules on HUP/exit. Others are free to disagree, patches will be evaluated if someone writes them. Regards, -- Yawning Angel pgp2yHXnYiOR_.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] ENGINE_get_default_ECDx missing?
On Mon, 18 Jan 2016 19:43:37 +0100 Gisle Vanem wrote: > Isn't OpenSSL 1.1.0 supported yet? Scratching head... We fix it when it breaks but it's not a high priority or something currently tested against. When 1.1.0 has a stable release, this will change, but people building against master or the pre-releases are currently on their own. Thanks for the patch though. Regards, -- Yawning Angel pgpasWyLTDBte.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] Entry/Exit node selection
On Mon, 18 Jan 2016 13:53:47 -0400
"Evan d'Entremont" wrote:
> Is there any reason why Tor doesn't select exit nodes which are as
> close as possible to the intended host?
The generic way to ask this question is "AS-aware path selection".
One big general issue is, "there is no accurate map of how ASes are
geographically distributed".
> If I connect to Tor and request a resource from a server on ISP A,
> would in not make sense to enforce an exit node also on ISP A, or if
> not, as close as possible?
Load balancing. Relay capacity is likely not distributed in a way that
matches intended desitnations.
> As well, entry guards should be as close as possible to the user,
> limiting the ability of others to log the connection.
This loses extremely quickly once you have adversaries that can force
ISPs to run relays ("You mean, we send a NSL to Comcast and we get to
be the Guard for all Tor users that are Comcast customers?").
Ditto load balancing concerns.
> In short, it's safer that only my ISP see a connection rather than my
> ISP, a backbone provider, the entry guard's ISP, etc. Systems like
> XKeyscore wouldn't even see the traffic in this case. It seems that
> selecting an exit country may actually be detrimental to anonymity by
> forcing traffic over the (monitored) internet backbone.
Hiding Tor use isn't part of Tor's threat model. The current situation
wrt e2e correlation and AS diversity is sub optimal, but the current
plan is to add link layer padding as a defense (Though it comes at a
~60% cost).
Regards,
--
Yawning Angel
pgpO62WxpcC58.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] Entry/Exit node selection
On Mon, 18 Jan 2016 14:26:04 -0800 Spencer wrote: > > > > Evan d'Entremont: > > ... select exit nodes ... > > > > It would be best if people could select their own path (: You can with the control port. Moving it to a first class feature would be a terrible idea for anyone that isn't a researcher because people will likely get the path selection horrifically wrong. Regards, -- Yawning Angel pgp8i36ArwBOJ.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] Is it possible to specify voluntary delays in my Tor client?
On Wed, 20 Jan 2016 08:15:48 + David Stainton wrote: > The Differences Between Onion Routing and Mix Networks > https://ritter.vg/blog-mix_and_onion_networks.html Not implemented yet in tor (see prop 254), but this is the current state of the art in link padding as a traffic analysis defense. http://arxiv.org/abs/1512.00524 This is follow up research from M. Juarez's GSOC project which prototyped the framework used when writing the paper and evaluating the various algorithms. Regards, -- Yawning Angel pgp5P4NZJRXsk.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] SyslogIdentityTag considered to be backported to 0.2.7?
On Thu, 21 Jan 2016 20:06:51 + nusenu wrote: > I like weasel's [1] SyslogIdentityTag feature that is available in > debian 0.2.7 packages only. > > The ticket [1] suggests that it will be included in tor 0.2.8.x > (milestone). Would you consider to backport it to 0.2.7 as well so > other platforms can make use of it before we see tor 0.2.8 (without > having to ask every package maintainer to maybe ship packages with > the patch applied)? The only thing that gets backports to stable releases are security and compatibility fixes. Regards, -- Yawning Angel pgpvwFQU9G7hh.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: obfs4proxy-0.0.6
Hello all, I just tagged obfs4proxy-0.0.6. There aren't many significant changes, and the internal changes primarily affect the client side initialization, so those of you that are perfectly content with obfs4proxy-0.0.5 can continue to use the existing version without issue. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.6.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.6.tar.xz.asc Changes in version 0.0.6 - 2016-01-25: - Delay transport factory initialization till after logging has been initialized. - Add a meek client implementation (WARNING: Does not support using a helper to normalize TLS signatures). The brave people that want to use it can do so as the "meek_lite" transport, with identical bridge lines to the real meek-client. This means "It's blatantly obvious that you're using a HTTPS client written in Go because the ClientHello is rather distinctive". The benefit is that it is a lot easier to package than meek-client + the external helper, and this can probably save binary size on things like Android. An example bridge line would be: Bridge meek_lite 0.0.2.0:1 url=https://meek-reflect.appspot.com/ front=www.google.com It has received moderate testing when I was on a business trip, and appears to function as intended, given the design constraints. There are minor internal API changes (which caused issues delaying the release) motivated by "meek's behavior is unlike most other transports" but I expect such things to be straight forward to those that actually hack on the code. Thanks to the person on Github for filing a pull request which saved me time debugging. Regards, -- Yawning Angel pgp65xew5gP_U.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] Introducing Snowflake (webrtc pt)
On Mon, 25 Jan 2016 14:34:42 -0800 Serene wrote: > Anyhow, if Snowflake seems like it would be useful / desired here, it > would be awesome if we had more help getting it stable, polished, > audited, deployable, etc... Neat. Yes, this will be useful. What are your plans for getting https://github.com/keroserene/go-webrtc to build completely in a deterministic manner? The several hours isn't per platform right? (The "easy way" is not going to cut it for distribution). What are your plans for actually getting the server side to scale well? Since you're using cgo you will run into Really Interesting behavior wrt OS threads as you try to increase concurrency. Regards, -- Yawning Angel pgpLU1pLkbv_I.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] Introducing Snowflake (webrtc pt)
On Mon, 25 Jan 2016 15:32:55 -0800 Serene wrote: [snip] > > What are your plans for actually getting the server side to scale > > well? Since you're using cgo you will run into Really Interesting > > behavior wrt OS threads as you try to increase concurrency. > > Right now, the server side is the same websocket relay from > flashproxy. Webrtc currently happens just between the client and > browser proxy - this already yields all the benefits listed above (as > we assume the volunteer proxy has no problem connecting to Tor) This seems sensible. > However, it might be worth having webrtc on both sides. We already > have prepared a webrtc server plugin, which the client plugin has > successfully connected to directly. To use a snowflake proxy in > between would require establishing two separate webrtc peerconnections > per circuit. Maybe that's worth doing - but I'm not sure about the > plan there, if we do decide to go that route. Ah that's what that was. If you don't use it then, you won't have lots of misery fighting with cgo's quirks. Regards, -- Yawning Angel pgpH3WhBnsvR9.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 not affected by recent openssl security advisories
On Thu, 28 Jan 2016 10:35:21 -0500 Nick Mathewson wrote: > Somebody always asks whether Tor is affected by each OpenSSL advisory, > so I'm sending this mail in order to get a URL to send people to. :) > > Here are today's advisories: >https://mta.openssl.org/pipermail/openssl-announce/2016-January/61.html > > With respect to the first ( "DH small subgroups (CVE-2016-0701)" ), > Tor is not affected because we set the SSL_OP_SINGLE_DH_USE() option. > We started setting this option back in Tor 0.1.1.9-alpha, back in > 2005. It's also worth noting that newer (0.2.7.x) versions of Tor should not be doing DHE except when talking to old versions of Tor, linked against old versions of OpenSSL as ECDH is both mandatory and preferred in the current stable series. All versions of OpenSSL that predate support for ECC have been EOLed and no longer receive security fixes, so if your system is using OpenSSL 0.9.8 (or 1.0.0 for that matter though it has ECC), you are strongly encouraged to upgrade to something that is being maintained. Regards, -- Yawning Angel pgpznz8AGqVM0.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 not affected by recent openssl security advisories
On Thu, 28 Jan 2016 18:05:51 +0100 Tim Kuijsten wrote: > > It's also worth noting that newer (0.2.7.x) versions of Tor should > > not be doing DHE except when talking to old versions of Tor, linked > > against old versions of OpenSSL as ECDH is both mandatory and > > preferred in the current stable series. > > Is ECDH currently mandatory or did you mean ECDHE? Yes. It uses ECDH with Ephemeral keys. Really, unless you vendor's OpenSSL library is doing something Really Silly, or is ancient, this will Do The Right Thing (TM). -- Yawning Angel [0]: Bow before your new NIST overlords, etc. pgpWk1gbZz6Dk.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] Quantum-safe Hybrid handshake for Tor
On Thu, 3 Mar 2016 16:33:42 + (UTC) lukep wrote: > Hi, > I'm trying to understand the hybrid protocol that's described here. > The server generates the parallel secret PAR_SEC or P and then > computes C = ENCRYPT( P | B | Y, QSPK); > The client decrypts C to get P and then uses it combination with the > ECC secret E: secret_input = E | P | QSPK | ID | PROTOID > > So E is secret, P is generated by the server, QSPK ID and PROTOID are > all public. So IF ECC is broken and IF the server has been > compromised (big IF's!) then everything is known. If the server is compromised, the client loses regardless of handshake mechanism because said compromised server has access to the plaintext. > I guess my point is that the client isnt contributing any secret > information to the quantum-safe part of KEY_SEED. Is that OK? Yes. I'd rather both sides contribute, but since `P | B | Y` is transmitted encrypted to a ephemeral key generated by the client, baring the "the server is compromised" case (which is irrelevant) the construct should hold. See RFC 4432, RFC 5246 7.4.7.1 for this sort of thing being done with RSA. Note: The Ring-LWE variant of this hybrid construct would fulfill the "both sides contribute material" clause (yay). Regards, -- Yawning Angel pgpcIxGIJ0_41.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
