Re: [tor-relays] How to detect Tor exit IP addresses (was Re: [SOLVED] published descriptor missing from consensus)

[Scott Bennett]

Roger Dingledine  wrote:

> On Thu, Jun 08, 2017 at 05:30:37PM -0500, Scott Bennett wrote:
> >  Consider another case.  Users have often complained that running a tor
> > relay results in their IP addresses being blocked by all manner of services
> > around the Internet.  The providers of those services say they have suffered
> > attacks originating from tor relays.  The project's response was to create
> > an automatically, frequently updated list of IP addresses of exit relays and
> > make that list available for download by anyone wishing to block traffic 
> > from
> > tor exits, while allowing traffic from all other relays.  That list of
> > addresses suffers the same problem of not including alternative IP addresses
> > for those relays.  Even worse, troublesome connections from those 
> > alternative
> > addresses *can* be traced back, in some cases, to the exit relay.  Once 
> > those
> > services have identified the offending traffic as coming from a machine they
> > had been promised by the tor project would be in the downloadable list of
> > exit relay addresses, they may decide that they had been deceived by the tor
> > project, which could lead to many bad things in the future.
>
> I think we might have to agree to disagree about a lot of these topics,
> but I wanted to correct this one.
>
> The bulk exit list:
> https://check.torproject.org/cgi-bin/TorBulkExitList.py
> along with TorDNSEL is designed to handle exactly this situation, and
> it does it pretty well.
>
 Okay, I'll take your word for it, but I'm curious to know the source
of the addresses collected if tor doesn't report them.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [SOLVED] published descriptor missing from consensus

[teor]

> On 9 Jun 2017, at 08:30, Scott Bennett  wrote:
> 
> Roman Mamedov  wrote:
> 
>> On Thu, 08 Jun 2017 09:43:00 -0500
>> Scott Bennett  wrote:
>> 
>>> As noted more than once previously, the pf rules *pass* all traffic
>>> from relay addresses *first*, so that traffic has already gone on to tor
>>> before the block list is applied.
>> 
>> There are most likely some relays which use a different IP for outgoing
>> connections than what is listed in the consensus, due to multiple IPs or
>> provider multihoming. Your scheme does not seem to account for that, so those
>> connections may fail. In effect you will be leaving the Tor network
>> permanently semi-broken by running a relay while employing such filtering.

This also excludes any direct client connections to your relay. For an Exit,
clients should only connect if UseEntryGuards is 0 (the default is 1, except
for Tor2Web and Single Onion Service clients).

It also excludes connections from relays that come up and down frequently.

> You're right.  I recall spending a lot of time trying to find a way to
> get those addresses, so that I could include them in the TorRelays table or
> some other arrangement to let their traffic through.  Unfortunately, tor
> doesn't publish them anywhere that I could find nor did anything else back
> at the time I set these rules and tables up.  However, I figured most relays
> probably have only a single WAN interface, so the rules would probably cause
> few failures.

My relays have multiple IP addresses on a single WAN interface. They all use
OutboundBindAddress to separate OR and Dir traffic from outbound traffic. And
they make up about 1% of Tor guard/middle bandwidth.

I think you will find this is not an uncommon configuration among
high-bandwidth relays.

Some directory authorities also have multiple IP addresses.

> Also, clients don't give up after something like that, but
> rather continue to try more circuits, so the end user may experience a short
> delay, but won't actually go unserved in such cases.

What actually happens depends on a number of factors:
* whether the other relay has successfully connected to your relay,
* whether both relays think the connection is canonical,
* whether either relay has a large exponential backoff on retries.

