Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[George Hartley via tor-relays]

Regarding web-servers hosting Tor relays, it is much more likely for them to 
sit behind a CDN such as Cloudflare for DoS protection and delivery 
optimization.

Other services of course, however..
--- Original Message ---
xmrk2 via tor-relays  schrieb am Sonntag, 11. 
Juni 2023 um 1:46 nachm.:


> 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.

signature.asc
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] Comcast blocks ALL traffic with tor relays

[xmrk2 via tor-relays]

Yes, I agree 100% with Danny's summary here, so I have to concede, I did not 
found enough evidence that Comcast blocks connections *to* tor relays. I 
apologize. Specifically, I did some tests with ronqtorrelays at risley.net , 
who is a Comcast Business customer, and he had no problem initiating TCP 
connection to my relay, even to tor-unrelated port.

About the other direction - from tor relays or exits to Comcast:

> https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security 
> mentions "Blocks remote access to smart devices from known dangerous 
> sources.". What do you mean by dangerous sources, and does it include tor 
> relays or exits?
>
> [https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security](https://urldefense.com/v3/__https:/www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security__;!!CQl3mcHX2A!GL-M865o8Ul6VQiGJSAHwue9MmlLnlCkSlez2kSjTpTq91B5S2TV_6hpdIS3pBMgjK8UBjTiRgcW8Hu1XzhBRik$)mentions
>  "Blocks remote access to smart devices from known dangerous sources.". What 
> do you mean by dangerous sources, and does it include tor relays or exits?
>
> It may be down to the fact that “unknown” users connect to the relay/exit and 
> that the average consumer user of the Advanced Security service does not want 
> that. I suspect if someone wants this, it’s best to toggle Advanced Security 
> off.
>
> [https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security](https://urldefense.com/v3/__https:/www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security__;!!CQl3mcHX2A!GL-M865o8Ul6VQiGJSAHwue9MmlLnlCkSlez2kSjTpTq91B5S2TV_6hpdIS3pBMgjK8UBjTiRgcW8Hu1XzhBRik$)mentions
>  "Blocks remote access to smart devices from known dangerous sources.". What 
> do you mean by dangerous sources, and does it include tor relays or exits?
>
> It may be down to the fact that “unknown” users connect to the relay/exit and 
> that the average consumer user of the Advanced Security service does not want 
> that. I suspect if someone wants this, it’s best to toggle Advanced Security 
> off.
>
> [https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security](https://urldefense.com/v3/__https:/www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security__;!!CQl3mcHX2A!GL-M865o8Ul6VQiGJSAHwue9MmlLnlCkSlez2kSjTpTq91B5S2TV_6hpdIS3pBMgjK8UBjTiRgcW8Hu1XzhBRik$)mentions
>  "Blocks remote access to smart devices from known dangerous sources.". What 
> do you mean by dangerous sources, and does it include tor relays or exits?
>
> It may be down to the fact that “unknown” users connect to the relay/exit and 
> that the average consumer user of the Advanced Security service does not want 
> that. I suspect if someone wants this, it’s best to toggle Advanced Security 
> off.
>
> [https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security](https://urldefense.com/v3/__https:/www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security__;!!CQl3mcHX2A!GL-M865o8Ul6VQiGJSAHwue9MmlLnlCkSlez2kSjTpTq91B5S2TV_6hpdIS3pBMgjK8UBjTiRgcW8Hu1XzhBRik$)mentions
>  "Blocks remote access to smart devices from known dangerous sources.". What 
> do you mean by dangerous sources, and does it include tor relays or exits?
>
> It may be down to the fact that “unknown” users connect to the relay/exit and 
> that the average consumer user of the Advanced Security service does not want 
> that. I suspect if someone wants this, it’s best to toggle Advanced Security 
> off.
>
> It may be down to the fact that “unknown” users connect to the relay/exit and 
> that the average consumer user of the Advanced Security service does not want 
> that. I suspect if someone wants this, it’s best to toggle Advanced Security 
> off.

Seems you do not understand the difference between exit relay and non-exit 
relay. (Nor does the persons who implemented this blocking of traffic from tor 
relays - this would explain a lot.)

I would first reformulate: unknown and anonymous users may route their traffic 
through tor, including some attacks (DDoS or worse), and this traffic will look 
like originating from tor *exit* relay. But this is only true about *exit* 
relays (and then only about some ports, but let's keep it simple). Non-exit 
relays only send tor-related traffic to other tor relays, never to other 
destinations. So when a non-exit relay R connects to a computer X, which does 
not run anything tor-related, you can be sure this connection is not 
tor-related and is really initiated by R. If we had a tor exit relay E, then 
connection E->X could be initiated by E or by a bad guy B who is abusing tor's 
anonymity. And X cannot tell the difference, so it is reasonable to assume the 
worst and block this. The traffic from B would really follow the path 
B->R1->R2->E->X, where R1 are R2 non-exit relays. You may argue that this bad 
traffic goes through R1 and R2, but so what? Blocking E->X is sufficient, but 
you are also blocking R1->X and R2->X.

Here 

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[Xiaoqi Chen (Danny)]

Hi xmrk2,

As a fellow relay operator I think it might be helpful for me to add some
clarification to what you saw.

1. "comcast" the ISP didn't block or interfere with traffic to/from the
relay IP. (Thanks Jason for the clarification.)
However,
2. an average "comcast user" (with ISP-provided modem and the "advanced
security" on by default) will by default block *incoming* connection from
relay IPs. Thus, when the said user opens a port forwarding from their
public IP, you can't proactively connect to that IP:port from your relay's
IP.
3. "advanced security" will not block return traffic for *outgoing*
connections from the user. That is, when this user connects to a relay IP
(e.g., opens a tor browser), it works just fine.

The blocking is done at the modem box, and anyone expecting incoming
connection from the wider internet should obviously turn off "advanced
security" on their box. I can understand the motivation for the default --
when most people set up port forwarding, they probably only want incoming
connections from friends or their own phone, not the entire internet.

I do not use comcast personally so this is only based on anecdotes I heard
and the thread so far; please take it as a grain of salt. Hope it helps.
I'm also happy to help you and your lightning node friend privately.
--
Danny


On Thu, Jun 15, 2023 at 6:43 AM Livingood, Jason via tor-relays <
tor-relays@lists.torproject.org> wrote:

> >As to the blog post you mention… Your statements are very generic: now
> you talk about "not blocking tor", but tor is not just one webpage, one
> server, a monolithic entity. I would appreciate details: If your customer
> has "advanced security" activated, can he connect to any ORPort of any tor
> middle relay?
>
> Fair enough. That post was in any case from 2014 and the questions are
> different today (I just used it as an example that we’re not against Tor).
> Honestly, I’m a little surprised that someone running a Tor exit node would
> not be using their own cable modem and running their own router (whether
> open source a la Openwrt or commercial). If someone wants to do stuff like
> run a Tor exit node or run a MASQUE relay or whatever, I’d recommend they
> turn off Advanced Security and manage their routing & firewall rules
> themselves.
>
>
> >Sorry if I am a bit repetitive, but
> https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security
> 
>  mentions
> "Blocks remote access to smart devices from known dangerous sources.". What
> do you mean by dangerous sources, and does it include tor relays or exits?
>
>
>
> It may be down to the fact that “unknown” users connect to the relay/exit
> and that the average consumer user of the Advanced Security service does
> not want that. I suspect if someone wants this, it’s best to toggle
> Advanced Security off.
>
>
>
> > I don't know whether this customer has "Advanced security" turned on, I
> just assume he has. Do you want me to send you privately more details (my
> IP and this peer's IP)?
>
> Sure – I am happy to look at that confidentially. But it could be a wide
> range of other things – even basic things like someone’s router timing out
> external connections after X minutes, etc.
>
> > So you remind me of an old joke: who should I believe, you, or my eyes?
> Sorry, I choose my eyes. I am talking here about direction from my node to
> Comcast. It is still possible that you don't block connections from Comcast
> to relays, I have contradictory evidence about this point. So if your "not
> blocking tor" means "not preventing our customer from connecting to some
> tor relays", this could be true.
>
>
>
> Alternatively, given the large size of our network, if we were in fact
> blocking this, then I’d expect to see this list filled with complaints and
> social media sites (Twitter
> ,
> Reddit, etc.) filled with complaints. But what I see now is a single
> report. That said, I routinely look at such reports when they seem at odds
> with our network policies so as to be certain there’s not some
> misconfiguration or bug someplace.
>
>
>
> Jason
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[Livingood, Jason via tor-relays]

>As to the blog post you mention… Your statements are very generic: now you 
>talk about "not blocking tor", but tor is not just one webpage, one server, a 
>monolithic entity. I would appreciate details: If your customer has "advanced 
>security" activated, can he connect to any ORPort of any tor  middle relay?

Fair enough. That post was in any case from 2014 and the questions are 
different today (I just used it as an example that we’re not against Tor). 
Honestly, I’m a little surprised that someone running a Tor exit node would not 
be using their own cable modem and running their own router (whether open 
source a la Openwrt or commercial). If someone wants to do stuff like run a Tor 
exit node or run a MASQUE relay or whatever, I’d recommend they turn off 
Advanced Security and manage their routing & firewall rules themselves.

>Sorry if I am a bit repetitive, but 
>https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security
> mentions "Blocks remote access to smart devices from known dangerous 
>sources.". What do you mean by dangerous sources, and does it include tor 
>relays or exits?

It may be down to the fact that “unknown” users connect to the relay/exit and 
that the average consumer user of the Advanced Security service does not want 
that. I suspect if someone wants this, it’s best to toggle Advanced Security 
off.

> I don't know whether this customer has "Advanced security" turned on, I just 
> assume he has. Do you want me to send you privately more details (my IP and 
> this peer's IP)?

Sure – I am happy to look at that confidentially. But it could be a wide range 
of other things – even basic things like someone’s router timing out external 
connections after X minutes, etc.

> So you remind me of an old joke: who should I believe, you, or my eyes? 
> Sorry, I choose my eyes. I am talking here about direction from my node to 
> Comcast. It is still possible that you don't block connections from Comcast 
> to relays, I have contradictory evidence about this point. So if your "not 
> blocking tor" means "not preventing our customer from connecting to some tor 
> relays", this could be true.

Alternatively, given the large size of our network, if we were in fact blocking 
this, then I’d expect to see this list filled with complaints and social media 
sites 
(Twitter, 
Reddit, etc.) filled with complaints. But what I see now is a single report. 
That said, I routinely look at such reports when they seem at odds with our 
network policies so as to be certain there’s not some misconfiguration or bug 
someplace.

Jason
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[xmrk2 via tor-relays]

Hello,

It is a good sign that Comcast cares and wants to defend itself. Another 
positive is that you did not try things like "tor is only for 
criminals/terrorists".

As to the blog post you mention. (Note that to see the post one may need to 
delete the trailing full stop from the url, the correct url is 
https://corporate.comcast.com/comcast-voices/setting-the-record-straight-on-tor.)
 Your statements are very generic: now you talk about "not blocking tor", but 
tor is not just one webpage, one server, a monolithic entity. I would 
appreciate details: If your customer has "advanced security" activated, can he 
connect to any ORPort of any tor middle relay? Can he connect to other ports of 
any tor middle relay? What about exit relays? What about other direction - can 
tor relays and exits connect to Comcast customers who have "adv. security" 
activated? Does it depend on destination port? Sorry if I am a bit repetitive, 
but 
https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security 
mentions "Blocks remote access to smart devices from known dangerous sources.". 
What do you mean by dangerous sources, and does it include tor relays or exits?

And in the blog the word "block" is not even mentioned.

- "Comcast doesn’t monitor ..." - irrelevant to blocking

- "The anecdotal chat room evidence  ..." -- not even linked, I don't know what 
is this evidence, so cannot comment

- "We respect customer privacy and security and only investigate ..." - again 
irrelevant to blocking

- "We do not terminate customers for violating the Copyright Alert System..." - 
even more irrelevant, I never talked about terminating customers

I am quite sure that if I run a tor relay, after some time I stop being able to 
connect (using my fibre connection) to certain Comcast customer, I get a 
timeout, and at the same time I am able to reach this same customer by mobile 
connection And both fiber and mobile connections are provided to me by the same 
company. So who do you suggest is doing this blocking? My ISP? I don't know 
whether this customer has "Advanced security" turned on, I just assume he has. 
Do you want me to send you privately more details (my IP and this peer's IP)? 
Comunity: Is there some privacy problem if I provide this info? Comcast already 
sees my connection attempts, at most they can link my email with my IP address.

So you remind me of an old joke: who should I believe, you, or my eyes? Sorry, 
I choose my eyes. I am talking here about direction from my node to Comcast. It 
is still possible that you don't block connections from Comcast to relays, I 
have contradictory evidence about this point. So if your "not blocking tor" 
means "not preventing our customer from connecting to some tor relays", this 
could be true.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[xmrk2 via tor-relays]

I have only experienced similar problems while running tor exit node, even with 
very restricted exit policy. Allowing exit only to port X, and unable to 
initiate connections to port Y (typically Y=HTTPS=443, of course X =/= Y).

Note that those problems are not Comcast's fault, although they do point to 
more general problem: that people (webmasters, cloud services, ISPs) sometimes 
block too much and misunderstand tor, they probably wanted to block just tor 
exits, but end up blocking anything tor-related.

This leads me to following idea: Educational campaign to teach relevant people 
about difference between middle relays and exits. My proposal for title/slogan: 
"Tor relays are not a threat - no reason to block them". (Should it be "middle 
relays"? But it seems too long then.) EFF could be quite helpful there.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[Livingood, Jason via tor-relays]

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-tor.

Jason Livingood
Technology Policy, Product & Standards
Comcast
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[webmaster]

I have the same problem here in germany with also two sites. I'm running 
an non-exit relay.
So far I can not access the sites "banking.ing-diba.de" and 
"www.elster.de" when the tor server is running after some time.


The only thing which helps when I renew my public ip address. Then the 
access to the above mentioned sites is posible for some time.
I'm not sure if the sites are blocking by themself or if they are using 
some service like cloudflare which does the blocking.


Am 13.06.2023 um 23:18 schrieb secureh...@gmail.com:
I was running a Tor Relay for a while from a Comcast residential, 
non-business account up until a couple of months ago with no issues 
from Comcast.


I did, however start experiencing issues accessing other commercial 
websites from the same Internet address. When I accessed those sites 
from a different IP address I had no problem.


Ultimately I determined our IP address was being blacklisted by 
certain hosting services who probably grabbed all Tor-related IP 
addresses and blocked them as a service to commercial websites. As 
this info is readily available it’s easy to deduce this.


From this I’d say running any Tor components from a shared residential 
ISP probably isn’t a good recommendation.


On Jun 12, 2023, at 3:13 AM, xmrk2 via tor-relays 
 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.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[securehell]

I was running a Tor Relay for a while from a Comcast residential, non-business 
account up until a couple of months ago with no issues from Comcast.

I did, however start experiencing issues accessing other commercial websites 
from the same Internet address. When I accessed those sites from a different IP 
address I had no problem.

Ultimately I determined our IP address was being blacklisted by certain hosting 
services who probably grabbed all Tor-related IP addresses and blocked them as 
a service to commercial websites. As this info is readily available it’s easy 
to deduce this.

From this I’d say running any Tor components from a shared residential ISP 
probably isn’t a good recommendation.

> On Jun 12, 2023, at 3:13 AM, xmrk2 via tor-relays 
>  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.
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays - probably firewall configuration; further tests

[xmrk2 via tor-relays]

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::" 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/030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f
 (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.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[xmrk2 via tor-relays]

Okay, you planted some doubt. This is a quote what my peer wrote me about the 
issue, I hope it is ok to quote, contains no personal or sensitive info, 
emphasis added:

> Comcast/Xfinity! has a bumpy past with tor. They periodically block it, get 
> yelled out by their subscribers and the media, then unblock it. At this 
> moment, outgoing tor is working. That is I am able to put the Brave browser 
> in tor mode. But, because of the intermittent interruptions, I've given up on 
> using tor when running behind my ISP.

Outgoing tor is working - so he has to be able to connect to some relay, not 
necessarily all of them. Or he configured a tor bridge because of past problems 
and forgot about it?

> Are you sure that port forwarding To your relay is reliably working and that 
> some "security feature" in your Comcast modem/router isn't causing the 
> problem? I haven't researched any reports of Comcast blocking so I can't 
> speak to any other anecdotal reports of said blocking. I sure hope it isn't 
> the case. If it is, I'll certainly drop them in a flash too.

Well, I am not in the US, no Comcast here :), and running OpenWrt on my router. 
My peer is Comcast customer. I was connected to > 100 lighting nodes while not 
able to connect to my Comcast peer. I did not check specifically, my lightning 
node should be reachable by IPv4, IPv6 and tor/onion, so in theory there could 
have been no inbound IPv4 connection while having > 100 connections. But not 
likely. I think I either checked my fail2ban-client banned, or turned off 
fail2ban.

Still, there could be some DDoS protection on my Comcast peer's end. To 
corroborate: lightning nodes need to be connected, they try to reconnect 
frequently to all their "neighbours". I myself see that when I take my 
lightning daemon offline for just 10 minutes, many IP addresses end in my 
fail2ban list. So my Comcast peer could have just taken his node offline, his 
router would see too many connection attempts from me and consider it DoS and 
ban me. Still, I would expected to be unbanned after some time, and this does 
not seem to happen, so this would be argument against DDoS protection.

For reference, this is my fail2ban's jail.local, perhaps too aggressive:

[lnd]
enabled = true
ports = 9735:9736
filter = lnd
logpath = ...
maxretry = 4

[lnd-repeat]
enabled = true
ports = 9735:9736
filter = lnd
logpath = ...
maxretry = 12
findtime = 1h
bantime = 1h

I'll test again by starting tor middle relay, and check inbound IPv4 
connections, should bring some results in a few hours.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[ronqtorrelays]

> On Jun 11, 2023, at 04:46, xmrk2 via tor-relays 
>  wrote:
> 
> I believe Comcast blocks all traffic between its customers and public tor 
> relay nodes

I'm a reluctant Comcast Business user. Here's my experience (briefly, as I'm 
typing with a newly-fractured wrist):

Though during install I asked for "just pipes" with none of the extra services 
they offer, instead they silently signed me up for their "Security Edge" 
service. Many things broke. I finally discovered that they were intercepting 
all outbound UCP and TCP traffic to port 53 and re-directing it to their own, 
badly-broken DNS resolver which seems to be pretty arbitrary about what it 
blocks. When I contacted them, they said it couldn't be removed but gave me 
instructions for turning it off, but the switch to do so on their web site was 
disabled (grey and not responsive to clicking, using multiple browsers and 
platforms). After over TWENTY HOURS on chat, they finally disabled it from 
their end. I had pointed out that it was a direct and blatant violation of 
California's net neutrality law. Life was good for about a week, then it came 
back on. I think I next posted a complaint on Reddit (which seems to get more 
attention than contacting customer service directly) and they, again, turned it 
 off. Around a year later, they started MITMing all my DNS queries again, 
wreaking havoc on my business. I, again, poked around their web site, and I 
found that the switch to disable blocking is now enabled (though hard to find) 
and for a couple of months now things have been okay.

None of my difficulties were directly related to Tor, even though I run a relay 
on one of my IP addresses. However, the variable and arbitrary nature of the 
blocks they implemented make it seem likely that they could be blocking Tor 
relays some of the time.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[lists]

On Sonntag, 11. Juni 2023 13:46:06 CEST xmrk2 via tor-relays wrote:

> 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.
> 
> 
> Any ideas on how to combat this?
It might help to configure Lightning node as a hidden service.
I offer my Monero and Bitcoin RPC & P2P ports as a hidden service.

And have additionally SocksPort flag 'OnionTrafficOnly' on the client and 
hidden 
service side.
SocksPort 9050 OnionTrafficOnly
# Tell the tor client to only connect to .onion addresses in response to 
SOCKS5 requests on this connection.
# This is equivalent to NoDNSRequest, NoIPv4Traffic, NoIPv6Traffic.

> I was thinking about including some false positives in tor relay list.
I wouldn't do that. I think you'll end up on the bad-relay list in no time.
I would rather write to the Comcast network admins first. Give them good 
examples. E.g. in Germany the ISP's support Tor (NetCologne, Deutsche Telekom, 
...)

Mirror:
https://torproject.netcologne.de/dist/
Our Traffic sponsors:
https://www.community-ix.net/sponsors/

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[xmrk2 via tor-relays]

> This sucks big time, if true. I am trying to ping Comcast from a middle
> relay IP address and it seams, to work, I guess you mean AS33651 -
> Comcast Cable LLC.

The peer's IP address is in ASN 7922, according to whatismyipaddress.com . Note 
that my test was always opening a TCP4 connection to him using socat. (I know 
on what port his lightning daemon listens. Obviously not feasible to do such 
test with a random Comcast customer.) In fact that node does not respond to 
pings. Perhaps those 2 differences explain different results.

I will send that peer a link to this convo, he could do some tests from inside 
Comcast's network. He sounded a bit resigned though, so no guarantees obviously.

And thanks for encouragement, up to now my efforts have fallen mostly to deaf 
ears. 

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[sysop]

FWIW I haven't ever experienced any issues using Tor on multiple Comcast 
residential and business lines.


I use Tor as a client daily from a Comcast residential connection and 
have never been unable to connect to directories or relays.


I also have a directory client running 24/7 on Comcast business and it 
hasn't had any Tor-related connectivity issues over the last 6+ years.


I just spun up a new /relay/ on a Comcast residential connection and 
have no issues talking to other relays and I've confirmed the ORPort is 
reachable from multiple other AS's in the US and abroad.


 │ 09:11:35 [NOTICE] Self-testing indicates your ORPort 
98.45.218.223:9001 is reachable from the outside. Excellent. Publishing 
server descriptor.
 │ 
https://metrics.torproject.org/rs.html#details/42BD1CC75EA01755D1F7DC8205C9ED9B19C7DC96


If anyone wants to test reachability to this Comcast relay, I'll leave 
it up for the next 48 hours or so.


I'm not necessarily a fan of Comcast or any of their practices and am 
only speaking for myself here but I haven't ever experienced any 
blocking or difficulty.


Are you sure that port forwarding To your relay is reliably working and 
that some "security feature" in your Comcast modem/router isn't causing 
the problem? I haven't researched any reports of Comcast blocking so I 
can't speak to any other anecdotal reports of said blocking. I sure hope 
it isn't the case. If it is, I'll certainly drop them in a flash too.


Regards,

Drew

On 6/11/23 04:46, xmrk2 via tor-relays 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.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[tor admin via tor-relays]

If we could get EFF to announce a boycott of any corporation known to 
act maliciously against Tor or other privacy-friendly technology (such 
as VPNs), that would go a long way.


I will also write to EFF.  I have donated money to them, so maybe they 
will listen.  If they won't support a boycott directly, maybe at least 
they will comment on the issue publicly, and that would help launch a 
boycott.


If will also help to get an official communication from Comcast saying 
they are blocking Tor.  If they won't admit this, it makes it that much 
harder to fight.  I can't do this as I'm not a Comcast customer.  Are 
there any Comcast customers that can get a Comcast rep to admit, in 
writing, that this is happening?







On 6/12/23 10:50, s7r wrote:

xmrk2 via tor-relays wrote:
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.




This sucks big time, if true. I am trying to ping Comcast from a 
middle relay IP address and it seams, to work, I guess you mean 
AS33651 - Comcast Cable LLC. Anyway, it could be, at latest consensus 
there is no single relay (middle or exit) hosted in AS33651.


I am not sure about the false positive solution, I see only downsides, 
including but not limited to:


- it's not ethical for Tor Project to do this, e.g. stating another 
company's infrastructure (say Google IP address space) is part of a 
network when in fact its not. I get it that the goal is privacy 
oriented and in good faith (freedom faith) but it seams rather 
inappropriate;


- there is no evidence that a blocker might use a list of relays 
provided by Tor Project's metrics portal (I am confident nobody does 
it because it's less effective) - they can just run a Tor client and 
get a copy of a consensus and extract from there IP:PORT IPv6:PORT and 
do from there whatever they please;


- if you include such false positives in the consensus you have to 
simulate dummy Tor relays on those "hot" IP addresses, like providing 
an onion key, RSA identity and ed25519 identity, thus looking like a 
relay, state some bandwidth for it, etc - in this case how will a Tor 
client know which relay is dummy and which not, in order not to try to 
establish circuits that fail, ultimately producing a terrible user 
experience for all users. Same applies for other relays, not just 
clients, that need to produce connections with the dummy relays. If we 
somehow mark them as "dummy", it will be pretty stupid and obvious and 
waste of effort as the blocker can simply understand the "dummy" 
marker and it's done, I guess it's pretty obvious.


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.




Not at all, this is very interesting and not spamming at all. I think 
it is unacceptable for this to happen, and I think all Comcast 
customers should quit if this is true - large internet corporations 
are trying to move on from "IP address identifications" as in only a 
beginner that discovered the internet one week ago still thinks of the 
IP address as "identification of a certain individual / entity", 
everybody is moving to advanced layers of authentication on per device 
basis, cryptographic public key, etc. Comcast if they do such a thing 
they set themselves 25 years behind the industry they operate in. And 
this can create many unwanted effects, someone should try to do 
something about this but I am not sure what we Tor volunteers *can* do 
to help with this, especially the ones that are not Comcast customers. 
EFF is the best start IMO.



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[s7r]

xmrk2 via tor-relays wrote:
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.




This sucks big time, if true. I am trying to ping Comcast from a middle 
relay IP address and it seams, to work, I guess you mean AS33651 - 
Comcast Cable LLC. Anyway, it could be, at latest consensus there is no 
single relay (middle or exit) hosted in AS33651.


I am not sure about the false positive solution, I see only downsides, 
including but not limited to:


- it's not ethical for Tor Project to do this, e.g. stating another 
company's infrastructure (say Google IP address space) is part of a 
network when in fact its not. I get it that the goal is privacy oriented 
and in good faith (freedom faith) but it seams rather inappropriate;


- there is no evidence that a blocker might use a list of relays 
provided by Tor Project's metrics portal (I am confident nobody does it 
because it's less effective) - they can just run a Tor client and get a 
copy of a consensus and extract from there IP:PORT IPv6:PORT and do from 
there whatever they please;


- if you include such false positives in the consensus you have to 
simulate dummy Tor relays on those "hot" IP addresses, like providing an 
onion key, RSA identity and ed25519 identity, thus looking like a relay, 
state some bandwidth for it, etc - in this case how will a Tor client 
know which relay is dummy and which not, in order not to try to 
establish circuits that fail, ultimately producing a terrible user 
experience for all users. Same applies for other relays, not just 
clients, that need to produce connections with the dummy relays. If we 
somehow mark them as "dummy", it will be pretty stupid and obvious and 
waste of effort as the blocker can simply understand the "dummy" marker 
and it's done, I guess it's pretty obvious.


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.




Not at all, this is very interesting and not spamming at all. I think it 
is unacceptable for this to happen, and I think all Comcast customers 
should quit if this is true - large internet corporations are trying to 
move on from "IP address identifications" as in only a beginner that 
discovered the internet one week ago still thinks of the IP address as 
"identification of a certain individual / entity", everybody is moving 
to advanced layers of authentication on per device basis, cryptographic 
public key, etc. Comcast if they do such a thing they set themselves 25 
years behind the industry they operate in. And this can create many 
unwanted effects, someone should try to do something about this but I am 
not sure what we Tor volunteers *can* do to help with this, especially 
the ones that are not Comcast customers. EFF is the best start IMO.




OpenPGP_signature
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] Comcast blocks ALL traffic with tor relays

[xmrk2 via tor-relays]

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.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays