Re: [tor-relays] TorBrowser HTTPS-Only Mode

[Matthew Finkel]

On Sun, Apr 25, 2021 at 7:13 PM nusenu  wrote:
>
> > (FWIW: on the client side there is still the HTTPS-only mode in the
> > pipeline, which could easily be a game-changer here, too.)
>
> Is the torproject backporting https-only mode [1] to 78esr / Tor Browser?

No. Firefox 78esr has an older version of https-only mode, but newer versions
of Firefox have many bugfixes. We don't feel comfortable enabling the current
implementation available in Tor Browser, and backporting the fixes/improvements
would be challenging. Currently, our recommendation is enabling EASE mode in
https-everywhere if you feel comfortable with the trade-offs, but that mode has
usability issues as well, and we aren't comfortable enabling that for everyone.

When Tor Browser migrates to Firefox 91esr we will look at enabling https-only
mode for everyone, but there remains a significant concern that there are many
sites that do not support HTTPS (especially more region specific sites) and the
question of what messaging Tor Browser should use in that case.

>
> kind regards,
> nusenu
>
> [1] 
> https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/
>
>
> --
> https://nusenu.github.io
> ___
> 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] Conduct on this list

[Matthew Finkel]

Please be aware that the Statement of Values [0] and Code of Conduct [1]
apply on this mailing list (and all mailing lists provided by the Tor
Project).

This mailing list started accumulating racist slurs and other insults,
which we have held in the moderation queue. Sending a mail containing
racist epithets is absolutely not acceptable and will not be tolerated.
Racism and sexism are not welcome in this community. Future
transgressions will result in the sender being unsubscribed from the
mailing lists and reported to the community council.

Help us create an open, inclusive, and diverse community supporting
Tor's mission.

Thanks,
Matthew/sysrqb on behalf of the list moderators

[0] 
https://gitweb.torproject.org/community/policies.git/tree/statement_of_values.txt
[1] 
https://gitweb.torproject.org/community/policies.git/tree/code_of_conduct.txt
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor project helping to attempt to cancel Richard Stallman

[Matthew Finkel]

On Fri, Mar 26, 2021 at 2:49 PM William Kane  wrote:
>
> Also, more information would be nice - just some "Please shut down all
> of your relays, because I / they have a problem with X" isn't very
> descriptive.
>
> Just did some own research:
>
> "The group recently reappointed the controversial developer and
> activist to its board; he had previously departed in the wake of
> sexual-harassment allegations and comments he made about the Jeffrey
> Epstein case that many found repellent."
>
> Ah, I see, feminists and leftists must be triggered right now, but how
> does this relate to the Tor Project or Mozilla in anyway? Sure, it's
> not the best PR for both but if he's a valuable (code) contributor I'd
> let it slip - anyone remember the Freedom of speech principle?

That's unfortunate because this attitude is counter to the Tor community we are
building:
https://gitweb.torproject.org/community/policies.git/tree/statement_of_values.txt

"""
Community health is a shared responsibility. By making the community more
inclusive and welcoming, we build a stronger and more resilient Tor. Perfection
is not required; a commitment to continuous improvement and learning is.
"""

We can't simply "turn the other cheek" because we must be better than that. We
cannot let misconduct and offenses "slip" for the sake of (code)
contribution. We
do not live in a cypherpunk/meritocratic crypto-utopia of the 1990s.

>
> I thought this is why we were doing all this.

There isn't one single reason why people contribute and volunteer
within and around
the Tor community. However, that may be your reason for volunteering
your time and
resources.

>
> My relay will still stay online for the time being, but I'd seriously
> reconsider priorities here - surely, they shouldn't be political - who
> cares what anyone thinks.

I'm sorry, but Tor is actually a policy statement and its implementation:
anonymity-by-default, privacy-by-design, censorship circumvention; Tor
is not a neutral
party in the debate on free access to cryptography.

The Tor Project having (and voicing) an opinion on these topics, as
well as other topics
within the larger free software community, are not out of scope and,
this should not be
a surprise.

I hope you continue running your relay and continue supporting the Tor network
and its users. Your contribution makes the network stronger for everyone.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor project helping to attempt to cancel Richard Stallman

[Matthew Finkel]

On Thu, Mar 25, 2021 at 12:52 PM Jeffrey Cliff  wrote:
>
> I've been running a relay/exit node for many years.  Tor user since ~2004.

Thank you for running an exit node. You provided a service to
the world and likely helped millions of people.

> To the extent that my voice means anything at all here, I would like to 
> strongly condemn the Tor project joining the attempt to cancel Richard 
> Stallman.  Stallman represents software freedom to me generally and as of 
> today I will be shutting down my exit node in protest of this action by the 
> Tor Project.

Your voice is meaningful, however it is unfortunate that you are
conflating a movement and a community, with one single person.
Furthermore, that one person is toxic and diminishes the strength
and accomplishments of free software. Richard Stallman should not
represent software freedom, we shouldn't put people on pedestals
and we should hold everyone accountable for their actions. RMS
helped start the free software movement, but he is not untouchable
and now there are much better leaders who should replace him. He
is holding back the movement and no one should praise him for that.

>
> I hope the rest of you out there, who depend every day on GNU project code 
> which would not exist without RMS's project, might consider joining me.

No good actions should allow someone to perpetuate toxic behavior
and push away people in marginalized groups. I hope you reconsider
your position on this.

>
> Jeff Cliff
>
> former tor exit node admin
> ___
> 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] reporting Abusive exit nodes

[Matthew Finkel]

On Fri, Dec 4, 2020 at 4:26 AM BRBfGWMz  wrote:
>
> I frequently find abusive exit nodes. Is there any way to report these to the 
> tor consensus system, so it deprioritizes them?
>

Yes, please report them to bad-rel...@lists.torproject.org

https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays#HowdoIreportabadrelay
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] don't publish detailed metrics about your relays

[Matthew Finkel]

On Thu, Aug 20, 2020 at 8:51 PM nusenu  wrote:
>
>
> Don't publish detailed metrics about your relays.
>
>
> Here is a good example what NOT to do with your relays:
>
> http://51.77.135.89:1/#menu_net_submenu_eno1;theme=slate
> http://51.75.144.43:1/#menu_net_submenu_eno1;theme=slate
>
> The relay guide has detailed guidelines on what granularity is considered 
> safe.

In section "System Health Monitoring" on
https://community.torproject.org/relay/setup/post-install/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ALL GREYPONY SERVERS ARE OPEN FOR DDOS

[Matthew Finkel]

On Fri, May 03, 2019 at 10:27:14AM +, Stirling Newberry wrote:
> ATTENTION GREYPONY USERS
> 
> ALL GREYPONY EXITS WILL BE TARGETED FOR DDOS. THIS REQUEST HAS COME FROM 
> PRETTY HIGH UP. GAME OVER BITCHES. YOU GUYS ARE GOING TO BE DONE. LOIC WILL 
> BE USED TO TARGET THE NODES. DON'T SAY YOU WERENT WARNED YOU STUPID SACKS OF 
> FAGGOT SHIT.

Just so we all have the same understanding here, no one should send or
respond to emails like this. Just like harassment, threats (even idle
threats) are not acceptable here.

Thanks, in advance, for your decorum.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor website overhaul -- who deserves punishment?

[Matthew Finkel]

Hi Ralph,

On Wed, Mar 27, 2019 at 05:10:08PM +0100, Ralph Seichter wrote:
> Not sure if this is the right place to vent, but here goes:
> 
> Whoever changed the Tor website's design seems to a) have a serious
> vision impairment and b) done his utmost to hide access to the Tor
> source code.

Please be respectful. The tone of this message is disrespectful of the
time, effort, and skill that went into launching the new website. It's
unfortunate you do not appreciate or like the new site, but that does
not excuse you.

The source code has not moved, it is still available at
gitweb.torproject.org, as usual. If you're looking for the download
page, then there is an open bug for that, see [0].

[0] https://trac.torproject.org/projects/tor/ticket/29907

> 
> I think the site feels dumbed down to cater only to those with the
> shortest attention spans (and bad eyesight) now. Also, as a relay and
> exit operator, I care most about the source code and documentation, not
> some management summary.

