Re: [tor-relays] Tiny computers (RPi-like) for exit nodes?
On Thu, 18 Aug 2016 11:50:33 -0600 Michael McConville <mm...@mykolab.com> wrote: > I forgot to mention all the crypto required, too. These boards don't > have crypto accelerators, so that's a big cost. What? ARMv8-A has hardware accelerated SHA(1/2), AES, and a carry-less multiply. As far as I am aware this still requires using OpenSSL 1.1.x (currently beta), and I don't remember off the top of my head if the code necessary to use newer OpenSSL was backported to pre 0.2.9.x. Regards, -- Yawning Angel pgpaOaNrGPCRk.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Any security tips on running a TOR relay?
On Thu, 4 Aug 2016 20:20:45 -0500 Tristan <supersluet...@gmail.com> wrote: > Any ideas what in-addr.arp is, and why the firewall would block it > even on allowed ports? I remember seeing this somewhere in the > Unbound config, but the IP isn't the same, and I didn't set up any of > the "local zones" in there. https://tools.ietf.org/html/rfc1033 Regards, -- Yawning Angel pgpDm9wLHW9uc.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] obfs4 - git how to ?
On Thu, 14 Jul 2016 14:47:27 +0100 Jonathan Roșca <ros...@tcd.ie> wrote: > chmod o+x /usr/bin/obfs4proxy lol no. > On 14 Jul 2016 10:55 a.m., "Petrusko" <petru...@riseup.net> wrote: > > > Trying to use obfs4 from git on a test bridge : > > > > With "root" user: > > cd /home/TEST > > git clone https://git.torproject.org/pluggable-transports/obfs4.git > > ln -s /home/TEST/obfs4/obfs4proxy /usr/bin/obfs4proxy Through out any of this, did it occur for you to look at the `README.md` file in the directory you cloned? To build: `go get git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy` To install: Copy `$GOPATH/bin/obfs4proxy` to a permanent location (Eg: `/usr/local/bin`) Regards, -- Yawning Angel pgprIqKr4egaS.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Darknet Shenanigans [was: suspicious "Relay127001" relays]
On Thu, 7 Jul 2016 07:29:04 +0200 Andreas Krey <a.k...@gmx.de> wrote: > On Wed, 06 Jul 2016 15:06:00 +, grarpamp wrote: > ... > > https://boingboing.net/2016/07/01/researchers-find-over-100-spyi.html > > Is there a way to make tor log connection attempts to any ports > on an hidden service address, independent of whether the port > actually has a HiddenServicePort? Not on any reasonable log config as is (I didn't check unreasonable ones like the debug one.). Patch `rend_service_set_connection_addr_port()` in rendservice.c if you want this behavior. Note that it will already log connection attempts to unknown ports by default (to the `LD_REND` domain). There's also an option (disabled by default) to tear down circuits that attempt to open streams to unknown ports, but that won't stop anyone moderately dedicated, just make things take more time. > > All quite expected and well known ever since the > > dawn of overlay networks. Same with the Internet. > > Also, wasn't there a change that made discovery impossible? Prop 224 will fix it, but that hasn't been fully implemented yet. Using `stealth` HS auth in the mean time frustrates this. -- Yawning Angel pgpojBDIhEIhA.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 84 exits (growing..)
On Sat, 7 May 2016 20:38:08 +0200 Toralf Förster <toralf.foers...@gmx.de> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 05/07/2016 08:27 PM, Yawning Angel wrote: > > Apart from accounts that have grandfathered free bandwidth, where > > is this mentioned? > > > from https://www.digitalocean.com/legal/terms/ : > > Notwithstanding the foregoing, Subscribers of Grandfathered Accounts > must NOT: (i) run Torrents for download or Seed Servers, TOR, ... Yes and? (https://en.wiktionary.org/wiki/apart_from) -- Yawning Angel pgptUZJJyQNVp.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 84 exits (growing..) (was: 68 new exits)
On Sat, 7 May 2016 07:46:31 -0500 Tristan <supersluet...@gmail.com> wrote: > Strange that some of the relays are running on Digital Ocean. Running > a Tor relay of any kind is against their AUP. That's news to me. https://www.digitalocean.com/legal/terms/ Apart from accounts that have grandfathered free bandwidth, where is this mentioned? Regards, -- Yawning Angel pgpHHhOs7T6BB.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Using your own Relay as Entry Node
On Thu, 14 Apr 2016 21:38:15 + fr33d0m4all <fr33d0m4...@riseup.net> wrote: > And about using it as a SOCKS proxy to enter the Tor network? Do the > same considerations apply or is it even worse to use a relay as a > SOCKS proxy? This is horrible and should *NEVER* be done, assuming any network not physically controlled by you is between you and the SOCKS proxy server[0], simply based on the request (and authentication if you chose to use such things) being in the clear. Regards, -- Yawning Angel [0]: So, SOCKS over an internal network to a VM/magical anonymity box may be ok (depending on your threat model). SOCKS to a VPS somewhere is essentially always a bad idea. pgpBZny5QoiyR.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] First (positive) experiences with a Tor Relay on Raspberry Pi3
On Sun, 10 Apr 2016 21:48:06 + fr33d0m4all <fr33d0m4...@riseup.net> wrote: [snip] > Thank you very much Yawning for the news, I didn't know about that! > I'm running stable 0.2.7.6 from the Jessie repo, I hope the new > ARMv8-AES-enabled version will be out "soon" in the repo (but I don't > think it will happen soon, at least for the stable branch, right?) 0.2.8.x will be in a stable repo shortly. However as far as I know, we do not separately build OpenSSL packages (and the 1.1.0 series is still in pre-release state), so you will either need to be patient, or wait the 15 years it takes for Debian to update anything[0]. > BTW, I can't offer more than 14 Mbps, which are about 75% of my upload > BW, so I can live for a while without AES acceleration :) Well, crypto being more efficient would reduce load on the box and lessen the likelyhood of it catching fire. :P Realistically I'd wait till there at least is a formal OpenSSL 1.1.0 release before using it for more than testing. But I figured it would be good to note that the RasPi3 will benefit. Regards, -- Yawning Angel [0]: Obvious hyperbole is obvious. pgphcbzmKfNfn.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] First (positive) experiences with a Tor Relay on Raspberry Pi3
On Sun, 10 Apr 2016 17:52:20 + fr33d0m4all <fr33d0m4...@riseup.net> wrote: > I've just moved my Tor relay installation from my alix1.c embedded > system (500Mhz CPU with 256Mb ram) which was able to offer only 4Mbps > (100% CPU utilization) to a new Raspberry Pi3 (quad-core 1.2Ghz 64-bit > cpu with 1 GB ram). Some days ago I've seen some messages on the ML > about Pi2 performance (if I remember well) and I'd like to share my > first experiences with Pi3. I have only 20Mbps connection in the > uplink direction, so I'm offering about 15Mbps for Tor relay and I've > just seen that it is able to offer 14Mbps with 40% of a single core > utilization.. In conclusion, I think that a single relay on Pi3 can > offer about 30-40 Mbps, and if you run 4 tor relays on the same Pi3 > you can offer more than 100Mbps which is definitely not bad for such a > small system. The only drawback is that you need to find a good way > for keeping it cold, since after 1 hour of 1 core at 100% I've reached > about 70°C with heatsinks on the CPU. If you build tor against OpenSSL 1.1 on that target you will get a massive increase in performance due to support for the ARMv8 hardware AES acceleration. This requires 0.2.8.x from the maint-028 branch (or master if you're brave) since I recently fixed tor (again) to compile with this version of the library, but the changes will be in the next 0.2.8 release candidate. Regards, -- Yawning Angel pgpEa2HfauO8D.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Suggestion to make Tor usage more disguised
On Sat, 16 Jan 2016 15:02:18 +0100 Raúl Martínez <r...@rme.li> wrote: > Most of people are uneducated about what is Tor and what is used for. > That can lead to trouble. > > I have used pluggable transports but they are too slow (50KB/s) So run your own fast bridge? It's relatively easy, and I assume that's the main reason why it's slow since all of the non-meek transports are relatively lightweight. Anyway, I don't see the point of this. People that care about masking Tor use should use Bridges with pluggable transports and expect to take a performance hit for the extra obfuscation. People that do not use such things should assume that it is trivial to figure out if they are using Tor. It's worth noting that the obfuscation isn't perfect and people should assume that it's possible to figure out if they're using Tor if they are being actively targeted as well, but the various transports do raise the bar by varying amounts. Apart from the cases involving Bridges and PTs, explicitly hiding Tor use is not in Tor's threat model either (and probably can't be without a major re-design of how the network works, which is unlikely to happen). Regards, -- Yawning Angel pgpyJokTtZeFO.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why is Tor trying to check the wrong ORPort/DirPort addresses?
On Fri, 8 Jan 2016 23:39:59 +1100 David Tomic <da...@tomic.com.au> wrote: > Is there something incredibly simple which I'm simply just not doing > properly, or is there possibly more going on here than first meets > the eye? Set the `Address` option in each torrc, otherwise tor will guess. -- Yawning Angel pgpor_gXvqcb1.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Crash and obfs error
On Thu, 10 Dec 2015 01:26:41 + Geoff Down <geoffd...@fastmail.net> wrote: [snip[ > Also, on restarting Tor with Obfsproxy already running, I got > Dec 09 14:14:43.000 [warn] Server managed proxy encountered a method > error. (obfs3 Could not set up listener (0.0.0.0:xx) for 'obfs3' > (Address already in use).) > Dec 09 14:14:43.000 [warn] Managed proxy at '/usr/bin/obfsproxy' > failed the configuration protocol and will be destroyed. > does this mean that Tor is running without obfsproxy now, and I need > to stop both and restart? Yes. For what it's worth, newer versions of tor (0.2.7.x) has code to prevent this from happening on Linux systems by using prctl to force the kernel into cleaning up children with SIGTERM. obfs4proxy also has the same prctl() trickery and additional code for non-Linux systems so it can self-terminate on parent exit. > It's quite annoying that Tor doesn't remember its auto-picked port, > and I have to change the port-forwarding rule every time. This should get persisted in the state file. Regards, -- Yawning Angel pgp29dnnHV2KV.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bots, love 'em or hate 'em?
On Tue, 8 Sep 2015 02:03:07 -0400 Roger Dingledine <a...@mit.edu> wrote: > On Mon, Sep 07, 2015 at 10:30:38AM -0400, > starlight.201...@binnacle.cx wrote: > > This is curious: Appears a large number of Tor > > client-bots have set > > > > UseEntryGuards 0 > > > > From current relays that have never had the guard flag: > > > > extra-info moep DA8C1123CDB3ACD3B36CD7E7CEFBEA685DED2276 > > entry-ips > > us=360,de=296,fr=232,it=192,es=160,jp=104,ru=104,br=96,ir=96. . . > > These are likely clients using a version from before we introduced > directory guards. So they probably use entry guards like normal, and > they just choose relays at random to fetch their directory info. > > This is why relays report dirreq-v3-reqs lines (number of v3 consensus > requests) in their extra-info descriptors too, and not just total > connection counts. This does present us with an opportunity to gain an actual estimate for the number of botnet clients since there's a way to distinguish them from normal users. Not sure if we'd require actual metrics or if this is just a matter of analysis. Regards, -- Yawning Angel pgpuOm6rLPfw_.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Guidelines for lifetime of a bridge?
On Mon, 17 Aug 2015 09:13:21 +0100 Tim Sammut t...@teamsammut.com wrote: With possible config changes in mind, is it best to use ports 80 and 443 for pluggable transports? It'd be nice if more bridges used ports 1024, yes. IIRC the bridgeDB prefers to hand out at least one bridge with port 80 or 443 open. Right now the bridge runs obfs3 on 80/tcp and obfs4 on 443/tcp. Is that still a desirable setup (despite having to run bits as root)? You don't need to run obfs4proxy as root assuming you are on a modern linux system, since obfs4proxy works correctly with capabilities. # setcap 'cap_net_bind_service=+ep' /usr/local/bin/obfs4proxy Note, this will let any user on the system executing the obfs4proxy binary to bind to privileged ports, and must be done each time the binary is modified in any way (moved, upgraded, etc). IIRC on Debian an extra package needs to be installed to get the setcap executable, but I don't remember what it is off the top of my head. For more information see setcap(8) and capabilities(7). Regards, -- Yawning Angel pgp4AU2Cj4baV.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How to Run High Capacity Tor Relays
On Tue, 4 Aug 2015 00:25:56 +1000 teor teor2...@gmail.com wrote: On 3 Aug 2015, at 22:19 , Ben Serebin b...@reefsolutions.com wrote: Windows has a very significant percentage of the server market share, and more attention should be focused on this part of the Tor Server development. Right now, it’s a very complicated install/config on a Windows OS which is disappointing and prevents greater adoption (the end goal of Tor is greater adoption to increase privacy). Windows sysadmin aren’t used to tweaking config files and the posted documentation isn’t good (repeated requested for me to update have gone unanswered). What are the Trac ticket numbers of these documentation change requests? (Or are they on the wiki? Anyone can modify the wiki.) If donating to the project to promote Tor on Windows existed, I would. Please log a Trac ticket for this - it sounds like an excellent idea. Hm, doesn't running good relays on Windows (especially high capacity ones) require that we finish off the IOCP related work? IIRC that's what the bufferevent code was supposed to be for, but it hasn't been maintained in a while, and is known to be buggy. Getting time/funding to work on that if my recollection is correct would be great I think. Regards, -- Yawning Angel pgpXT0PaEG1Tg.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor 2.6.10 fails to generate fresh DH Keys
On Sat, 01 Aug 2015 13:06:55 -0400 starlight.201...@binnacle.cx wrote: Bug: Assertion r == 0 failed in crypto_generate_dynamic_dh_modulus at ../src/common/crypto.c:1788. Looks like you have DynamicDHGroups enabled in your torrc file. Yes. Don't use it. It's kind of pointless since it only affects TLS cyphersuites that shouldn't get negotiated in the first place. This is interesting because the recent LogJam research indicates the NSA has probably broken commonly used 1024 bit DH groups, which suggests turning on this parameter. Sigh. There's no point because any sensible build of Tor will negotiate ECDHE over DHE when doing the TLS handshake (which is the only thing this option applies to). Note: any sensible build basically is anything moderately recent, linked against OpenSSL = 1.0.0 (If your vendor OpenSSL is older than that, 0.2.7.2-alpha and later will refuse to build, so users may as well start thinking of a migration path.). However it was disabled by default some time ago for anti-fingerprinting reasons: https://trac.torproject.org/projects/tor/ticket/5598 The feature is flat out deprecated in 0.2.7.1-alpha and later, in the The code that implemented it was removed sense of deprecated. https://trac.torproject.org/projects/tor/ticket/13736 AND, it's probably a moot issue now that Ntor handshakes (elliptic curve) have overtaken older RSA connections. This has nothing to do with TAP vs ntor, and only affects TLS. -- Yawning Angel pgpay0pHTe22G.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Very unbalanced in/out connection ratio
On Tue, 28 Jul 2015 09:04:44 +0200 mattia sowd...@autistici.org wrote: I've been running a middle relay [1] for months and I have always noticed an unbalance between incoming and outgoing connections (monitored through arm). The incoming connections were always in between 0-10% more than the outgoing ones. This morning though the unbalance has reached so far unseen levels: arm reports more than 2500 incoming connections while outgoing are little more than 200. Is this normal and, if so, why? Your relay has the HSDir flag, so most likely what happened is that you became one of the HSDirs for a popular hidden service (use your imagination as to which one, there's a few that cause a lot of traffic). I wouldn't worry about it that much. Regards, -- Yawning Angel pgpXC4cMYXbRp.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Giving away some pre-warmed relay keys for adoption
On Mon, 27 Jul 2015 11:14:00 -0400 Paul Syverson paul.syver...@nrl.navy.mil wrote: I've been following this thread but haven't had time (and won't for several days at least) to formulate a thorough thoughtful response, but your statements are too absolute and without qualification. I used strong wording because there's a lot of thought/vetting that should go into doing something like this safely, though in hindsight, it probably was overly strong. That said [snip] Let's assume purely for simplicity that the transfer can be done in a secure fashion. Then if, for example, someone transferred keys to long-known trusted persons w/in the Tor community (say some of the dir-auths and others at similar levels of trust) in a way that (a) actually diminished the network concentration of trust among people by spreading his family to others where the result is more flat, and (b) paid attention to AS, country (by Geo-IP), etc. so that neither AS nor country changed. This should probably be fine. I think the trust component here is the biggest thing to worry about. [snip] There are probably other scenarios where this would be an OK action. And it's not just a security/performance trade-off. Having those relays just disappear reduces the diversity and capacity of the network, which has security implications too. But by design: a) The relays will move network location (unless the new operator picks the same data centers) therefore, the consensus weight should be re-measured. (To the peanut gallery, yes know the bwauths are held together by ducttape, string, chewing gum, and occult animal sacrifices. We're currently migrating from chicken based rituals to goat based ones, and assuming the bwauths work is probably about as reasonable as assume enough vetting or assume secure key transfer.) If b from your list is done, then this can be skipped. b) The operator has changed (the network/code itself doesn't and can't realistically know how much vetting the new operator has had), therefore, it flags should be treated as if the relay was brand new. If there was a way to objectively quantify trust, then I can see short-circuiting the various flag assignment delays, but, that appears to be an open research problem. Essentially, if the person running them changes, and the network location changes (possibly for the better, diversity is good after all), what's the difference between someone just spinning up new replacement high capacity relays that isn't (if the person is 'trusted enough *waves hand*', it's sort of ok to bypass delays in letting the relays do certain things that are added for security reasons). Here is another example wrt another factor. (If I'm going on too long here and losing you, skip the rest of this paragraph.) Someone could be maintaining several relays reasonably well but realize that their ability to securely maintain them is going to diminish slightly for some reason, still probably keeping them among the upper half of relays wrt security practice and circumstance. However, they realize that they can securely transfer authority over those relays to people who are both more trusted/reputed w/in the Tor community and in a better position to maintain their security going forward. In that case, they would be improving the security of the network by (securely) handing over the private keys than by continuing to maintain the relays themselves. Sure. I can see this as well, though I think the same counterargument applies. It is fine to note that this is something that could only make sense if done carefully. But claiming that the transfer of authority over private keys from on person to another must always be irresponsible diminishes the value of your primary point by overstating the argument. I'm not totally convinced, but I don't run a DirAuth, and it's up to each DirAuth operator on what to do. Apart from a short term decrease in network capacity/diversity, I see spinning up new relays as an equally good alternative here (with enough prior notice to teardown, even the current bwauths will get around to measuring things, assuming the chicken entrails are spread correctly), without all the tricky issues of secure data transfer and trust. Paranoid regards, -- Yawning Angel pgphnnCkQrsef.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Giving away some pre-warmed relay keys for adoption
On Sun, 26 Jul 2015 07:13:44 +0500 Roman Mamedov r...@romanrm.net wrote: Either way you won't do much damage even if any of this ends up being false, as the consensus weight and the stable status will drop more rapidly than they are gathered if your node can't maintain them. Giving away the identity keys for high capacity relays that actual users are using as Guards seems irresponsible at best, and downright malicious assuming a realistic threat model for the Tor Network as a whole. Yes, in an ideal world the bwauths will scan new relays faster. Meanwhile in reality the outcome is often [1]. Orthogonal problem, and it's being worked on under an OTF Fellowship. A fun task for someone who likes messing with consensus documents and descriptors would be to write a script to measure IP address churn for relays while the relay identity remains constant (either legitimately eg: being on a dynamic IP, person had to move the rack the relay was on, or through key compromise/derp). I do this extensively on my relays, as one VPS or dedicated server expires, gets terminated or canceled for various reasons, a different one takes its place, inheriting the same identity. If I had to always wait for new relays to spin up from scratch in each case, a lot of the time I probably wouldn't even bother. While the bwauth delay is unfortunate (which is why it's being worked on), the delay in assigning Stable/Guard and HSDir are for user safety. I'm somewhat torn on the whole key pinning thing, because I think an individual operator moving their relay around is sort of ok (though in an ideal world the consensus weight should get reset and rapidly re-measured), but giving away the private component of a relay's identity key is putting users at risk, and is behavior that should be discouraged if not outright prohibited if possible (and key pinning would be a heavy handed way to rule out this sort of stupidity). I personally care less about the absolute size of the Tor network, and if it's a choice between user's Guards changing ownership, and a smaller Tor network I will pick the latter every single time. Running 20 relays in a declared family at the moment, together comprising about 1.8% of aggregate Tor bandwidth, however due to financial reasons I will have to shut down most of these over the coming weeks and months; so I see little difference if the next machine inheriting a particular identity this time will be managed and paid for by someone else and not by me. Just throwing these away seemed like a waste. If I have to write a script to figure out the fingerprints of your relays just to keep users safe I will. I have 3 million other things I rather be doing, but keeping the user safe from the bad guys (no matter how good their intentions) is the most important thing I could be doing. Regards, -- Yawning Angel ps: I'm mostly done with this. If Roger or someone else wants to comment and overrule what I say that's up to them. pgpFiWngEpry3.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] pinning relay keys to IPs (or not)
On Sun, 26 Jul 2015 21:09:13 +0300 s7r s...@sky-ip.org wrote: We need to confirm this: is a relay holding TLS connections to the majority of the other relays? This is another metrics needed thing. In general, at any given time, any relay should be prepared to be able to open or accept a connection to any other relay/bridge, because circuit failures are extremely unhealthy for the network and anonymity. As the number of users tends towards infinity, the number of concurrent TLS connections on a given relay will increase till it caps out at 1 per every other node in the network (plus destinations if Exit, clients if Guard), because the path selection will work out such that at least one user will pick a path that involves every possible relay pair. So in a magical more anonymous future, yes, relays will hold TLS connections to the majority of other relays. The growth won't be linear since the path selection is based on consensus weight, so having nifty metrics to graph trends here will be useful, since as you noted in your example we aren't at that point yet. On a relay with over 100 days of uptime (middle relay) Stable, HSDir, etc. I have (# netstat -a | wc -l) 1942 connections. Another one, with less uptime just has 548 connections. These relays have a small consensus weight. A guard with good consensus weight has much more, but anyway under the ~6400 (total number of relays in the consensus). There are consumer grade routers that would not be able to sustain the small example due to NAT session tracking limitations. This is sad, relays behind such devices will do bad things to the network. See https://trac.torproject.org/projects/tor/ticket/15482#comment:26 and the linked tor.stackexchange.com question, and the follow up discussion for practical issues caused by such devices. Regards, -- Yawning Angel pgpcciOfZ2l9G.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Giving away some pre-warmed relay keys for adoption
On Sat, 25 Jul 2015 23:40:10 +0500 Roman Mamedov r...@romanrm.net wrote: If anyone is planning to spin up a new VM or dedi to run a Tor relay and want it to be put instantly into good use (without wasting couple of weeks to a month for the whole unmeasured relay/measured/guard/stable cycle to complete) or if you are having trouble with your current relay being measured properly, in a few days I'm considering to give away several fingerprints+keys from my relays that I will be shutting down. What are the fingerprints so they can be rejected by the DirAuths? Regards, -- Yawning Angel pgprP8lFKaKfa.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Giving away some pre-warmed relay keys for adoption
On Sun, 26 Jul 2015 05:32:17 +0500 Roman Mamedov r...@romanrm.net wrote: On Sat, 25 Jul 2015 19:47:23 + isis i...@torproject.org wrote: I could take those backdoored^Wpre-warmed keys and put them to good use! Hello, Mkay, I'll get in touch in a few days. As for other repliers, I would not mind explaining my reasoning in more detail, if you have any specific questions or more articulated objections that a knee-jerk ban it or lolz reactions. What was knee-jerk about my response? The relay identity key is sensitive cryptographic material. Sharing it means the private key is compromised and is an attempt to subvert: * The bandwidth scanning process. The consensus weight is the relay's capacity relative to other nodes in the network which will change and should be reset if the location of the relay changes. Yes, in an ideal world the bwauths will scan new relays faster. But that's orthogonal to the need to reset/remeasure on IP address change. * The flag assignment process. A random person should not get the Guard or Stable flag quickly. The only thing a compromised relay should be used for is as a middle node and never a HSDir, so the correct behavior on the DirAuth side is to never assign the Valid flag to said relays. A fun task for someone who likes messing with consensus documents and descriptors would be to write a script to measure IP address churn for relays while the relay identity remains constant (either legitimately eg: being on a dynamic IP, person had to move the rack the relay was on, or through key compromise/derp). I'm of the opinion that it may be worth adding code to pin relay identities to IP addresses on the DirAuth side so that consensus weight and flag assignment gets totally reset if the ORPort IP changes, but if there's too much churn already it may cause more trouble than it's worth. Regards, -- Yawning Angel pgpp5HzUsPwa3.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Relays behind NATs (Was Re: unflagged BAD EXIT nodes)
On Sat, 4 Jul 2015 19:34:45 -0400 Ben Serebin b...@reefsolutions.com wrote: I'll hijack the response I'm a sysadmin, an unloved Windows one. My unwanted $0.02 are: - Windows installer (omg, Windows, the evil one which if you really want greater adoption is the answer! Oh smokes, someone said it! Ignoring this, not a platform I use or particularly care about, etc. - change the architecture so running behind nat works (this is probably the #1 limit factor for increasing relays). Every tom, dick, and harry could then add bandwidth via every internet circuit. It would be insane! Running relays behind NATs does work, you either need to setup port forwarding manually or provide a tor-fw-helper executable, with the former being massively preferable. tor-fw-helper isn't being distributed/built at all despite having had a portable rewrite (Check my github repo), instead of the C code that depends on a bunch of sketchy library code (included in the tor source tree), because: a) A lot of uPnP/NAT-PMP implementations on the router side are utterly horrific, and will crash if you look at them funny. b) Playing tech support for people that encounter a is not something I can personally do, and probably neither the support team. c) A person that can't figure out port forwarding probably should not be running a relay in the first place. An important thing to consider here is that, beyond bandwidth relay uptime and stability are also important considerations, which is not something usually obtainable from someone's home computer (eg: people turning it off at night). If by this you mean, make relays work from behind NATs without port forwarding in any shape or form that's a far trickier prospect. It's important that every relay can talk to every other relay, and TCP NAT traversal when both boxes are behind NATs requires a intermediary of some sort (See: http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf for a reasonable intro to how this works[0]). Regards, -- Yawning Angel [0]: Yes, the paper is old. It's the precursor research to ICE used by WebRTC. pgpKtYLS91sY3.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] de-centralised bad exit list files - a bad and/or naive idea ?
On Fri, 03 Jul 2015 08:17:00 -0700 Seth l...@sysfu.com wrote: On Fri, 03 Jul 2015 04:27:50 -0700, Toralf Förster toralf.foers...@gmx.de wrote: Reading [tor-relays] unflagged BAD EXIT nodes /me wonders, such a feature would makes sense. Maybe. The fundamental problems here are: * This reduces users anonymity, in that any modifications to the path selection behavior will make a given user behave differently from others, thus reducing their anonymity set from all Tor users to all Tor users that happen to use an identical configuration. The more restrictive a given user chooses to be about what Exits they allow, the more severe the reduction. * The maintainer of such a list can do a lot of damage (partitioning attacks, serving unique lists to each people). The extreme example would be along the lines of serving out lists that BadExit everything but adversary controlled Exits, or adversary observable exits. * How does one establish list-maintainer trust. While the methodology of the research that went into this appears solid, and the person appears to have the userbase's best interests in mind, it's hard to replicate. At a more basic level, I personally would rather see things like the badonions honeypot code integrated into something like phw's exitmap (patches accepted), and the BadExit-ing procedure improved substantially. Both of these things would be good places for volunteers to step up, and I think would be more fruitful in the long run. Technically this could yield to a ./torrc.d config directory, where tor users could store the (regular updated) list/s they do trusts. That would be nice, right now copying in the fingerprints of dozens of exit nodes into torrc is downright painful, especially since they can't be listed on their own lines. The ability to use nginx style include statements in torrc would also be helpful, that way values like 'ExitNodes' could be maintained in a separate file. You can kind of do this with a `--defaults-torrc` file and a separate file (probably autogenerated) containing all your other things. Or start Tor with `DisableNetwork` set, and use the control port to load your tinfoil hattery. Regards, -- Yawning Angel pgpAqJK4TjJkY.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge Usage and Setup
On Sun, 7 Jun 2015 12:31:52 +0200 tor-server-crea...@use.startmail.com wrote: I want to investigate why obfs4 is nearly never used. hi, may you want to have a look into tails bug #9268 adressing some obfs issue You mean, a Tails issue that happens to affect obfs4 since it likes to write large-ish packets, and what may be a Linux kernel issue that possibly makes the PLPMTUD code not that great. I have a packet capture that I need to go over but, since it is tcpdump output from a terminal and not a pcap file I've been putting it off, but the fact that TCP/IP breaks when write calls are done when the system is breaking PMTUD is not an obfs4 issue. In sane environments where PMTUD works, obfs4 has no issues with shorter than normal MSS. Regards, -- Yawning Angel pgpdutIpIar2D.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge Usage and Setup
On Tue, 2 Jun 2015 05:28:07 + isis i...@torproject.org wrote: [snip] Somehow, possibly due to one of the above-mentioned bugs, your tor and BridgeDB both seem to think that you're *only* listening on IPv4… so I'm a bit confused by what netstat is telling you… It's a Linux-ism. Binding to [::] will bind to both IPv4 and IPv6. It's initially confusing behavior, but harmless/useful (in this case more useful than anything else). I don't think I'll change this, though I could. I can put my bridge line into TBB and try and use it for obfs4; seems to work. But actually finding that bridge line wasn't straightforward (cat /var/lib/tor/pt_state/obfs4_bridgeline.txt and then edit the fields, right?) And it doesn't help for obfs3. Would it be easier, perhaps, if obfs4proxy were to also put your obfs3 (and/or scramblesuit) bridge lines into that file? (I thought it already did this, but I must be wrong.) You had to edit it? The bridge line file only dumps the obfs4 bridge line because it's the transport with PT generated arguments (well, Dust2 will have them, but that's not merged yet). The missing information that I have as fill this in with the correct values in there aren't provided to PTs at all (Eg: The fingerprint, and the inbound IP address). The fingerprint could be provided to PTs, the inbound IP address probably won't ever be because Tor doesn't know it at PT init time, and our code for guessing it needs a lot of love. [snip] I agree that all of the FAQ-ish questions you've just mentioned should be somewhere, easily accessible, on the website. I've created ticket #16261 for updating the Running a Bridge portion of the bridges.html page, [3] but I'm totally open to suggestions if people think the documentation should go into the FAQ page, or on a wiki page (or link to a wiki page, so that it's easier for community members to contribute tips and ideas), or somewhere else. mrphs wrote up this a while back: https://tor.stackexchange.com/questions/6370/how-to-run-an-obfs4-bridge Regards, -- Yawning Angel pgpBru_80teAv.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Enabling obfs4 and obfs3 on 80 and 443
On Tue, 05 May 2015 13:51:34 +0100 R-one r...@cryptoisimportantto.me wrote: [snip] This didn't work -- obfs4 complained that 443 was in use (is that because I had previously set it for ORPort?). So, for now, I have set obfs4 to a random high port. I will admit to being pretty confused about the recommended bridge setting for ORPort and the obfs ports (and what ExtORPort does differently). Does anyone have a recommendation for what I should do? Do I need to upgrade to tor 0.2.5? ORPort should be sent to something random, that is externally reachable and not in use by anything else. ExtORPort should be set to auto, it only listens on the loopback interface, so it doesn't need external reachability. The obfs ports can be unset (No ServerTransportListenAddr line) in which case they will be random, or set to specific ports to attempt to bypass naive attempts at protocol whitelisting. You need to upgrade to tor 0.2.5.x or later to be a useful obfs4 bridge period because Bridges running 0.2.4.x will publish broken bridge configurations to BridgeDB, and will not ever get served to users. (Yes, tor should log a warning whenever such situations occur, see #13202 for people shooting that idea down when I first brought it up a long time ago.) No idea about the port already in use thing. Check the processes on the system to see if you have a defunct obfs4proxy instance hanging around (obfs4proxy 0.0.5 makes this less likely to happen). Regards, -- Yawning Angel pgpcJKGqTuM_P.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] HW-Accelerated OpenSSL Tor not playing nicely.
On Sat, 02 May 2015 12:10:33 -0400 12xBTM 12x...@gmail.com wrote: So, I deleted the /usr/local/ssl/ folder and went from there. I got the sudo make test going again, and it failed D: . So the last thing remains: How do I get/install that patch that supposedly corrects this? ... Quoting from the README file: Note that OpenSSL's cryptodev implementation is outdated, and there are issues with it. For that we recommend to use the patches below, that we have provided to the openssl project. http://... You're making it sound as if the patches are on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'. Anyway... * I haven't bothered to check if the patches apply cleanly, only that they weren't ever merged. Shouldn't be that hard to fix the patches if they've rotted. * According to one of the writeups linked, in 2013 cryptdev wasn't exposing a CTR-AES EVP engine. If this is still the case, the bulk of tor's AES calls will not benefit from the acceleration (Skimming the cryptdev code quickly, this would ultimately be a kernel issue). * The SHA acceleration will only help TLS, because the bulk of the SHA calls in tor don't use the EVP interface (For good reasons in the case of SHA1, and it's a good idea, someone should do it reasons for SHA256). I'd expect in a lot of cases that the gains would be fairly minimal anyway, since using hardware acceleration with this configuration requires a syscall. if there's a better way to go about having HW-accelerated crypto for Tor (excluding Intel aes-ni), please let me know. Instead of some garbage TI part, use something that supports ARM-v8's AES, SHA1, SHA256, and VMULL instructions. Regards, -- Yawning Angel pgp0uhdF2rE_Y.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Installing obfs4 on Raspberry Pi bridge
On Thu, 23 Apr 2015 19:53:55 + jchase jch...@riseup.net wrote: Hello, When I run $ go get git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy $ sudo cp $GOPATH/bin/obfs4proxy /usr/local/bin on a laptop running linuxmint/ubuntu it produces a nice binary executable. Unfortunately it doesn't work to copy it to the Pi2, because it's not an ARM binary. When I run the same script on the Pi2 I get the following error messages: go get git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy # git.torproject.org/pluggable-transports/obfs4.git/common/ntor /usr/lib/go/src/pkg/git.torproject.org/pluggable-transports/obfs4.git/common/ntor/ntor.go:272: undefined: sha256.Sum256 [snip] Any idea how I can get it cleanly on a Pi2? This is covered in the README.md: * Go 1.2.0 or later. Prior versions of Go (Eg: 1.0.2) are missing certain important parts of the runtime library like a SHA256 implementation. Go 1.2 was released on December 1, 2013, so I'm not particularly inclined to support older versions, especially since it means re-implementing parts of the standard runtime library. Regards, -- Yawning Angel pgpsGaT__LdHI.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Installing obfs4 on Raspberry Pi bridge
On Thu, 16 Apr 2015 18:37:10 +
jchase jch...@riseup.net wrote:
Hello,
When I run either ./obfs4proxy or obfs4proxy.go I get:
./obfs4proxy: line 1: /bin: Is a directory
./obfs4proxy: line 2: syntax error near unexpected token `('
./obfs4proxy: line 2: ` * Copyright (c) 2014-2015, Yawning Angel
yawning at torproject dot org'
Errr, that's not going to work, because that's the raw source code and
not a compiled binary.
So you have a line somewhere in your torrc that says something that
looks like:
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
What does /usr/bin/obfs4proxy (in my example, fix the paths as
appropriate say), and is /usr/bin/obfs4proxy an actual ARM binary?
Regards,
--
Yawning Angel
pgp_L5Popsgvq.pgp
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Installing obfs4 on Raspberry Pi bridge
On Sun, 12 Apr 2015 17:43:55 +
jchase jch...@riseup.net wrote:
Hello,
Thanks to you I have tor 0.2.5.11 running on a Raspberry Pi2 and obfs4
installed from git. I have good news and bad news.
The largest problem is that I get the warning could not launch
managed proxy executable at '/path/obfs4proxy'('Permission denied')
In the past this used to be a problem with apparmor, but apparmor
isn't installed. Any idea where I can start looking for a solution?
Here are a couple of details and small problems:
I didn't install obfs4 directly (due to problems), but installed it to
another laptop and copied it to the Pi2 using scp.
Oh dear. What happens when you run the obfs4proxy executable in a
shell directly (on the pi2)?
It should look something like:
$ ./obfs4proxy
2015/04/12 20:13:02 [ERROR]: obfs4proxy - must be run as a managed
transport
If not, what does 'file /path/obfs4proxy' say?
Regards,
--
Yawning Angel
pgpfSUWdONl0s.pgp
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Installing obfs4 on Raspberry Pi bridge
On Mon, 30 Mar 2015 01:02:25 +0300 s7r s...@sky-ip.org wrote: We currently do not have armhf or armel packages for obfs4proxy in deb.torproject.org, but Yawning (CC'ed) will let us know when he has time how we can build obfs4proxy from git on Raspbian. Hmm, wonder why there aren't new packages. IIRC there were issues with building the debian ones on their arm build environment a while ago due to some of the unit tests taking too long and timing out, but I though I worked around that. If it's the same issue, maybe I should skip some of the time consuming tests entirely on ARM Assuming you can get a go compiler on the board the normal manual build instructions should work $ go get git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy $ sudo cp $GOPATH/bin/obfs4proxy /usr/local/bin But naturally you lose the benefits of package management. Regards, -- Yawning Angel pgpxP43c83EGi.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How to troubleshoot obfs4 bridge?
On Thu, 12 Mar 2015 10:44:28 -0600 Tim Sammut t...@teamsammut.com wrote: The bridge line I am supplying to TBB looks like: bridge obfs4 x.x.x.x:41980 obfs4 requires clients to prove that they know the server's obfs4 public key. This means that the bridge line needs a bit of extra information added. On the bridge look at: /var/lib/tor/pt_state/obfs4_bridgeline.txt Regards, -- Yawning Angel pgpFLZLKb3nNp.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-assistants] Running obfs4proxy on Debian Stable
On Sat, 14 Feb 2015 11:50:48 +0100 Alexander Dietrich alexan...@dietrich.cx wrote: So it's probably safer to wait for obfs4proxy to show up in Ubuntu repositories. Is there already a plan for that? There are no plans for this currently, and it is unlikely to happen unless someone steps up to do it. Regards, -- Yawning Angel pgpmuupux5jWY.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] updating obfuscations in windows bridges
On Mon, 16 Feb 2015 10:30:57 + eliaz el...@riseup.net wrote: s I read it, the tor browser bundle 3.x FAQ [1] implies that bridges on windows can use only obfs3 of the provided pluggable transports. Can someone let me know if this is correct? Huh? What does a old browser bundle FAQ have to do with running bridges on windows? The obfs3 line (as described in torrc-defaults) works fine, but torrc won't even accept obfs2, let alone fteproxy or flashproxy. No one should use obfs2 for anything, it's deprecated. Would torrc in windows accept obfs4 ? - thanks, eliaz If you have an obfs4proxy binary compiled for windows, you can run an obfs4 bridge on windows (as well as any of the other transports supported by obfs4proxy, which is currently obfs2/obfs3). I'm not really understanding the question... -- Yawning Angel pgpOcwxBJWQa3.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-assistants] Running obfs4proxy on Debian Stable
On Mon, 2 Feb 2015 22:41:40 + isis i...@torproject.org wrote: I requested that the obfs4proxy package in Debian jessie be ported to wheezy-backports, [0] however, it seems this is extremely unlikely to happen because it would mean backporting pretty much every Golang package in existence. Last I heard, that was mostly unnecessary, though how exactly this apt pinning stuff works is a mystery to me[0]. I would be super stoked if we could make it as easy and seamless as possible for the Bridge operators who are still running obfs2 (!!) to move to supporting better, newer Pluggable Transports. Currently recommended PTs to run are: obfs3, obfs4, scramblesuit, and fteproxy. When Tor Browser 4.5 becomes stable (probably in mid-April 2015), we'll want lots more obfs4 Bridges! For the super adventurous sysadmins who'd like to try Yawning's experimental new post-quantum PT, Basket [1] is one of the newest PTs. More obfs4 bridges would be amazing. It's worth noting that obfs4proxy can also handle obfs2 and 3 (and with a branch that I need to test/merge soon, a ScrambleSuit client), and it even is easy to run bridges on ports 1024 without messing with port forwarding. Basket is still a research project and non-researchers shouldn't deploy it because the wire format may change (and it consumes a hilarious amount of bandwidth). We should probably come up with some easy instructions for operators of Tor Bridge relays who are running Debian stable, such as adding an Apt pin to pull in only the obfs4proxy package and its dependencies from Debian jessie and keep everything else pinned to stable. If someone has done this, or has another simple solution, would you mind writing up some short how-to on the steps you took, please? [0]: http://lists.alioth.debian.org/pipermail/pkg-anonymity-tools/Week-of-Mon-20150202/001119.html [1]: https://github.com/yawning/basket All of obfs4proxy's dependencies are build time. The binary is statically linked because that's what Go does. David S.'s ansible-tor package does it like this: https://github.com/david415/ansible-tor/commit/f897581daa79389ddcb28c7dae601473e85e8226 So the documentation should be a matter of how to setup the apt pin for a single package. I've heard someone complaining about the tor AppArmor profile but that also isn't something I've dealt with ever. Regards, -- Yawning Angel [0]: I just scp the binary to my bridge whenever I need to update it, and my idea of how to update all my linux systems starts with pacman and not apt-get. pgpL005w2im2I.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for obfs4 bridges, and a brief discussion of obfs4proxy.
On Tue, 28 Oct 2014 04:46:37 + Yawning Angel yawn...@schwanenlied.me wrote: You could either Wait for Tor Browser 4.5-alpha which I am told will happen Soon, or run a tor instance and edit the torrc to use your bridge. The same obfs4proxy binary also acts as the client. Just to quickly follow up on this, Tor Browser 4.5-alpha-1 was released today which includes obfs4proxy fully integrated into the build system and the configuration interface so people should be able to easily test their bridges now. I'm planning on writing a in-depth blog post talking about obfs4 shortly as well. Regards, -- Yawning Angel pgpQryXnRWK2B.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for obfs4 bridges, and a brief discussion of obfs4proxy.
Hello, I'll consolidate a few e-mails since replies are spread out. On Mon, 27 Oct 2014 18:24:49 -0400 Steve Snyder swsny...@snydernet.net wrote: Does obfs4 support IPv6 addresses? If so, does it work like ORPort in that it is just a matter of adding another line? For example, to add an IPv6 address can I just replace ServerTransportListenAddr obfs4 111.222.333.444:__RNDPORT__ with ServerTransportListenAddr obfs4 111.222.333.444:__RNDPORT__ ServerTransportListenAddr obfs4 [:::::1]:__RNDPORT__ in the config file? Ooof. kind of. Pluggable Transport IPv6 support needs a lot of love and is one of the things on my TODO list. The obfs4proxy server code should support IPv6 as well as any other PT, but a lot of the tor and BridgeDB side needs a lot of love before I would consider things well supported. In particular, the following bugs need to be solved before dual stack bridges are really what I would consider fully functional (regardless of transport, all PTs are affected by these issues). * https://trac.torproject.org/projects/tor/ticket/7961 * https://trac.torproject.org/projects/tor/ticket/11211 * https://trac.torproject.org/projects/tor/ticket/12138 If you are running a private bridge, or wish to hand out IPv6 addresses to people on your own, then things will work, till then IPv4 PT bridges are far more useful. In the obfs4 case, there also is the problem that goptlib exposing a SOCKS4 interface vs SOCKS5 (required for IPv6 client use), so even if the server listens on IPv6 (and it should if told to do so, and also will automatically in certain cases), the client code can't use IPv6 bridges. * https://trac.torproject.org/projects/tor/ticket/12535 The code is done, but needs more testing, probably in the Tor Browser alpha series. For now, I would recommend running most PT bridges on IPv4, with the exception of bridges that are manually distributed. Fixing all of this is on my ever growing TODO list, but unfortunately keeps getting pushed back by bigger things being on fire. Can I use the same ExtORPort for both IPv4 and IPv6 addresses? The ExtORPort doesn't need to be public because it's only used for communicating between the pluggable transport server code and the tor daemon. So, yes the same one is fine, and I would recommend auto since it only needs to run/work on the loopback interface, unless your configuration is extremely exotic. One more question: how can I test the functionality of obfs4proxy given that TorBrowser v4.0.0 doesn't support this transport? You could either Wait for Tor Browser 4.5-alpha which I am told will happen Soon, or run a tor instance and edit the torrc to use your bridge. The same obfs4proxy binary also acts as the client. The relevant torrc bits for a client would be: UseBridges 1 # The bridge line from /var/lib/tor/pt_state/obfs4_bridgeline.txt on # the bridge, edited to replace the placeholders. Bridge obfs4 . ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy Regards, -- Yawning Angel pgppcCFdDzY4L.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] A friendly reminder for all ScrambleSuit bridge operators.
Hello all, This is a friendly reminder to all ScrambleSuit bridge operators that unless you are running tor-0.2.5.x, you should not be running a ScrambleSuit bridge. This is because the method for propagating the ScrambleSuit password (or any other future pluggable transport server side argument) for inclusion in the Bridge line served from BridgeDB was implemented in 0.2.5.x, and is not present in 0.2.4.x, and to make matters worse, 0.2.4.x has a bug that will allow this configuration to run instead of failing with an error[0]. If you are running a ScrambleSuit bridge with tor-0.2.4.x, it is useless. Users that happen to be served your ScrambleSuit bridge will not be able to connect, because the password is missing. Approximately 1/7th of the ScrambleSuit bridges in BridgeDB exhibit this behavior and we will most likely start filtering them on the BridgeDB side. Please see https://trac.torproject.org/projects/tor/ticket/13202 if you wish to know more about this. Best Regards, -- Yawning Angel [0]: Apparently this is not worth patching 0.2.4.x for, which I personally view as unfortunate. signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge Operators - Heartbleed, Heartwarming, and Increased Help
On Sat, 26 Apr 2014 06:05:27 + Yawning Angel yawn...@schwanenlied.me wrote: [snip] I'll look into adding backward compatibility code for the version of pycrypto CentOS packages so it's possible to setup one of these without pulling in all the development tools next (Git is temporary till the next obfsproxy release, since the #11558 changes are needed). Follow the bug for future progress. Ok, I just closed the bug[0] as invalid, with no planned further action on my part with regards to this. Summary of current state of obfsproxy on CentOS 6: It works with the vendor provided packages (Including python 2.6), as long as you install a more recent version of pycrypto. The vendor provided pycrypto (python-crypto-2.0.1-22) is not usable because it is missing `Crypto.Util.Counter` *and* more importantly, the CTR-AES implementation only handles plaintexts/ciphertexts that are sized as a multiple of the AES block size. Any version of pycrypto that has a fully working CTR-AES implementation will also provide `Crypto.Util.Counter`, so there is no need to implement the latter in obfsproxy as a compatibility hack. Till the next release of obfsproxy, people that wish to use this will need to grab obfsproxy from the git repository to get a fix for #11558. How one will properly update pycrypto is left as an exercise to someone that actually uses CentOS. -- Yawning Angel [0]: https://trac.torproject.org/projects/tor/ticket/11610#comment:3 signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge Operators - Heartbleed, Heartwarming, and Increased Help
On Thu, 24 Apr 2014 20:00:53 -0400 Steve Snyder swsny...@snydernet.net wrote: Let us know if/when obfsproxy runs on CentOS. It's broken? If someone files a bug explaining what's broken about it, the chances of it working again will rise significantly. For what it's worth asn and myself have been looking into making sure that it will run with the distribution packaged python (and assorted libraries) shipped with Debian oldstable which is probably similarly ancient (See Bug #11558). Even better, if/when it is back to being written in C, instead of version-specfic Python. That will increase obfsproxy use more than any heartfelt request. That's unlikely to happen. The closest thing that exists to a native implementation of the more recent pluggable transports is obfsclient, but it's client only and uses version-specific C++ that the standard CentOS compiler will choke on. From my perspective it would be easier to fix obfsproxy to better tolerate dependencies being prehistoric, but again, without a detailed bug report to work off of, that won't happen unless by happy accident. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
