- tor-relays - lists.torproject.org

[Important] A call for more long running bridges, especially with OBFS IAT-Mode set to 1 or 2.
by George Hartley 16 Jun '23

16 Jun '23

Hello dear relay and bridge hosts, recently a paper was published, describing a traffic confirmation attack called DeepCorr, which works against Tor users and as such, also hidden services. The attack allegedly had success rates of up to 96% percent. It is being worked on and listed here as a separate ticket: https://forum.torproject.net/t/tor-dev-critical-deepcorr-traffic-confirmati… Until mitigations have been merged into the Tor codebase, I kindly ask you, the driving force behind the network, to set up more bridges with "iat-mode" enabled and set to "1" or "2" - the paper stated that it was significantly harder to launch successful attacks against clients using OBFS4 bridges with timing obfuscation enabled, which is what "iat-mode" really is. In a nutshell, the measure of IAT is the average (or the arithmetic mean) between network packets arriving at a host over a period of time, of the times between packets arriving at a host over a period of time, which you can also call latency. For security reasons such as defeating DPI and similar network analysis techniques, OBFS4, while at the same time encrypting and making your traffic look like regular TLS traffic, it also offers to try and obfuscate the IAT and packet size by inserting random padding bytes. For you guys or girls with programming skills or the ability to read and understand code, here is the responsible code: https://github.com/Yawning/obfs4/blob/40245c4a1cf221395c59d1f4bf27412704535… I vote for a fair 50 / 50 distribution of bridges with "iat-mode=1" and "iat-mode=2", even though while IAT mode 2, also called the "paranoid" mode by the author of the code above, may be more effective. Dear clients, you can already enable timing-obfuscation in one way, by editing your bridge-line and setting iat-mode from "0" to either "1" or "2" - please be aware that this will only enable timing-obfuscation in one way, the bridge needs to support it too to get packet timing obfuscated in both ways. Dear bridge operators, all it takes is a simple tor configuration file change: ServerTransportOptions obfs4 iat-mode=1 or ServerTransportOptions obfs4 iat-mode=2 Your bridge key will very likely stay the same, although I do not have the infrastructure to try this out right now. It is and has been very hard to find reliable OBFS4 bridges which also support timing obfuscation, for over a year now - please consider changing your bridge configuration in order to possibly help clients and hidden services evade timing related attacks such as DeepCorr. Yours truly, George Hartley

2 2

AROI not getting verified
by chani 14 Jun '23

14 Jun '23

Hey all, I'm running a relay and wanted to get AROI setup. I tried to debug it now for quite some time, but I just cant get it to get verified. I checked that my contact info matches the well known file, and if the well known file is reachable. I also cant find anyone except myself, querying the well known file on my webserver for the last few days. Am I missing something? relay fingerprint: CA1D49840F37E0C9D5F1770A5F033D80EB6AF369

3 3

Re: [tor-relays] Do they use their own modem/router?
by Livingood, Jason 14 Jun '23

14 Jun '23

This thread mentions “Advanced Security” and you can learn more about that at https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security. This feature can only be used with a leased Xfinity gateway like the XB7 or XB8. There are a great many cable modems that customers can and do buy in retail stores that do not have such features – like the Arris S33 cable modem. So, a customer that has Advanced Security has in essence (1) chosen to use an XB gateway rather than buy their own modem & router in retail and manage it themselves, and (2) turned on Advanced Security. If the customer in question that is using Advanced Security wishes to turn it off, they can do so in the Xfinity app (or turn the modem into ‘bridge mode’ and use their own router, or use their own modem). I’m happy to help answer other questions. Jason Livingood Technology Policy, Product & Standards Comcast

2 1

Re: [tor-relays] Comcast blocks ALL traffic with tor relays
by Livingood, Jason 14 Jun '23

14 Jun '23

Hi – Dropping into this thread from Comcast to say that we DO NOT BLOCK Tor. Feel free to refer back to my 2014 blog statement on this at https://corporate.comcast.com/comcast-voices/setting-the-record-straight-on…. Jason Livingood Technology Policy, Product & Standards Comcast

2 1

Re: [tor-relays] Do they use their own modem/router?
by Livingood, Jason 14 Jun '23

14 Jun '23

BTW, feel free to refer back to my 2014 blog statement on this at https://corporate.comcast.com/comcast-voices/setting-the-record-straight-on…. Jason From: tor-relays <tor-relays-bounces(a)lists.torproject.org> on behalf of "Livingood, Jason via tor-relays" <tor-relays(a)lists.torproject.org> Reply-To: "tor-relays(a)lists.torproject.org" <tor-relays(a)lists.torproject.org> Date: Wednesday, June 14, 2023 at 14:43 To: "tor-relays(a)lists.torproject.org" <tor-relays(a)lists.torproject.org> Cc: Jason Livingood <Jason_Livingood(a)comcast.com> Subject: Re: [tor-relays] Do they use their own modem/router? This thread mentions “Advanced Security” and you can learn more about that at https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security<https://urldefense.com/v3/__https:/www.xfinity.com/support/articles/using-x…>. This feature can only be used with a leased Xfinity gateway like the XB7 or XB8. There are a great many cable modems that customers can and do buy in retail stores that do not have such features – like the Arris S33 cable modem. So, a customer that has Advanced Security has in essence (1) chosen to use an XB gateway rather than buy their own modem & router in retail and manage it themselves, and (2) turned on Advanced Security. If the customer in question that is using Advanced Security wishes to turn it off, they can do so in the Xfinity app (or turn the modem into ‘bridge mode’ and use their own router, or use their own modem). I’m happy to help answer other questions. Jason Livingood Technology Policy, Product & Standards Comcast