Thank you for running these relay, we all appreciate it. The website,
however, is intended for a diverse audience, and most people are not
familiar with Tor. This new website is significantly better and more
welcoming for the general population, rather than a small percentage
of the population.

If you have suggestions for improving the new design, then please let us
know.

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

Re: [tor-relays] Relay without OpenSSL

[Matthew Finkel]

On Wed, Jan 30, 2019 at 05:23:40PM +0100, Nick Mathewson wrote:
> On Mon, Jan 28, 2019 at 9:52 PM Alexander Nasonov  wrote:
> >
> > I recently tried updating one of my relays to Tor 0.4.0.1 compiled
> > with NSS (and without OpenSSL) but it failed to start, see the logs
> > below. I wonder if this configuration is supported at all and
> > whether I should try running a brand new relay instead of updating?
> >
> > Alex
> 
> This warning looks like the one I added for the openssl-related bug
> #28973. But I didn't expect it to happen on NSS!  Could somebody
> please open a ticket here?  I can take a look next week, I hope.

I opened #29241 for this (because I didn't see anyone else open it).
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] maha's tor-latest on COPR?

[Matthew Finkel]

On Tue, Sep 18, 2018 at 04:35:46PM +0200, re...@mobtm.com wrote:
> Hi *,
> 
> does anyone know if maha still supports his Fedora/Epel repo for the latest 
> Tor release[1]?
> 
> I'm nearly sure he announced his repo on the list some time ago, but I don't 
> find the mail anymore...
> 
> With 0.3.3.10 (and 0.3.4.8) released and not really happy with compiling it 
> myself[2] an up to date repo for redhattish distributions would be very nice.

I don't know an answer to your question, but apparently a nice person
named Jamie is currently packaging Tor on Fedora:

https://trac.torproject.org/projects/tor/wiki/doc/packages
https://apps.fedoraproject.org/packages/tor

Maybe 0.3.3.10 will be available soon.

> 
> Thanks
> Renke
> 
> [1] https://copr.fedorainfracloud.org/coprs/maha/tor-latest/
> [2] too lazy :)
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Something strange noticed on tor metrics

[Matthew Finkel]

On Fri, Jul 27, 2018 at 04:40:46PM -0700, Keifer Bly wrote:
> 
> Hello,
> 
> So today I w as checking my relay on tor metrics 
> https://metrics.torproject.org/networksize.html
> 
> I noticed something strange, according to the graph, the number of bridges 
> seems to have suddenly completely dropped to zero (the bridges line just 
> after “2018-07”) and now slowly climbing back up. I am wondering did 
> something happen that knocked all of the bridges offline? It seemed strange 
> so I just thought I would report.

Yes, the Bridge Directory Authority changed, and Metrics only received
the bridges from one of the new bridge dirauth. Unfortunately, nearly
all of the existing bridges were still publishing to the old bridge
dirauth. As a result, Metrics saw the number of bridges drop the
approximately zero. Slowly bridges are updating and using the new
bridge dirauth instead.

[0]
https://blog.torproject.org/new-release-tor-0339-bridge-authority-update
[1]
https://lists.torproject.org/pipermail/tor-announce/2018-July/000162.html
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay Guide - IPv6 Connectivity Testing

[Matthew Finkel]

On Tue, Jun 26, 2018 at 04:31:55AM +1000, teor wrote:
> 
> On 26 Jun 2018, at 02:40, nusenu  wrote:
> 
> >> It would also be nice if the relay, itself, performed self-checks of
> >> this connectivity and printed a warning log if some failure-threshold is
> >> reached (and possibly disabling the IPv6 ORPort). But, in reality, this
> >> is a hack 
> > 
> > I wouldn't call it a 'hack', I'd consider it a reliability feature.
> 
> Relays already check that their IPv4 ORPorts are working.
> 
> Doing reachability checks for relay IPv6 ORPorts is a bit more
> complicated, because we have to teach relays to extend over IPv6 first.
> 
> Here's the master ticket:
> https://trac.torproject.org/projects/tor/ticket/24403
> 
> And if relays use authority IPv6 ORPorts to upload descriptors, they
> will get connectivity checks for free:
> https://trac.torproject.org/projects/tor/ticket/24777

Good point (and I agree). I'll stopping opening a separate ticket for
this. Thanks!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay Guide - IPv6 Connectivity Testing

[Matthew Finkel]