So in some cases, clients will be unable to connect to your exit via some
middle relays. This reduces your exit traffic, and also reduces the number of
different circuit paths available to clients. (Using a wide variety of paths
is one of the building blocks of Tor's anonymity.)

My point is that there are a lot of moving parts here.
And there could be multiple contributing factors, not just OpenSSL.

For the record, we generally suggest the following firewall
configuration:
* allow incoming connections to your ORPort and DirPort from any IP
* allow all outgoing connections.

But we might have to agree to disagree here.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org






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

[tor-relays] How to detect Tor exit IP addresses (was Re: [SOLVED] published descriptor missing from consensus)

[Roger Dingledine]

On Thu, Jun 08, 2017 at 05:30:37PM -0500, Scott Bennett wrote:
>  Consider another case.  Users have often complained that running a tor
> relay results in their IP addresses being blocked by all manner of services
> around the Internet.  The providers of those services say they have suffered
> attacks originating from tor relays.  The project's response was to create
> an automatically, frequently updated list of IP addresses of exit relays and
> make that list available for download by anyone wishing to block traffic from
> tor exits, while allowing traffic from all other relays.  That list of
> addresses suffers the same problem of not including alternative IP addresses
> for those relays.  Even worse, troublesome connections from those alternative
> addresses *can* be traced back, in some cases, to the exit relay.  Once those
> services have identified the offending traffic as coming from a machine they
> had been promised by the tor project would be in the downloadable list of
> exit relay addresses, they may decide that they had been deceived by the tor
> project, which could lead to many bad things in the future.

I think we might have to agree to disagree about a lot of these topics,
but I wanted to correct this one.

The bulk exit list:
https://check.torproject.org/cgi-bin/TorBulkExitList.py
along with TorDNSEL is designed to handle exactly this situation, and
it does it pretty well.

--Roger

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

Re: [tor-relays] [SOLVED] published descriptor missing from consensus

[Scott Bennett]

Roman Mamedov  wrote:

Hi Roman!
> On Thu, 08 Jun 2017 09:43:00 -0500
> Scott Bennett  wrote:
>
> >  As noted more than once previously, the pf rules *pass* all traffic
> > from relay addresses *first*, so that traffic has already gone on to tor
> > before the block list is applied.
>
> There are most likely some relays which use a different IP for outgoing
> connections than what is listed in the consensus, due to multiple IPs or
> provider multihoming. Your scheme does not seem to account for that, so those
> connections may fail. In effect you will be leaving the Tor network
> permanently semi-broken by running a relay while employing such filtering.

 You're right.  I recall spending a lot of time trying to find a way to
get those addresses, so that I could include them in the TorRelays table or
some other arrangement to let their traffic through.  Unfortunately, tor
doesn't publish them anywhere that I could find nor did anything else back
at the time I set these rules and tables up.  However, I figured most relays
probably have only a single WAN interface, so the rules would probably cause
few failures.  Also, clients don't give up after something like that, but
rather continue to try more circuits, so the end user may experience a short
delay, but won't actually go unserved in such cases.
 Consider another case.  Users have often complained that running a tor
relay results in their IP addresses being blocked by all manner of services
around the Internet.  The providers of those services say they have suffered
attacks originating from tor relays.  The project's response was to create
an automatically, frequently updated list of IP addresses of exit relays and
make that list available for download by anyone wishing to block traffic from
tor exits, while allowing traffic from all other relays.  That list of
addresses suffers the same problem of not including alternative IP addresses
for those relays.  Even worse, troublesome connections from those alternative
addresses *can* be traced back, in some cases, to the exit relay.  Once those
services have identified the offending traffic as coming from a machine they
had been promised by the tor project would be in the downloadable list of
exit relay addresses, they may decide that they had been deceived by the tor
project, which could lead to many bad things in the future.
>
> In any case I don't think there is any reasonable threat scenario against 
> which
> you must protect by not just allowing all connections from anywhere to
> ORPort/DirPort of a Tor relay.
>
 That is something that each system administrator has to determine for
the system(s) under his care.  My determination for my system apparently
differs from your evaluation of your situation.
 What originally prompted me to look into using a packet filter to block
traffic from identifiable sources of trouble was the frequency of attacks on
my system.  It was so intense at times that even the kernel was complaining
in console messages that it was limiting RSTs to 200/s.  These messages were
happening so fast that syslogd was reducing them in most cases with messages
like "last line repeated 1353 times" (not an exact quotation, but I'm sure
you've seen syslogd's message flood response before).  At first, setting

net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1

seemed to take care of the problem.  However, after a couple of years, the
messages resumed.  China, Malaysia, Nigeria, and a few other countries were
being especially persistent and aggravating in the frequency of their attacks.
(Just in case, I've since added "net.inet.sctp.blackhole=2" to the above list.)
 Although providing a tor relay and directory is currently the only thing
my system offers to benefit other people, I decided that, if I ever chose
to offer other services, I would want to deny those services to the offending
parties, too, which is why those block rules apply to all ports on my system
and not only to tor's ports.  The pass rules apply to traffic destined to
tor's ports.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [SOLVED] published descriptor missing from consensus

[Scott Bennett]

tor  wrote:

> > I tried disabling pf and restarting tor. To my surprise, the authorities
> > connected to my relay successfully and distributed its information in
> > subsequent consensuses!
>
> Haha. This is the least surprising thing I've read all week.

 Then either you weren't paying attention or you don't know pf.  And
you have to explain why correcting the openssl library versions eliminates
the problem.  In short, you didn't follow the chain of evidence presented.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [SOLVED] published descriptor missing from consensus

[tor]

> I tried disabling pf and restarting tor. To my surprise, the authorities
> connected to my relay successfully and distributed its information in
> subsequent consensuses!

Haha. This is the least surprising thing I've read all week.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [SOLVED] published descriptor missing from consensus

[Roman Mamedov]

On Thu, 08 Jun 2017 09:43:00 -0500
Scott Bennett  wrote:

>  As noted more than once previously, the pf rules *pass* all traffic
> from relay addresses *first*, so that traffic has already gone on to tor
> before the block list is applied.

There are most likely some relays which use a different IP for outgoing
connections than what is listed in the consensus, due to multiple IPs or
provider multihoming. Your scheme does not seem to account for that, so those
connections may fail. In effect you will be leaving the Tor network
permanently semi-broken by running a relay while employing such filtering.

In any case I don't think there is any reasonable threat scenario against which
you must protect by not just allowing all connections from anywhere to
ORPort/DirPort of a Tor relay.

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

Re: [tor-relays] [SOLVED] published descriptor missing from consensus

[Scott Bennett]

teor  wrote:

>
> > On 8 Jun 2017, at 18:44, Scott Bennett  wrote:
> > 
> > Roger Dingledine  wrote:
> > 
> > Or at least partially solved, at any rate.  The problem is solved,
> > but the mystery remains.
> > 
> >> On Sun, Jun 04, 2017 at 07:14:06PM -0500, Scott Bennett wrote:
> >>> Which versions are the Running votes coming from versus the 
> >>> non-Running?
> >> 
> >> You can see the votes at
> >> https://www.seul.org/~arma/moria1-v3-status-votes
> >> 
> >>> I have a few commands in a crontab entry that extract relay IP 
> >>> addresses
> >>> from the most recently received consensus, sort them, and load them into a
> >>> table in pf.  They run every 15 minutes.  Anything coming from the 
> >>> addresses
> >>> in the table is immediately passed.  Anything not passed gets checked 
> >>> against
> >>> a much larger table of probers, attempted intruders, etc. and is blocked 
> >>> if it
> >>> matches a table entry.
> >> 
> >> Well heck. Sounds like we have a winner here.
> >> 
> >> Turn off your weird censorship infrastructure, confirm that things
> >> start working after a while, and now you have something to debug. :)
> >> 
> > The misuse of the word "censorship" aside, I tried disabling pf and
> > restarting tor.  To my surprise, the authorities connected to my relay
> > successfully and distributed its information in subsequent consensuses!
> > I do not know why, which is the remaining mystery.  However, having to
> > turn off one's firewall in order to run tor is not a solution to the
> > problem.
>
> If your firewall is blocking connections that tor needs to make, turning
> off that rule is precisely the solution to the problem.

 As noted more than once previously, the pf rules *pass* all traffic
from relay addresses *first*, so that traffic has already gone on to tor
before the block list is applied.  As also noted previously, the rules had
not (and still have not) been changed in a long time.  They were working
just fine for years, and then suddenly they were not.  Now they are working
just fine again since tor got rebuilt, so they are not the problem.
>
> > What I think I know is that the mismatched openssl stub and library versions
> > somehow interact with pf and pre-0.3.0.7 tor authorities in some mysterious
> > manner that causes connections from those authorities to my relay to fail,
> > but connections from 0.3.0.7 authorities to work just fine.  Having the stub
> > version and the library version be identical apparently avoids the erroneous
> > interaction(s).
>
> It's possible. But to confirm, you'd need to provide the sections of
> the firewall log that show what happens when a directory authority
> tries to check the reachability of your relay.

 That stuff isn't logged because it would soon exhaust the available
disk space with garbage.
>
> (As an aside, I'd encourage you not to keep logs at this level on an
> ongoing basis, they would contain client IP addresses and connection
> times.)

 That's one reason; the other is the space and kernel overhead
requirements.
>
> Or perhaps your firewall collected enough state to want to block tor
> while it was running, and lost that state when you turned it off and
> on again.

 I don't understand how an application could directly interfere with
the packet filter's operation.  I've previously posted the rules.  As I
described, it appears to be a problem of openssl misbehaving, apparently
due to mismatched stub and library versions, though I don't understand
how openssl trouble could occur with pf enabled and not occur with pf
disabled.  In any case, rebuilding tor so that the stub and library
versions match has eliminated the problem.  tor now plays nicely with the
authorities, regardless of whether pf is enabled.
 Now, having said that, I should mention that tor does mess around
with /dev/bpf, at least during startup, which is one reason why tor has
to have root privileges during startup.  I've never looked into exactly
what it does with /dev/bpf, however, so I have no idea whether that could
be involved and caused to malfunction somehow by openssl problems.
>
> You have a complex enough system that there are probably more
> possibilities neither of us have thought of.

 Complex?  Compared to what?  You've already seen the handful of rules
involved, which includes some near duplication of ORPort rules to provide
the same protection from miscreants to the DirPort that is given to the
ORPort.  In a nutshell, the rules look at incoming SYN packets to see if
they come from tor relay addresses and immediately lets pass those that do.
(By doing this step first, relay traffic is protected from the next step,
even if the relay's address has gotten onto the block list, e.g., an exit
that has been abused by some cracker or wannabe-cracker.)  If they do not,
then they are checked against a very large block list and, if found in the
block list, are dropped with no 

Re: [tor-relays] [SOLVED] published descriptor missing from consensus

[teor]

> On 8 Jun 2017, at 18:44, Scott Bennett  wrote:
> 
> Roger Dingledine  wrote:
> 
> Or at least partially solved, at any rate.  The problem is solved,
> but the mystery remains.
> 
>> On Sun, Jun 04, 2017 at 07:14:06PM -0500, Scott Bennett wrote:
>>> Which versions are the Running votes coming from versus the non-Running?
>> 
>> You can see the votes at
>> https://www.seul.org/~arma/moria1-v3-status-votes
>> 
>>> I have a few commands in a crontab entry that extract relay IP addresses
>>> from the most recently received consensus, sort them, and load them into a
>>> table in pf.  They run every 15 minutes.  Anything coming from the addresses
>>> in the table is immediately passed.  Anything not passed gets checked 
>>> against
>>> a much larger table of probers, attempted intruders, etc. and is blocked if 
>>> it
>>> matches a table entry.
>> 
>> Well heck. Sounds like we have a winner here.
>> 
>> Turn off your weird censorship infrastructure, confirm that things
>> start working after a while, and now you have something to debug. :)
>> 
> The misuse of the word "censorship" aside, I tried disabling pf and
> restarting tor.  To my surprise, the authorities connected to my relay
> successfully and distributed its information in subsequent consensuses!
> I do not know why, which is the remaining mystery.  However, having to
> turn off one's firewall in order to run tor is not a solution to the
> problem.