1 0

Do they use their own modem/router?
by xmrk2 13 Jun '23

13 Jun '23

Got a question from [seeess at riseup.net](mailto:seeess@riseup.net) > I had a question about the "advanced security" and the two users you tested with. Do either of them use their own customer provided modem, or are they both using a Comcast-provided modem/router? Is "Advanced Security" something that is configured locally on their networking equipment (like a Comcast-provided modem/router) or is it cloud based? You mention "in his Comcast router" but I wanted to double-check if it was specifically a Comcast-provided piece of hardware. CCB says: "It is configured in the cloud. There's a limited amount of things I can do with my router, most of the settings are done through their app. So like... things like my port forwarding, I can't actually do in my router, I have to go through the app, which I can access remotely or on a different network." I think we cannot be sure where the filtering is done (router at customer's premises or inside Comcast network) unless someone tries with custom router. CCA stopped replying me, I can only speculate. He tested our connection with netcat, mentioned using wireguard, so he should be capable of configuring his custom router. But whether he does.... my guess would be as good as yours. ------- Original Message ------- On Sunday, June 11th, 2023 at 1:46 PM, xmrk2 <xmrk2(a)protonmail.com> wrote: > I'd like to raise awareness of the Comcast blocking. > > As stated in subject, I believe Comcast blocks all traffic between its customers and public tor relay nodes. That is, the blocking is not limited to tor-related traffic, all other services / ports on the tor relay are blocked. > > Background: I am running a lightning node, lightning is a layer 2 protocol to scale Bitcoin. Lightning nodes need to be connected to each other ideally 24/7. I was contacted by the operator of another Lightning node, complaining that he cannot connect to my node. He is Comcast customer, I am not. I was also running a tor relay on the same public IPv4 address. > > I am pretty sure that the blocking is done by Comcast and is triggered by being in public list of tor relays. The blocking disappeared after I stopped my tor relay and restarted my router (thus getting a new external IPv4 address). After 1 day, I relaunched the tor relay, and the blocking reappeared a few hours later. It was also confirmed by the said operator of the lightning node, who said there were various rounds of blocking tor, customers complaining and Comcast lifting the block for some time, only to reinstate the blocking later. > > Comcast thus discourages me and similar people from running tor relays, or at least forces me to run tor in bridge mode. So this is an insidious attack on tor. Note that Bitcoin is not particularly relevant, Comcast is blocking tor nodes, not bitcoin nodes. So even if you hate Bitcoin, note that the same problem could arise even if Bitcoin never existed: e.g. a self-hosted web server, whose owner wants to donate his free capacity to tor by running tor relay. By doing this, he prevents any Comcast customers from accessing his web server, and this consequence is not obvious at all. > > Any ideas on how to combat this? I was thinking about including some false positives in tor relay list. Imagine including some Google servers' IP addresses - Comcast customers suddenly cannot connect to Google, unless Comcast stops this blocking... or simply whitelists Google. But those false positives sound ugly and a bit malicious, not sure it is a good idea. > > I already wrote about this publicly, and also wrote a mail to EFF. Hope I am not spamming, I feel this is quite important issue and am a bit frustrated by the lack of attention it gets.

1 0

Re: [tor-relays] Comcast blocks ALL traffic with tor relays - probably firewall configuration; further tests
by xmrk2 13 Jun '23

13 Jun '23

Starting from the most interesting info - another Comcast customer contacted me, lets call him CCB, and the first Comcast customer I mentioned previously will be CCA. CCB claims he had to disable some settings - probably "Advanced Security" - in his Comcast router, because before doing so, nobody was able to connect to his lightning node via IPv4 (clearnet, not tor). He claims to have done this back in July or August. We tested just today, and both sides were able to successfully initiate TCP connection, no blocking here. Importantly, at the same time I was not able to connect to CCA - timeout. Chronology of tests, all times are in CEST. around 18:00 yesterday - I started tor relay (non-exit, ExitPolicy reject *:*) 22:09 - it appeared as online on https://metrics.torproject.org/ . Started testing connection to CCA, using "socat -dd - TCP4:<CCA_ADDR>:<CCA_lightning_port>" every 5 minutes. Connected successfully. 07:07 - last successful connection to CCA 07:12 - first unsuccessful connection to CCA - timeout; all subsequent tests with CCA end with timeout 08:10 - stopped tor relay 13:09 - 13:14 - tests with CCB - both sides can connect 17:54 - still cannot connect to CCA 18:19 - connected to CCA from my mobile phone connection (so from another IP, which is not blacklisted, so we see CCA is not offline) 18:55 - still cannot connect to CCA So port forwarding must be correct on CCA, or I would not be able to connect. Now I think the blocking is real, probably on by default, but Comcast customers can opt-out. Doubts / weaknesses of tests and theory: - only tested with 2 Comcast users - not sure about CCA's firewall settings - I just assume he has "Advanced Security" active - my tests only cover connections from me to Comcast users. Not sure if this "Advanced Security" also blocks connections from Comcast users. On one hand, my lightning channel with CCA was inactive for a month or more, and CCA contacted me because of it. Lightning nodes want and try to connect to all peers they have channel with, automatically - so his node presumably tried to connect to mine. And lightning nodes publish their IP addresses, there are sites which show current IP addresses of lightning nodes, like https://1ml.com/node/030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7… (the link already points to a concrete node). My node should announce its IP addresses. So even if connection from me is blocked, he should initiate connection. Inactive channel means he was not successful, difficult to explain without blocking. OTOH, he claims he can connect to tor, so must be able to connect to at least some tor relay, not necessarily mine. Any volunteer Comcast customers for further testing? Preferably without lightning nodes, because I'd like to test with this "Adv. security" active, and it may interfere with lightning node (or any other use-case which needs high uptime). If my theory is correct, Comcast is slightly less evil than my very first post would suggest. Still evil, because this blocking has little to do with security - maybe blocking exit relays makes some sense, they can be misused to attacks, DDoS etc. But according to Comcast, merely running tor relay makes you a threat. And this so-called security is probably on by default (according to CCB) and "There are definitely popups all over the place telling me to turn it on". So it is probably not apparent that this setting blocks (some? most?) tor relays completely.

1 0

«Possible compression bomb» from Authority?
by Tschador 07 Jun '23

07 Jun '23

Hi there, today I found this warning in the log of my relay (6A7551EEE18F78A9813096E82BF84F740D32B911): Jun 03 04:04:33.000 [warn] Possible compression bomb; abandoning stream. Jun 03 04:04:33.000 [warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 199.58.81.140:80). What does this mean? Regards

4 3

Providing metrics relevant to relay operators
by Georg Koppen 07 Jun '23

07 Jun '23

Hello! I got recently pinged by a large exit operator asking whether we had a website with nice graphs and statistics relevant to relay operators on our project infrastructure (showing e.g. the largest exit operators etc.), but that's currently not the case and we should fix that. There are some third-party tools, like OrNetStats[1], but we think it would be very useful for our relay operators to have relevant information available on the Tor Project website itself. Those third-party projects are a good contribution to the overall ecosystem we have but might e.g. die at some point due to lack of maintenance or move their focus to particular parts of the network while neglecting others, which is fine in general. However, we as a project should make sure our relay operators and we ourselves are not losing important insights into the state of the network and its different relay groups in case anything like that happens. At the end of the day those statistics and graphs should show up on metrics.torproject.org but we are not there yet given the complex nature of that website and our plans to fix that. However, thanks to our efforts of setting up a database containing all the relay descriptors and other network documents and our ongoing Google Summer of Code project for making those accessible with the help of a network status API we can start to experiment with providing those statistics early on via a different venue. I've just filed a ticket tracking that process[2] for those of you who are interested. As always we are very much interested in collaboration and getting feedback from all of you. So, if you have particular statistics and graphs you would like to see on such a website, please speak up! Ideally, this would happen on the above-mentioned Gitlab issue but just replying to this thread or in private is fine as well. Thanks, Georg [1] https://nusenu.github.io/OrNetStats/ [2] https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/4…

1 0

Tor Relay Operator Poll (closes on 2023-05-30)
by nusenu 27 May '23

27 May '23

Hi, want to help shape the future of the Tor network? Here is a poll for you: https://cryptpad.fr/form/#/2/form/view/VE-b3bd-IS1P17Povh0ryIHYhqGqEiA7sJMR… It is open until 2023-05-30. Only operators that did run relays/bridges before 2023-04-01 (and are still running) may participate. An AROI or a relay fingerprint (or hashed bridge fingerprint) is required to participate. This poll happens in the context of working on a network health proposal. The goal of this poll is * to gather input from non-malicious relay operators * to help make pragmatical design decisions for an upcoming network health proposal * to ensure it remains practical to implement for relay operators * to get a feeling on whether it has a chance to see actual real world adoption * to get a feeling on whether relay operators would participate in a web of trust * to get a feeling on what type of rules relay operators would find acceptable In the light of malicious entities this poll has been send to large relay operators a few days ago so they can claim their submission first. Their feedback was also used to improve and extend the poll, if you submitted it already once you can submit it again but ensure to submit the same random string at the end as you did the first time so they can be linked. kind regards, nusenu -- https://nusenu.github.io

2 3