On Mon, Jun 25, 2018 at 04:40:00PM +, nusenu wrote:
> > Considering there are potential critical failures when the IPv6 ORPort
> > is configured, should the relay guide suggest the operator confirm they
> > have IPv6 connectivity to all of the IPv6-enabled directory
> > authorities[2] before enabling it ("Please ping6/telnet/nc to these
> > hosts before enabling this.")?
> 
> thanks for this suggestion, I hope you like the change:
> 
> https://trac.torproject.org/projects/tor/wiki/TorRelayGuide?action=diff=218

That change looks great, thanks!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Relay Guide - IPv6 Connectivity Testing

[Matthew Finkel]

Over the last few days I've started thinking more about IPv6 and,
inevitably, I started thinking about how we can improve support within
the Tor network.

Within the last few months, there were a few instances of relay
operators seeking answers for why their relay did not have the running
flag in the consensus. After some investigation, in some cases this was
because the relay had an IPv6 ORPort configured but a majority of the
IPv6-enabled directory authorities did not believe it was running.

Unfortunately, despite IPv6 connectivity being a necessity now, ISP
rollout is slow and on-going in some geographical areas and network
peering arrangements are sometimes sub-standard or not stable.

The Relay Guide[0] has a section describing how an operator can enable
an IPv6 ORPort, and there's a supplementary page[1] specifically
describing additional information about it.

Considering there are potential critical failures when the IPv6 ORPort
is configured, should the relay guide suggest the operator confirm they
have IPv6 connectivity to all of the IPv6-enabled directory
authorities[2] before enabling it ("Please ping6/telnet/nc to these
hosts before enabling this.")?

It would also be nice if the relay, itself, performed self-checks of
this connectivity and printed a warning log if some failure-threshold is
reached (and possibly disabling the IPv6 ORPort). But, in reality, this
is a hack around a broken internet - and I hesitate advocating for
something like this in tor. Maybe there is a compromise we can find
between the relay operator manually testing connectivity periodically
and tor automatically doing-smart-things.

Thoughts?

- Matt

[0] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#IPv6
[1] https://trac.torproject.org/projects/tor/wiki/doc/IPv6RelayHowto
[2] https://gitweb.torproject.org/tor.git/tree/src/or/auth_dirs.inc
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Verizon AS701 blocking Tor consensus server tor26 (86.59.21.38)

[Matthew Finkel]

On Wed, May 16, 2018 at 11:36:58AM -0400, Nathaniel Suchy (Lunorian) wrote:
> If Verizon is suddenly worried about malware, why not block at the DNS level 
> with something like Quad9 where it’s managed by more competent professionals? 
> (Of course still allowing alternate DNS Servers)

They probably do this, too.

> Does Tor bootstrap by IP Address directly?

Yes

> 
> Sent from my iPhone
> 
> > On May 16, 2018, at 11:32 AM, Alex Xu  wrote:
> > 
> > Quoting Roger Dingledine (2018-05-16 15:05:29)
> >> The fix (if my theory is right) would be to reach whatever engineer made
> >> this leap, and teach them about Tor. But it will be extra challenging
> >> because they don't even know that there's something they need to learn.
> > 
> > like the fact that malware can have more than one C server? :/
> > ___
> > 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] Verizon AS701 blocking Tor consensus server tor26 (86.59.21.38)

[Matthew Finkel]

On Wed, May 16, 2018 at 11:33:54AM -0400, Nathaniel Suchy (Lunorian) wrote:
> Can you still use Tor on Verizon with bridges?

This is only one of the directory authorities. A tor client using
Verizon may never notice they can't reach this one server.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Verizon AS701 blocking Tor consensus server tor26 (86.59.21.38)

[Matthew Finkel]

On Tue, May 15, 2018 at 08:12:50PM -0400, Neel Chauhan wrote:
> Hi tor-relays mailing list,
> 
> I have noticed that the Tor consensus server tor26 
> (https://metrics.torproject.org/rs.html#details/847B1F850344D7876491A54892F904934E4EB85D)
> is blocked on Verizon's UUNET (AS701) backbone, and therefore, Verizon's
> retail services like FiOS and Wireless. I can confirm this on FiOS, but I
> don't use Verizon Wireless (my smartphone uses Sprint) so I can't test it
> there.
> 
> A traceroute to tor26's IP address 86.59.21.38 from a Brooklyn apartment
> shows this is filtered on Verizon's backbone:

Interesting, thanks for noticing this and investigating.

From an Optimum Online connection I can reach tor26:

$ traceroute -n 86.59.21.38
traceroute to 86.59.21.38 (86.59.21.38), 30 hops max, 60 byte packets
[...]
 9  * * *
10  4.69.203.210  87.969 ms  93.582 ms  90.246 ms
11  4.68.110.66  91.896 ms  89.551 ms  87.997 ms
12  130.244.38.232  89.958 ms  94.470 ms  95.286 ms
13  130.244.71.47  132.933 ms  131.108 ms  131.941 ms
14  212.152.189.65  132.910 ms  128.954 ms  149.351 ms
15  86.59.118.145  110.832 ms  111.453 ms  112.767 ms
16  86.59.21.38  116.790 ms  117.539 ms  117.448 ms

> In a normal traceroute, you will see ALTER.NET at hop 5. Also, the subnet
> 86.59.21.0/24 is not filtered on UUNET. A traceroute to 86.59.21.1 works:
>

I also receive a response from the IP address immediate below tor26's:

$ traceroute -n 86.59.21.37
traceroute to 86.59.21.37 (86.59.21.37), 30 hops max, 60 byte packets
[...]
 9  * * *
10  4.69.203.210  88.174 ms  92.438 ms  92.715 ms
11  4.68.110.66  90.381 ms  89.487 ms  89.491 ms
12  130.244.38.232  92.294 ms  91.150 ms  93.985 ms
13  130.244.71.47  131.010 ms  131.173 ms  131.000 ms
14  212.152.189.65  131.932 ms  130.328 ms  136.155 ms
15  86.59.118.145  261.323 ms  261.824 ms  261.783 ms
16  86.59.21.37  122.162 ms  121.369 ms  118.289 ms
 
> I got in contact with Peter Palfrader and he says he couldn't help, and also
> with Verizon FiOS support and they said the filtering 'isn't on Verizon's
> network' (read: isn't on Verizon's internal FiOS network but still on
> Verizon's AS701 which I have to go to to get anywhere on the Internet here).

Unfortunately, no surprises there. Peter won't have any control over
this, and FiOS won't take the blame for this.

> But if Verizon didn't unblock tor26, could it actually mean that Verizon
> wants to discourage Tor (and VPN/proxy) use to try to mine information of
> their customers (and sell ads/information) and direct users to VZ-owned AOL
> and Yahoo? Well, I hope they were just sloppy and don't mean to wage war on
> Tor.

Yeah, either they don't understand how Tor works, or they blocked
tor26's IP address for another reason (not because it's a directory
authority).

> 
> While I'm not saying you should avoid using anything Verizon at all costs (I
> certainly wouldn't want to go to the local cable company), I just want to
> point out a blocked consensus server.

It's absolutely something we should keep an eye on, especially in the US
as ISPs begin testing the FCC's (reinstated) laissez faire policy.

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

Re: [tor-relays] lets stop using central big DNS resolvers (Google, Level3, OpenDNS, Quad9, Cloudflare)

[Matthew Finkel]

On Fri, May 11, 2018 at 10:54:06PM -0500, Andrew Deason wrote:
> On Thu, 10 May 2018 22:37:00 +
> Tyler Durden  wrote:
> 
> > All our nodes are using a local DNS caching server and only use google
> > as a fallback.
> 
> I was also using google just as a fallback; I've now changed my node to
> just use a local resolver, with no fallback.

Thank you!

> 
> Neither the email from nusenu nor the documentation pointed to actually
> says which of these options is preferable. If you (nusenu) are looking
> to reduce the exits using these resolvers, I'd suggest explicitly also
> saying to not use them even as a fallback after a local resolver
> (assuming that's what you want). Maybe you had intended this to come
> across with the existing text, but I don't think it's obvious enough.

But isn't that what the subject line says? And the original email
contains:

> The goal is to be bellow the following thresholds within one year:
>   not have any single remoteAS entity control more than 10% exit capacity
>   reduce the overall remoteAS share to bellow 20% exit capacity

Maybe it would help clarifying that almost any use of the above
mentioned Open DNS resolvers qualifies as using a remoteAS (therefore
contributing to its control of exit capacity) - even if that resolver is
configured as a fallback.

Thanks again for adjusting your configuration.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] PSA regarding Quad9 DNS Resolver

[Matthew Finkel]

On Fri, May 11, 2018 at 07:41:45AM -0400, Nathaniel Suchy (Lunorian) wrote:
> Like OpenDNS, Quad9 is a censoring DNS resolver and exits using it are / 
> should be considered bad exits. I haven’t seen any exits using it yet however 
> I thought I’d bring it up. Thoughts?

Yes, but nusenu's email is the better course of action. Using Quad9 is
one of the examples listed on the wiki page for why a relay is marked as
a badexit [0], but if the operator can simply change their
configuration then that is a significantly better solution.

[0] https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Metrics not functioning?

[Matthew Finkel]

On Sat, Apr 14, 2018 at 10:30:54AM +1000, teor wrote:
> 
> > On 14 Apr 2018, at 09:48, Matthew Glennon  wrote:
> > 
> > Are the right people aware that Metrics has been like this for most of the 
> > day? No matter what relay you look for it claims old data.
> > https://metrics.torproject.org/rs.html#details/9695DFC35FFEB861329B9F1AB04C46397020CE31
> 
> Yes, but it's their weekend, so it might take a while.

And that issue is resolved now (but I didn't do it).
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Port not rechable

[Matthew Finkel]

Hi!

On Fri, Mar 02, 2018 at 09:34:02PM +0100, peter.zehet...@liwest.at wrote:
> OK, now I've set PortForwarding in Tor-Arm from "False" to "True", then 
> restarted Tor:

Hrm, I'm not sure this will do what you want. In fact, this may do
absolutely nothing. Do you have administative access into your network
router? Maybe there is a website interface you used. This is where you
should configure port forwarding. Unfortunately this is complicated and
not easy plug-n-play.

> 
> ...has not managed to confirm that its DirPort is reachable. Relays do not 
> publish descriptors until their ORPort and DirPort are reachable. Please 
> check...
> 
> I'm going to run a non-exit-relay and I'm going to do this at home.
> 
> Peter
> 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Running a relay at home (was: Port not rechable)

[Matthew Finkel]

On Fri, Mar 02, 2018 at 03:01:31PM -0500, Roger Dingledine wrote:
> On Fri, Mar 02, 2018 at 07:42:11PM +0000, Matthew Finkel wrote:
> > Are you running this relay at your home? If yes, then that is not
> > recommended, but
> 
> For the record, it's running *exit* relays at home that is not
> recommended. Running non-exit relays at home is typically fine -- the
> most likely problems are that some overzealous blacklist will put your
> IP address on their list, making some websites not work so well for you
> if you also use that IP address for your own traffic. Some of these
> overzealous blacklists are just being stupid, because they don't
> understand about exit policies:
> https://www.torproject.org/docs/faq#ExitPolicies
> but others of them are intentionally trying to harm people who are
> trying to support Tor:
> http://paulgraham.com/spamhausblacklist.html

Just for the record, this is exactly why I don't recommend it from my
exerience. I lost access to my bank's website (plus some other sites)
for a while because I did this. It's must less risky running a non-exit
than running an exit, but there may be unintended side effects that make
the experience less fun overall for the operator.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Port not rechable

[Matthew Finkel]

On Fri, Mar 02, 2018 at 08:27:29PM +0100, peter.zehet...@liwest.at wrote:
> Hi, I'm still trying to run a tor delay. Here's the error:
> 

Thank you for running a relay.

> Your server (81.10.248.112:80) has not managed to confirm that its DirPort is 
> reachable. Relays do not publish descriptors until their ORPort and DirPort 
> are reachable.

I do not see port 80 open, either:

$ torsocks nc -v 81.10.248.112 80
Ncat: Version 7.40 ( https://nmap.org/ncat )
Ncat: Connection timed out.

> 
> But canyouseeme.org said: Your ISP is not blocking port 80

Maybe "not blocking" does not mean "is open".

Are you running this relay at your home? If yes, then that is not
recommended, but you may need to allow port 80 on your firewall/router.
You may need to use port forwarding or add your computer into the DMZ
(if your router supports this).

If you're not running this relay from home, is the server directly
connected to the Internet or is there a router/switch/blackbox in the
middle?

> 
> Whats's wrong?
> 
> Thanks
> 
> Peter

> ___
> 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] Is there a reason for all exit nodes being public?

[Matthew Finkel]

On Wed, Dec 07, 2016 at 02:25:03PM +0200, Rana wrote:
> 
> On Wed, Dec 07, 2016 at 11:51:34AM +, Matthew Finkel wrote:
> >> On Wed, Dec 07, 2016 at 01:25:59PM +0200, Rana wrote:
> >> > I mean, why aren't some exit nodes kept hidden, at least partially 
> >> > and temporarily, like bridges? This would mitigate web services 
> >> > denying service to Tor users (Gmail is the most recent example), 
> >> > plus would increase security.
> >> 
> > I'll simply refer you to the FAQ:
> 
> >That was rude of me, answer below. Do you disagree with the reasoning?
> 
> That was not rude at all, thank you for the reference to the FAQ. I largely 
> got a satisfactory explanation there although points (b) and (c) might be 
> controversial. 
> 
> The one point I find difficult to agree with is "(a) We can't help but make 
> the information available, since Tor clients need to use it to pick their 
> paths." If bridges can be hidden and provided to clients on as-needed basis, 
> so can exits.

Yes, this is true, and it's a topic that comes up every couple years. But,
there are significant differences between bridges and exits. First, choosing
your circuit's exit manually is a usability nightmare and could destroy your
anonymity. Even if you give your tor client a small set of "hidden" exits,
over time traffic from these nodes will be linked to your connections and they
will be linked to Tor. It's not easy for users know when this happens. Tor
tries extremely hard at preventing users from hurting themselves.

Research has shown that bridges (and guards) should be used for longer periods
of time, but if you use an exit for too long then you risk leaking too much
information about your behavior (to both the exit and the destination server).

Similarly, using a hidden exit becomes more risky if the user is already using
a bridge because there is (currently) less oversight of the bridges than there
is for the public network. This would likely be true for hidden exits, as well.
This presents the problem that traffic analysis attacks against a small subset
of Tor users become incredibly easy.

When it comes to hidden nodes, they never remain hidden forever. Some
adversaries already crawl the list of bridges and block them, other adversaries
would do the same if some exit nodes were not public.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Is there a reason for all exit nodes being public?

[Matthew Finkel]

On Wed, Dec 07, 2016 at 11:51:34AM +, Matthew Finkel wrote:
> On Wed, Dec 07, 2016 at 01:25:59PM +0200, Rana wrote:
> > I mean, why aren't some exit nodes kept hidden, at least partially and
> > temporarily, like bridges? This would mitigate web services denying service
> > to Tor users (Gmail is the most recent example), plus would increase
> > security.
> 
> I'll simply refer you to the FAQ:

That was rude of me, answer below. Do you disagree with the reasoning?


  *You should hide the list of Tor relays, so people can't block the exits.*
  There are a few reasons we don't:

a. We can't help but make the information available, since Tor clients
need to use it to pick their paths. So if the "blockers" want it, they can
get it anyway. Further, even if we didn't tell clients about the list of
relays directly, somebody could still make a lot of connections through Tor
to a test site and build a list of the addresses they see.

b. If people want to block us, we believe that they should be allowed to do
so. Obviously, we would prefer for everybody to allow Tor users to connect
to them, but people have the right to decide who their services should
allow connections from, and if they want to block anonymous users, they can.

c. Being blockable also has tactical advantages: it may be a persuasive
response to website maintainers who feel threatened by Tor. Giving them the
option may inspire them to stop and think about whether they really want to
eliminate private access to their system, and if not, what other options 
they
might have. The time they might otherwise have spent blocking Tor, they may
instead spend rethinking their overall approach to privacy and anonymity.


> 
> https://www.torproject.org/docs/faq.html.en#HideExits
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Is there a reason for all exit nodes being public?

[Matthew Finkel]

On Wed, Dec 07, 2016 at 01:25:59PM +0200, Rana wrote:
> I mean, why aren't some exit nodes kept hidden, at least partially and
> temporarily, like bridges? This would mitigate web services denying service
> to Tor users (Gmail is the most recent example), plus would increase
> security.

I'll simply refer you to the FAQ:

https://www.torproject.org/docs/faq.html.en#HideExits
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Faravahar messing with my IP address

[Matthew Finkel]

On Sat, Oct 24, 2015 at 03:09:00AM +0300, s7r wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hello,
> 
> Unfortunately this is not the first time we see this, and it did
> happen before Faravahar IP address change and before it was
> experiencing very high latency (
> https://trac.torproject.org/projects/tor/ticket/17338 ).
> 
> See:
> https://trac.torproject.org/projects/tor/ticket/16205#comment:3
>  ~5 months ago

See another recent instance [0]. This one is interesting, though, because
it's actually Faravahar's old IP address.

For those who see this happening, do you only see these log entries for a
short time after starting the relay or do you see it at arbitrary times,
after the relay has run for days?

Thanks,
Matt

[0] https://lists.torproject.org/pipermail/tor-relays/2015-November/008128.html
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Wrong IP from faravahar again

[Matthew Finkel]

On Mon, Nov 09, 2015 at 06:34:21AM +, Pascal Terjan wrote:
> Nov 04 17:06:00.000 [notice] Our IP Address has changed from
> 149.18.2.82 to 154.35.32.5; rebuilding descriptor (source:
> 154.35.175.225).
> Nov 04 17:08:55.000 [notice] Our IP Address has changed from
> 154.35.32.5 to 149.18.2.82; rebuilding descriptor (source:
> 154.35.175.225).
> 
> 5.32.35.154.in-addr.arpa domain name pointer faravahar.rabbani.jp.

Thanks! It'll be easier if we keep a single thread for this issue,
so I responded to the older mails about it. Please feel free to
respond to those again if you have more helpful info.

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

Re: [tor-relays] Faravahar messing with my IP address

[Matthew Finkel]

On Wed, Nov 04, 2015 at 08:00:52AM +0100, Logforme wrote:
> Happened again tonight:
> 
> Nov 04 05:23:43.000 [notice] Our IP Address has changed from
> 84.219.173.60 to 185.99.185.61; rebuilding descriptor (source:
> 154.35.175.225).
> Nov 04 05:23:43.000 [notice] Self-testing indicates your ORPort is
> reachable from the outside. Excellent. Publishing server descriptor.
> Nov 04 05:23:43.000 [notice] Our IP Address has changed from
> 185.99.185.61 to 84.219.173.60; rebuilding descriptor (source:
> 154.35.175.225).
> Nov 04 05:23:43.000 [notice] Self-testing indicates your ORPort is
> reachable from the outside. Excellent. Publishing server descriptor.
> 
> 84.219.173.60 <- My real IP address
> 185.99.185.61 <- Holland?
> 154.35.175.225 <- faravahar.redteam.net
> 
> Not even a second between getting the wrong IP and then getting the
> correct one back, but enough to restart the relay.
> After seeing this I upgraded to the latest version 0.2.7.4-rc and on the
> restart it again used Faravahar to (correctly) guess the IP:
> 
> Nov 04 07:47:49.000 [notice] Guessed our IP address as 84.219.173.60
> (source: 154.35.175.225).

Which version of Tor were you previously running? Have you seen these
messages within the last few days, after you upgraded?

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

Re: [tor-relays] T-shirts and Confirming Relay Control

[Matthew Finkel]

On Tue, May 05, 2015 at 01:57:04PM +, Speak Freely wrote:
 Matthew Finkel,
 
 It's kind of disingenuous to suggest If you want to work on something,
 then please come work on it, we really are overloaded.
 

I'm really sorry you interpretted it in that way. It actually was a
genuine request for more help.

 You have to let us work on it, for us to work on it. Do you understand
 the problem?

Sure, that is a problem, but what is the problem? It seems this dilemma
is reoccurring and not getting solved. Someone says they are willing to
help work on something, possibly someone else says great! we need your
help! then nothing happens. Was it an empty offer or did the offer die
because no one followed up with the person? Having a volunteer
coordinator might help - I hope it would help - but what's the best way
to organize that? Is it the responsibly of some people associated with
The Tor Project to follow up on every offer they receive or is it the
responsibility of the person who made the offer to follow up and get
involved? Maybe both?

 
 To The Inner Circle (The Tor Project People),
 
 I am at the very least the third person to mention in this thread that
 we have offered to help. No one responded to my offers. I'm pretty sure
 at least some of their offers were ignored as well, though I can't be
 bothered to double check.

:( I don't know. Obviously, not receiving a response sucks. I completely
understand that. Tor's work and day-to-day coordination is heavily based
around IRC, so the mailing lists are not great places for offering help.

This whole situation seems to be less about an inner circle existing,
and more about a disconnection between the announcements and discussions
on the mailing lists and what happens on IRC. I don't know of a good way
to bridge this gap, though.

 
 I get that you're busy. However, Matthew's attitude to Seth is, in my
 most humble of opinions, unwarranted.


We're all busy, it's difficult balancing everything. I'm sorry if my
response was unwarranted, and maybe I shouldn't have responded because
it was off-topic, in any case. It's frustrating trying to do something
and improve a situation, and instead of receiving helpful feedback the
thread receives complaints about how Tor is crappy with how it handles
volunteers. Maybe this is partially due to miscommunication but I'm at
a loss for what to do.

 You've got several people who out of their own free will, decided to
 offer our additional help, above and beyond what we already do.
 
 I wonder, how would you feel, if after offering free assistance to a
 community that then goes completely, totally, and utterly UNANSWERED,
 only to have those very people that we offered to assist, bitch that
 they are busy and want our help. How would you feel?
 Angry? A little schadenfreude? Or numb?
 
 I'm a husband, a father, and a business owner. I'm a busy guy, yet I
 still offered to help. I can't express how pissed off I am about this,
 without going into a obscenity-laced tirade about how your house isn't
 in order.
 
 When I offer assistance to someone, or in Tor's case several people, I
 damn well expect a response. Yes or no, thanks or fuck off,
 please or tomorrow, join us! or maybe next time.
 
 Deafening silence is in no way a mechanism that encourages support from
 the broader community, but from my perspective that's all you've given.
 

Thanks.


Obviously you're correct, silence is not an answer and not what you
deserve as a result of offering your assistance. I don't know why this
happened or the context of the offer but, to be blunt, Tor doesn't
babysit volunteers. If you want to work on something, then, you must
actually follow through and work on it. I learned this personally. A
volunteer coordinator would be a great person for helping volunteers
become more integrated into the community and work on projects but it
is ultimately the person volunteering who decides how, when, and if
they help.

Tor wants your help, but becoming an active volunteer is your decision.

 
 Here's a suggestion to The Inner Circle
 - Have a volunteer coordinator that actually responds to people.
 
 This way, when the next person offers to help, they might actually get a
 good g*d d@mn f@cking response!
 

Yes, this sounds like a good idea. Who wants to volunteer to be the
volunteer coordinator? Again, that is a genuine question. No one has
stepped up to do it. If we had one, at least they would respond to most
offers.

 
 Seeing as how I'm a nobody and my offers aren't worth acknowledging,
 please continue to do whatever you'd like, with *all* the success it
 brings. Don't forget to smile.
 

Being a nobody or being a somebody is irrelevant. I'm a nobody too, but
I'm trying to do something. I sincerely hope you and the rest of the
community will help me and Tor, as a whole, create a better
community/network/world.

Let's continue this discussion in a new thread.

Thanks,
Matt
___
tor-relays mailing

[tor-relays] T-shirts and Confirming Relay Control

[Matthew Finkel]

Hi Ops,

We recently began responding to t-shirt requests again. Sorry for the
long silence. There's been a lot happening around here but not enough
time or people to do everything, so the t-shirt requests simply remained
untouched. But, despite the overload, t-shirts are important because
they are a small token of our thanks and appreciation for making the
network what it is today.

We responded to around 70 t-shirt requests from relay operators in
April, which comprised all requests for which we could verify (within
reason) the request came from the person who controlled the qualifying
relay. We still have another 20 requests where the requestor is not
obviously the owner of the relay. Currently the content of a relay's
Contact field is used, but this does not always provide enough (or any)
information. For this case, we need an authentication mechanism which
proves control of the relay but is something relay operators won't mind
running.
 
My currently plan is to ask relay operators to sign the fingerprint file
which tor creates. The major disadvantage of this method is that it must
be run as root (or a user with access to tor's data directory).

The following process is the current plan, but does anyone have a better
idea? Does it seem logical?


When we receive a t-shirt request from someone who isn't obviously in
control of the relay, we ask them to sign their fingerprint file with
a unique salt.

Assuming the path to their data dir is /var/lib/tor, we ask them to run:

$ (echo -n salt ; cat /var/lib/tor/fingerprint) | openssl sha256 \
  -binary | openssl pkeyutl -inkey /var/lib/tor/keys/secret_id_key \
  -sign -pkeyopt digest:sha256 -pkeyopt rsa_padding_mode:pss \
  -pkeyopt rsa_pss_saltlen:32 | openssl base64  signed_fingerprint

They send us both /var/lib/tor/fingerprint and signed_fingerprint.

When we receive them, we confirm the fingerprint in the fingerprint file
matches the qualifying relay. Then we retrieve the relay's public key
from its descriptor and convert it into pkcs#8 format using:

$ openssl rsa -pubin -in pubkey_pkcs1 -RSAPublicKey_in -out pubkey

and then we verify the sig using following commands:

$ (echo -n salt ; cat fingerprint) | openssl sha256 -binary | \
  openssl pkeyutl -pubin -verify -inkey pubkey -sigfile \
  $(OUT=/tmp/signed_fingerprint_bin; base64 -d signed_fingerprint  \
  ${OUT}; echo ${OUT}) -pkeyopt digest:sha256 -pkeyopt \
  rsa_padding_mode:pss -pkeyopt rsa_pss_saltlen:32; rm \
  /tmp/signed_fingerprint_bin;

This should yield Signature Verified Successfully.



Another disadvantage of this is PSS wasn't implemented in openssl's
apps until 1.0.1. I wonder how many relays are running on servers which
are still using openssl 0.9.8 (and 1.0.0?). For these servers we can
fallback on pkcs#1 v1.5 signatures.



The signature can be created using a command similar to the one above:

$ (echo -n salt ; cat /var/lib/tor/fingerprint) | openssl dgst \
  -sha256 | openssl rsautl -inkey /var/lib/tor/keys/secret_id_key \
  -sign | openssl base64  signed_fingerprint

Again, they provide /var/lib/tor/fingerprint and signed_fingerprint,
and we verify using:

$ test $(openssl base64 -d -in signed_fingerprint | openssl rsautl \
  -pubin -verify -inkey pubkey) = $((echo -n salt ; cat \
  fingerprint) | openssl dgst -sha256); echo $?


In addition, again, we confirm the fingerprint in the fingerprint file
matches the fingerprint of the qualifying relay.


Originally I used a few bashisms which made these simpler, but for
this I suspect portability is important.

Sorry this is a bit long.

Thanks,
Matt



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

Re: [tor-relays] T-shirts and Confirming Relay Control

[Matthew Finkel]

On Sun, May 03, 2015 at 12:05:49PM -0700, Aaron Hopkins wrote:
 On Sun, 3 May 2015, Matthew Finkel wrote:
 
 Assuming the path to their data dir is /var/lib/tor, we ask them to run:
 
 Please don't get in the habit of asking relay operators through e-mail to
 run complex bash command lines as root.  As a security practice, this is
 terrible.  (How do you know the suggested command wasn't altered before it
 reached its recipient?)

Yes, this is terrible, and I really hate the idea of asking it. I signed
all my emails for the t-shirt requests, but now we're relying on
everyone fetching my key and verifying the mail - so, that's also a bad
assumption. I don't have a good solution. This is why I'm asking.

 
 If you want to build a utility for this into the tor distribution, and make
 it obvious what it does, I think that's fine.  If the site asked people to
 run tor-request-tshirt or more generically tor-verify-ownership and it
 asked for whatever required information, I'd think that'd be more obviously
 safe.

Unfortunately, for something like that to work seamlessly, it would
need to be setuid or setgid. This may be a better way forward, but I
wonder what we can do now.

 
 Or as Robert suggests, just send verification mail to the listed contact
 address of the relay.  If they don't list one on their config, find an
 alternate verification mechanism like e-mailing whois contacts for the IP or
 domain name, or refuse the request.

I'd prefer not denying them a t-shirt because they don't want to publish
an email address publically, but using whois seems like a stretch and
usually ends at the hosting provider instead of the operator.

Thanks for the idea.

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

Re: [tor-relays] T-shirts and Confirming Relay Control

[Matthew Finkel]

On Sun, May 03, 2015 at 09:18:30PM +0200, Sebastian Urbach wrote:
 On May 3, 2015 7:45:39 PM Matthew Finkel matthew.fin...@gmail.com wrote:
 
 Hi Matthew,
 
 Hi Ops,
 
 We recently began responding to t-shirt requests again. Sorry for the
 long silence. There's been a lot happening around here but not enough
 0 time or people to do everything, so the t-shirt requests simply remained
 untouched. But, despite the overload, t-shirts are important because
 they are a small token of our thanks and appreciation for making the
 network what it is today.
 
 We responded to around 70 t-shirt requests from relay operators in
 April, which comprised all requests for which we could verify (within
 reason) the request came from the person who controlled the qualifying
 relay. We still have another 20 requests where the requestor is not
 obviously the owner of the relay. Currently the content of a relay's
 Contact field is used, but this does not always provide enough (or any)
 information. For this case, we need an authentication mechanism which
 proves control of the relay but is something relay operators won't mind
 running.
 
 I'm really not amused. As i recall a bunch of people including myself
 offered to help. 

Amused? This really has nothing to do with amusement. If you want to
work on something, then please come work on it, we really are
overloaded. That being said, correctly handling t-shirt requests and
other similar communications is important and delicate. The Tor Project
is in a difficult situation where it wants to support the Tor network
but not run it. This means, to some extent, we become a trusted
third-party with some information. T-shirt requests are a perfect
example of this, where we receive requests from people who choose not
to publically publish their contact details yet they would like a reward
for their work - which they absolutely deserve. This requires that
operators trust us, so letting anyone help take care of these requests
is not wise.

 I get the distinct impression that you keep everything
 within a small circle of people, no matter what. Even if that means that
 services are suffering.
 

We're a group of security and privacy conscious individuals who want
a world where everyone has secure and private communications, this isn't
exactly a good combination which leads to publically discussioning
everything. I certainly admit sometimes I default to discussing topics
privately rather than sending it to tor-talk or tor-relays - I nearly
did that with this thread. It's a bad habit, but it's not as common as
I think you think it is.

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

Re: [tor-relays] T-shirts and Confirming Relay Control

[Matthew Finkel]

On Sun, May 03, 2015 at 03:31:01PM -0700, Tom van der Woerdt wrote:
 Matthew Finkel schreef op 03/05/15 om 14:47:
 On Sun, May 03, 2015 at 08:20:54PM +, Matthew Finkel wrote:
 On Sun, May 03, 2015 at 12:05:49PM -0700, Aaron Hopkins wrote:
 On Sun, 3 May 2015, Matthew Finkel wrote:
 
 Assuming the path to their data dir is /var/lib/tor, we ask them to run:
 
 Please don't get in the habit of asking relay operators through e-mail to
 run complex bash command lines as root.  As a security practice, this is
 terrible.  (How do you know the suggested command wasn't altered before it
 reached its recipient?)
 
 Yes, this is terrible, and I really hate the idea of asking it. I signed
 all my emails for the t-shirt requests, but now we're relying on
 everyone fetching my key and verifying the mail - so, that's also a bad
 assumption. I don't have a good solution. This is why I'm asking.
 
 
 What if we add the commands to the t-shirt[0] website? Again, this isn't
 a great solution, but we already have documentation which requires
 running commands with elevated privileges on there, and it's slightly
 better than sending it in an email. These commands are still more
 complex than I'd like, but if beside providing an executable or
 verifiable shell script, I'm running low on solutions.
 
 [0] https://www.torproject.org/getinvolved/tshirt
 
 Thanks,
 Matt
 
 Hi Matt,
 
 How about :
 
  * Primarily using ContactInfo for the verification
  * If you cannot match the ContactInfo, ask people to set it on their relays

Sounds good.

  * If they are unwilling/unable to do so, ask them to sign their mail
 address using their secret Tor key

How? For the short-term, do you think asking the operator to run the
proposed command is not a crazy idea?

  * Implement a --sign option for Tor 0.2.7
  * Starting a year from now, just ask everyone to sign the request

We'd need more than a year for this, likely four years, at the earliest
because Jessie only has 0.2.6.

 
 Proving ownership of a Tor relay can be relevant for more applications than
 just Weather, so a simple --sign option can be good to have. That doesn't
 address the immediate concerns though, it's more of a long-term solution.

I think this may be a good idea, especially if CAs being issuing certs
for onion sites. Implementing it will not be too difficult,
unfortunately its usability may be a little tricky.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] T-shirts and Confirming Relay Control

[Matthew Finkel]

On Mon, May 04, 2015 at 12:46:01AM +0200, Markus Hitter wrote:
 Am 03.05.2015 um 22:49 schrieb Matthew Finkel:
  This requires that
  operators trust us, so letting anyone help take care of these requests
  is not wise.
 
 Maybe I'm unique with this opinion, but usually I trust groups open to 
 helping hands more than those who consider them selfs to be wiser than the 
 average.
 

I don't think what I said contradicts this. You are certainly not alone
with that opinion and we, the thousands of people in the Tor community,
make Tor what it is. There is a smaller subset of the community which
handles some personal information, and, as it turns out, most people
prefer only revealing their information to a few people instead of
thousands. Hopefully we will move toward an automated system for these
t-shirts, so that the only people in the trusted-set are those who pay
for the t-shirts, in this case. But, in general, when dealing with
finances and PII, there's certain information that should remain
private. That being said, we want more people to help us. Please, come
work on some of Tor's projects. We want more review, more input, more
feedback. I was not saying we were wise because we aren't 100% public
and transparent with what we do. I was saying revealing the personal
information about operators to random, unvetted volunteers was not
wise - I hope this makes sense.

  We're a group of security and privacy conscious individuals who want
  a world where everyone has secure and private communications, this isn't
  exactly a good combination which leads to publically discussioning
  everything.
 
 Sounds almost like the advertising from companies which try to sell their 
 closed source software as the most secure thing since the invention of sliced 
 bread.

Heh. Good thing that wasn't an advertisement and Tor is not a company
selling closed-source software :)

 
 Of course it's not a good idea to publish the addresses of the t-shirt 
 receivers, neither to email them randomly around the globe, but printing a 
 hundred stickers and placing them on as many bags also isn't something which 
 keeps a group of people busy for months.

Absolutely, but what's the cost? Our current solution using Printfection
is neither ideal nor cheap, but it is convenient. Tor pays Printfection
a bunch of money and Printfection creates the t-shirts, gives us
one-time links, and takes care of the shipping and handling. If we crowd
sourced creating bags with stickers in them we would need someone who
can organize all the volunteers, ship the bags and stickers around the
world, pay the return shipping for the filled bags, and then ship them
again to the relay operators. That seems like it will become expensive.
I would love to find a better solution than Printfection, so if anyone
has suggestions we'd love to hear about it.

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

Re: [tor-relays] T-shirts and Confirming Relay Control

[Matthew Finkel]

On Sun, May 03, 2015 at 06:17:20PM -0400, JovianMallard wrote:
 Matt,
 
 Inspired by the options to confirm domain ownership with Google,
 Could you ask the relay operator to include a randomly generated (by
 you) token in their contact field? It may take a while to propagate and
 it requires action on the operator's part, but it's not difficult and I
 expect it provides the assurance you need.
 

Thanks for the suggestion! I did consider this and other similar
methods. The major disadvantage I see with this one is that there will
be a historical record of when the operator requested a t-shirt. Maybe
this doesn't matter, though. It's probably a better option than some
of the others.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] T-shirts and Confirming Relay Control

[Matthew Finkel]

On Sun, May 03, 2015 at 10:26:52AM -0800, I wrote:
 Matt,
 
 Thanks for handling the backlog of t-shirts as they are important as an 
 acknowledgement of valuable contributions.
 
 Isn't the value of the t-shirt disproportionate to the trouble you're going 
 to to give them out?
 If the weather message offering the t-shirt is answered by the same address 
 isn't that proof enough?
 
 As I haven't received a message yet and my details are plain and simple I 
 wonder what could have gone wrong.

Hi Robert,

I replied privately about your situation but it's possible this plan is
more complicated than it needs to be. In general, I'd prefer we receive
t-shirt requests from the same email address as is specified in the
Contact field. Obviously, if they are different, we can always send the
response and t-shirt link to the address in the Contact field, but that
asymmetry seems weird to me, but I'm not against doing this.

For the situations where there is no email address in the contact field,
I'm not certain how else we can confirm we're sending the t-shirt to the
person who deserves it.

Thanks for your input!

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

Re: [tor-relays] Tor-Tshirts

[Matthew Finkel]

On Sun, Mar 22, 2015 at 09:02:04AM -0800, I wrote:
 
 Would you look at how or when the second design which Jacob wears would be 
 available again, please?

Do you have an example of the second design?

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

Re: [tor-relays] Tor-Tshirts

[Matthew Finkel]

On Sun, Mar 22, 2015 at 06:51:38AM -0400, Roger Dingledine wrote:
 On Sun, Mar 22, 2015 at 01:03:15AM -0400, Nchinda Nchinda wrote:
  Is there still someone at Tor Weather managing tshirt distribution?
  I've been running a two fairly large relays for a couple months, although I
  also wouldn't mind paying for an official tor shirt.
  
  My email to Tor Weather went unanswered.
  
  https://atlas.torproject.org/#details/C1CFB375BED9D7506569E07B01753BC67EE87AC2
  https://atlas.torproject.org/#details/CAB78BF9BD73536DCB55E5BC98D5F3AAB45CF9EA
 
 We indeed have a stack of tshirt requests queued up. I've been
 working on spinning up another volunteer to help answer all of them.
 Soon I hope!
 

Yes, real soon now, I hope. That volunteer should send an update
when they start working on all the requests in the queue.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Whitelist

[Matthew Finkel]

On Tue, Dec 23, 2014 at 11:20:32PM +, Thomas White wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 Directory Authorities,
 
 Can you please remove the following fingerprints/IP's from the
 blacklist as per my previous updates in tor-talk.
 
 D78AB0013D95AFA60757333645BAA03A169DF722
 6F545A39D4849C9FE5B08A6D68C8B3478E4B608B
 5E87B10B430BA4D9ADF1E1F01E69D3A137FB63C9
 0824CE7D452B892D12E081D36E7415F85EA9988F
 35961469646A623F9EE03B7B45296527A624AAFD
 1EA968C956FBC00617655A35DA872D319E87C597
 E5A21C42B0FDB88E1A744D9A0388EFB2A7A598CF
 5D1CB4B3025F4D2810CF12AB7A86FC10F139
 1324EC51FBFA5FD1A11B94563E8D2A7999CD8F57
 93CD9231C260558D77331162A5DC5A4C692F5344
 

Hi Thomas,

I cannot speak for the directory authority operators, but removing
these fingerprints from each of their blacklist seems like a bad idea.
Whether or not your relays were compromised, it sounds like something
happened. Directory authorities accepting these keys again seems risky
(even assuming the hardware is secure). Generating new keys is probably
a better choice, unfortunately this will add additional overhead and
you'll obviously lose a few months reputation and stability-state, but
it shouldn't take long before the relays regain their flags and status
in the network.

Thanks for running these relays,
Matt
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] How's your relay doing? Reporting Bad Relays

[Matthew Finkel]

Hi Relay Operators,

A few months ago[0], we announced the bad-rel...@lists.torproject.org
mailing list and asked everyone to send reports to that list
if they suspected a relay was...bad. We've already received many
reports, so please keep them coming.

We also want to ask all of you to use that list, as well. If at anytime
you think your relay is no longer safe for use, please tell us. Roger
tweeted about this yesterday[1][2], too. The Tor network exists because
of all of you and we can only keep it safe with your help.

Let us know if you have any questions.

Thanks!
Matt

[0] https://blog.torproject.org/blog/how-report-bad-relays
[1] https://twitter.com/RogerDingledine/status/530878388605423616
[2] For those who don't want to open Twitter:
  If your #Tor relay is stolen or you lose control of it, please report
  it so we can blacklist it:
  https://blog.torproject.org/blog/how-report-bad-relays @TorProject
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Choosing to run vanilla or obfuscated bridge

[Matthew Finkel]

On Wed, Oct 29, 2014 at 08:20:15AM +, eliaz wrote:
 I know that vanilla bridges cannot carry obfsproxy traffic. But can
 obfsproxied bridges carry vanilla traffic? If not, are there criteria to
 help me decide which bridge configuration is useful at any particular
 time? - eliaz

Hi eliaz,

As a followup to Andreas message, vanilla bridges (only setting the
torrc Bridge line) will only speak and look like the Tor protocol on
the wire. Pluggable transports usually sit directly in front of Tor
and transform the Tor-protocol-looking-data into whatever the pluggable
transport creates. At this point, Tor only speaks the Tor protocol and
each pluggable transport only speak their specific protocols. Each
component does what it does best.

So, to answer your question, only Obfsproxy understands the obfuscated
protocols (obfs2, obfs3, scramblesuit) and Tor understands Tor. If you
are thinking about running a bridge then it would be awesome if you
can run a bridge and run the pluggable transports[0]. And, if your
brave, you can also try running the new Obfs4proxy[1] pluggable
transport.

Does this make sense? Let us know if you have any more questions.

- Matt

[0] 
https://www.torproject.org/projects/obfsproxy-debian-instructions.html.en#instructions
[1] https://lists.torproject.org/pipermail/tor-relays/2014-September/005372.html
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Few questions about relaying

[Matthew Finkel]

On Sat, Oct 11, 2014 at 02:05:24AM -0400, Blaise Gagnon wrote:
 Hi and many thanks for developping this project !
 
 I have a dedicated 200Mb (25 MB) fiber optics connection and a dedicated
 quad-core Linux server (64). What is the best setup to get maximum
 bandwidth usage ? I'm still stuck at 46.4Kb measured speed and 3,51MB
 advertised bandwidth. The server has direct connection to the Internet.
 
 Fingerprint : 5EF740BB88C75915F8316DFEC8F1C8631FF26F12
 

Hi Blaise,

Thanks for running a relay!

It looks like you're currently peaking at a little over 2MB (with a
mean of ~1MB)[0][1]. 