If your firewall is blocking connections that tor needs to make, turning
off that rule is precisely the solution to the problem.

> What I think I know is that the mismatched openssl stub and library versions
> somehow interact with pf and pre-0.3.0.7 tor authorities in some mysterious
> manner that causes connections from those authorities to my relay to fail,
> but connections from 0.3.0.7 authorities to work just fine.  Having the stub
> version and the library version be identical apparently avoids the erroneous
> interaction(s).

It's possible. But to confirm, you'd need to provide the sections of
the firewall log that show what happens when a directory authority
tries to check the reachability of your relay.

(As an aside, I'd encourage you not to keep logs at this level on an
ongoing basis, they would contain client IP addresses and connection
times.)

Or perhaps your firewall collected enough state to want to block tor
while it was running, and lost that state when you turned it off and
on again.

You have a complex enough system that there are probably more
possibilities neither of us have thought of.

I'd keep an eye on things over the next few weeks.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org






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

Re: [tor-relays] torservers.net: some exits became guards? (deanonymization risk)

[nusenu]

Hi Paul,

Paul Syverson:
> It shouldn't be possible
> to use the relay in both positions simultaneously.  And even if it
> could serve as both guard and exit simultaneously, the route-selection
> algorithm would preclude it being used as both ends for any
> circuit. And if all torservers.net relays are properly indicated to be
> from the same family, they will never be selected for both ends of a
> circuit.

I'm well aware of how MyFamily works :)

To quote the page I linked (OrNetStats):

> Operators are only listed if they actually have a chance to do end-to-end 
> correlation attacks, that is:
> their guard and exit probability is > 0%
> they did not properly configure MyFamily
> they run in more than a single /16 network block

For more context see:
https://medium.com/@nusenu/some-tor-relays-you-might-want-to-avoid-5901597ad821


> Potentially, a client opening multiple circuits through multiple
> guards (so not using the current standard default of using a single
> guard) could have some guards and some exits of concurrent circuits
> run by torservers.net if they satisfy the /16 separation.
> But that is generally not what is meant by 'end-to-end correlation'.

By end-to-end correlation I mean "a tor client has a chance to use
torservers.net relays in their entry (guard) and exit position in a
single circuit.


-- 
https://mastodon.social/@nusenu
https://twitter.com/nusenu_



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] torservers.net: some exits became guards? (deanonymization risk)

[Paul Syverson]

Hi Nusenu,


On Thu, Jun 08, 2017 at 09:58:00AM +, nusenu wrote:
> Dear Torservers,
> 
> are  you aware that you have recently become a relay operator with
> end-to-end correlation (deanonymization) capabilities? (in fact you are
> the biggest known such operator)
> This is especially bad for tor clients because you are also one of the
> biggest tor exit operators.
> 
> Some of your relays which used to be exits recently became guard-ony relays.
> https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#httpswwwtorserversnetdonatehtml-support-a