I also see that the relay is currently hibernating. This will
certainly impact the amount of bandwidth you use. Did you configure
MaxAdvertisedBandwidth?

Below is what the network knows about your relay (with some irrelevant
details removed).

$ curl 
https://onionoo.torproject.org/details?fingerprint=5EF740BB88C75915F8316DFEC8F1C8631FF26F12
{
  version:1.1,
  relays_published:2014-10-11 05:00:00,
  relays:[
  {
nickname:QuebecFibe,
fingerprint:5EF740BB88C75915F8316DFEC8F1C8631FF26F12,
[...]
last_seen:2014-10-11 06:00:00,
last_changed_address_or_port:2014-10-07 07:00:00,
first_seen:2014-07-17 17:00:00,
running:true,
flags:[Fast,Running,V2Dir,Valid],
[...]
consensus_weight:5950,
host_name:69.159.127.80,
last_restarted:2014-10-08 06:31:26,
bandwidth_rate:26214400,
bandwidth_burst:26214400,
observed_bandwidth:3512594,
advertised_bandwidth:3512594,
exit_policy:[reject *:*],
exit_policy_summary:{reject:[1-65535]},
[...]
advertised_bandwidth_fraction:2.51E-4,
consensus_weight_fraction:2.4263727E-4,
guard_probability:0.0,
middle_probability:7.2791905E-4,
exit_probability:0.0,
recommended_version:true,
hibernating:true}
  ],
  [...]
]}