Apologies if this is focusing on a minor point of your message or
illuminates nothing but my general tiredness/distractedness, but I
don't see how switching a relay from being an exit to being guard-only
increases correlation risk from that relay. It shouldn't be possible
to use the relay in both positions simultaneously.  And even if it
could serve as both guard and exit simultaneously, the route-selection
algorithm would preclude it being used as both ends for any
circuit. And if all torservers.net relays are properly indicated to be
from the same family, they will never be selected for both ends of a
circuit.

Potentially, a client opening multiple circuits through multiple
guards (so not using the current standard default of using a single
guard) could have some guards and some exits of concurrent circuits
run by torservers.net if they satisfy the /16 separation.
But that is generally not what is meant by 'end-to-end correlation'.

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

[tor-relays] torservers.net: some exits became guards? (deanonymization risk)

[nusenu]

Dear Torservers,

are  you aware that you have recently become a relay operator with
end-to-end correlation (deanonymization) capabilities? (in fact you are
the biggest known such operator)
This is especially bad for tor clients because you are also one of the
biggest tor exit operators.

Some of your relays which used to be exits recently became guard-ony relays.
https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#httpswwwtorserversnetdonatehtml-support-a


Is there anything I can help you with to fix this and reduce the risk
for tor clients?

thanks,
nusenu