[0] 
https://globe.torproject.org/#/relay/5EF740BB88C75915F8316DFEC8F1C8631FF26F12
[1] 
https://atlas.torproject.org/#details/5EF740BB88C75915F8316DFEC8F1C8631FF26F12

 Should I run multiple relays on the same machine/IP ?

You can, and it may help, but there may be a simpler problem that can
be fixed here.

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

Re: [tor-relays] introduction

[Matthew Finkel]

On Thu, Oct 09, 2014 at 06:57:31PM -0600, Mirimir wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 I don't know whether introductions are hopelessly old school on this
 list, but here's a brief one. Although I've used Tor for many years,
 it's been just about a year since I decided to understand it better.
 I've also been catching up on the literature.
 
 Now I'm considering the possibility of running some relays. I've read
 some of the instructions on torservers.net, and have a few questions
 about security. I'm presuming that this is the best place to ask them.

Great! Welcome! This is probably as good a place as any, so please
feel free to ask (but please don't overwhelm the list ;) ).
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Directory Server Issue

[Matthew Finkel]

On Wed, Aug 13, 2014 at 10:32:45AM -0400, Spencer Rhodes wrote:
 Hi,
 
 I have a server (triratna) which I recently put up, which operates on ports 
 80 and 443, and which initially showed a Directory Server flag. After several 
 days of operation, however, the directory flag disappeared from both the 
 torstatus listing and from the arm display on the console.
 
 I would like to know if there is a way to verify that directory services are 
 in fact working, and if so, determine why the server is not flagged properly. 
 I found some old postings to the effect that one could browse to server://tor 
 or server://tor/status/all, but this does not seem to be true any more.

Hi Spencer,

This should still work. Try using
http://ip address:DirPort/tor/status-vote/current/consensus
to fetch the current consensus. You can also fetch individual relay
descriptors using a similar URI. 

If you provide your relay fingerprint someone may be able to help
further. I tried looking up the name you gave, but I couldn't find
it in either Globe[0] nor Atlas[1].

Thanks for running a relay!

- Matt


[0] https://globe.torproject.org/#/search/query=triratna
[1] https://atlas.torproject.org/#search/triratna
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Why did my relay fall out of the consensus?

[Matthew Finkel]

On Fri, Jul 04, 2014 at 10:06:51AM -0400, Steve Snyder wrote:
 On June 9th my relay, which was established about 20 months ago,
 fell out of the cached consensus.
 
 There are no errors in the logs, just notices that the relay is not
 in the cached consensus.  Apart from upgrading to Tor v0.2.4.22 3
 days earlier I haven't made any changes to the server.
 
 Anyone know what's going on here?
 
 https://exonerator.torproject.org/?targetaddr=targetPort=ip=5.9.191.52timestamp=2014-06-09#relay

Did you fix something? It seems to be running again:

https://atlas.torproject.org/#details/9BE67F8BE1B248994A30E4DEEB3EA00CCFBE9F06
https://globe.torproject.org/#/relay/9BE67F8BE1B248994A30E4DEEB3EA00CCFBE9F06
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Lost hsdir flag

[Matthew Finkel]

On Sat, Jun 21, 2014 at 07:46:54PM +0100, kingqueen wrote:
 hello,
 
 I don't know why, my relay nicknamed kingqueenbtnftw used to have the
 hsdir flag but now doesn't.
 
 I think from what I can gather, hsdir is based purely on the time
 since last boot / restart Tor service, rather than how long the relay
 has been up in total? That would explain it.

Hi kingqueen,

Yup, you are correct. The flag is assigned based on the current uptime
of the relay[0]. 

   HSDir -- A router is a v2 hidden service directory if it stores and
   serves v2 hidden service descriptors, and the authority believes that
   it's been up for at least 25 hours (or the current value of
   MinUptimeHidServDirectoryV2).

I see your relay was recently restarted, so that does explain why it
lost the flag.

Thanks for running a relay!

[0]
https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1877
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Bridge Operators - Heartbleed, Heartwarming, and Increased Help

[Matthew Finkel]

Hi All,

Below is an email we sent last week to almost all of the bridge
operators who provided contact information for their bridge(s). For
those operators we missed and for those we couldn't contact, this
hopefully provides some useful information.

All the best,
Matt

---

Hi Tor Bridge Relay Operator!

Unfortunately this email must begin with bad news, but it gets better.

Due to the recent Heartbleed OpenSSL vulnerability that was disclosed
earlier this week, we are reaching out to you to ask that you install
an updated version of OpenSSL. The vulnerability has the potential to
decrease the security of your bridge as well as the anonymity of any
user connecting to your bridge. As a result of this, we also ask that
you generate a new identity key due to the possibility that your
current one was leaked. 

The process to upgrade your version of OpenSSL depends greatly on
your operating system. Please ensure you are using a version that was
released within the past four days, see the Heartbleed website[0] for
more details on the vulnerability and for which versions are affected.
Please do this before you regenerate your identity key.

When this is done, you will need to restart Tor. At this point you can
ask us to retest your bridge to confirm that it is not vulnerable
anymore.

Next, to regenerate your identity key simply stop Tor and delete the
current key. This is done by opening Tor's Data directory and removing
the contents in the keys/ directory. Tor's Data directory is located at
/var/lib/tor, by default. Let us know if you have trouble locating it.
When this is complete, start Tor and it will automatically create a new
identity for you.