-- 
https://mastodon.social/@nusenu
https://twitter.com/nusenu_



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] [SOLVED] published descriptor missing from consensus

[Scott Bennett]

Roger Dingledine  wrote:

 Or at least partially solved, at any rate.  The problem is solved,
but the mystery remains.

> On Sun, Jun 04, 2017 at 07:14:06PM -0500, Scott Bennett wrote:
> >  Which versions are the Running votes coming from versus the 
> > non-Running?
>
> You can see the votes at
> https://www.seul.org/~arma/moria1-v3-status-votes
>
> >  I have a few commands in a crontab entry that extract relay IP 
> > addresses
> > from the most recently received consensus, sort them, and load them into a
> > table in pf.  They run every 15 minutes.  Anything coming from the addresses
> > in the table is immediately passed.  Anything not passed gets checked 
> > against
> > a much larger table of probers, attempted intruders, etc. and is blocked if 
> > it
> > matches a table entry.
>
> Well heck. Sounds like we have a winner here.
>
> Turn off your weird censorship infrastructure, confirm that things
> start working after a while, and now you have something to debug. :)
>
 The misuse of the word "censorship" aside, I tried disabling pf and
restarting tor.  To my surprise, the authorities connected to my relay
successfully and distributed its information in subsequent consensuses!
I do not know why, which is the remaining mystery.  However, having to
turn off one's firewall in order to run tor is not a solution to the
problem.
 But, while going back through the logs, I noticed the following among
tor's startup messages.

Jun 05 23:25:46.849 [warn] OpenSSL version from headers does not match the 
version we're running with. If you get weird crashes, that might be why. 
(Compiled with 100020bf: OpenSSL 1.0.2k  26 Jan 2017; running with 100020cf: 
OpenSSL 1.0.2l  25 May 2017).
Jun 05 23:25:46.895 [notice] Tor 0.3.0.7 (git-cfd9c1bdc0582656) running on 
FreeBSD with Libevent 2.1.8-stable, OpenSSL 1.0.2l and Zlib 1.2.8.

The date of 25 May 2017 means that my last run of 0.3.0.6 was using an older
OpenSSL version, but 0.3.0.7 was using the newer one, although it had been
compiled with the earlier version shown in the first message.  I'm not sure
how that might interact badly with pf at all.  However, I rebuilt 0.3.0.7,
stopped the running copy, enabled pf, and restarted tor to run from the
rebuilt version.  Enough authorities must be happy with it because they are
now distributing its information in the consensus and also its most recent
descriptor.
 In summary, the problem is resolved, but the mystery remains unsolved.
What I think I know is that the mismatched openssl stub and library versions
somehow interact with pf and pre-0.3.0.7 tor authorities in some mysterious
manner that causes connections from those authorities to my relay to fail,
but connections from 0.3.0.7 authorities to work just fine.  Having the stub
version and the library version be identical apparently avoids the erroneous
interaction(s).


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 2017-06-07 15:37: 65 new tor exits in 30 minutes

[nusenu]

Roger Dingledine:
> we have a plausible guess about where they came from,
> and we contacted the company that we think controls the IP addresses, so
> they can figure it out / clean up as needed.

Interesting. I'm curious, how did you link the IP addresses to the
company? Is your guess that the company set up relays or that someone
used that company's servers to setup relays?
("clean up" sounds like someone used their servers in an unauthorized way)


-- 
https://mastodon.social/@nusenu
https://twitter.com/nusenu_



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