See the recent blog post for many more details:
https://blog.torproject.org/blog/openssl-bug-cve-2014-0160

Now that the bad news was said, we want to take this opportunity to
thank you, from the bottom of our hearts, for volunteering to run
a bridge relay. We know we do not say it often, but it is really
appreciated! Please let us know if you have any question, concerns, or
suggestions, especially related to how we communicate with you and how
bridge relay operators can be more involved.

Lastly, if you are not already running the obfsproxy pluggable
transport[1] (i.e.  obfs3) on your bridge, please follow the Debian
instructions[2] (for a Debian-based system) on the website and install
it. Your bridge is a great contribution to the Tor network, however as
censorship on the internet increases around the world users are forced
to use a pluggable transport. Tor does not understand how to
communicate with them by default, though. Therefore we are asking that
all bridge operators install obfsproxy and help as many users as
possible.

In addition, also consider subscribing to the tor-relays mailing
list[3], if you are not already; we will be posting instructions on how
to maximize the contribution of your bridge on that list every now and
then.

[0] http://heartbleed.com
[1] https://www.torproject.org/docs/pluggable-transports.html.en
[2] 
https://www.torproject.org/projects/obfsproxy-debian-instructions.html.en#instructions
[3] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Again, thank you for running a bridge relay and sorry for the bad news.

Let us know if you have any questions or if you have any suggestions.

All the best,
Matt
The Tor Project
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] DDOS?

[Matthew Finkel]

On Sat, Dec 29, 2012 at 11:44:29PM +, mick wrote:
 On Sat, 29 Dec 2012 22:07:59 +
 mick m...@rlogin.net allegedly wrote:
  
  I shut tor down while I investigated and when running nethogs I
  noticed a shed load of attempted connections to my tor port (443) from
  non-tor addresses. A snapshot is at
  http://rlogin.net/tor/incoming.png 
  
  Anyone else seeing anything similar? I can't believe I'm the only node
  being poked.
 
 On further investigation, I think many of those addresses are likely
 to be tor related, possibly clients attempting to join tor through my
 node.
 
 How long does it take from the time a node is shut down to the point
 where no-one will attempt to connect through it? 
 
 Mick

Hi Mick,

Technically clients will attempt to use your node until the majority of
the directory authorities agree your node is no longer reachable (should not
take more than a little over 1 hour, assuming I understand the code
correctly) plus 3 hours (a client considers a consensus valid for at most 3
hours), so roughly 4 hours. However, because some clients have incorrectly
set clocks, connections will most likely trickle in past this point. I
think after 5 hours no valid clients should still try to connect.

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