Re: [tor-relays] interesting tor platform string or tor bug?

2016-07-07 Thread Ivan Markin 


Tim Wilson-Brown - teor:
> Hmm, I can't find an actual descriptor with these characters in it. The 
> latest descriptor I can find for this relay has a normal platform line:
> https://collector.torproject.org/recent/relay-descriptors/server-descriptors/2016-07-06-06-05-14-server-descriptors
> 
> Could this be a bug in Atlas?

Nope, Onionoo returns the same platform line [1].
[1]
https://onionoo.torproject.org/details?lookup=7A9A7CD200D288DD7D78542779DE16070BC8BFFD

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

Re: [tor-relays] interesting tor platform string or tor bug?

2016-07-07 Thread Roger Dingledine 
On Fri, Jul 08, 2016 at 10:07:56AM +1000, Tim Wilson-Brown - teor wrote:
> Hmm, I can't find an actual descriptor with these characters in it. The 
> latest descriptor I can find for this relay has a normal platform line:
> https://collector.torproject.org/recent/relay-descriptors/server-descriptors/2016-07-06-06-05-14-server-descriptors
> 
> Could this be a bug in Atlas?

Not a bug in atlas -- I see an actual descriptor in moria1's cache from
inaTor which has these funny symbols in its platform string.

--Roger

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

Re: [tor-relays] interesting tor platform string or tor bug?

2016-07-07 Thread Tim Wilson-Brown - teor 

> On 8 Jul 2016, at 09:48, Tim Wilson-Brown - teor  wrote:
> 
> 
>> On 8 Jul 2016, at 09:41, nusenu  wrote:
>> 
>> Hi Seongmin,
>> 
>> out of curiosity I was wondering whether your so called tor "platform"
>> string ("??B`?\u0001") or your tor relay [1] was generated by a modified
>> tor installation on Windows 8 or if we are looking at some bug in
>> vanilla tor?
> 
> We plan on authorities rejecting descriptors with non-ASCII characters in 
> 0.2.9, if we get it implemented before the code freeze.
> https://trac.torproject.org/projects/tor/ticket/18938

Hmm, I can't find an actual descriptor with these characters in it. The latest 
descriptor I can find for this relay has a normal platform line:
https://collector.torproject.org/recent/relay-descriptors/server-descriptors/2016-07-06-06-05-14-server-descriptors

Could this be a bug in Atlas?

> 
>> 
>> thanks!
>> 
>> 
>> [1]
>> https://atlas.torproject.org/#details/21E84B294794821E2898E8ED18402E45E4FC351E
>> 
>> descriptor containing that platform string:
>> https://collector.torproject.org/recent/relay-descriptors/server-descriptors/2016-07-07-06-05-14-server-descriptors
>> 
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
> ricochet:ekmygaiu4rzgsk6n
> 
> 
> 
> 

Tim Wilson-Brown (teor)

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






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

Re: [tor-relays] interesting tor platform string or tor bug?

2016-07-07 Thread Tim Wilson-Brown - teor 

> On 8 Jul 2016, at 09:41, nusenu  wrote:
> 
> Hi Seongmin,
> 
> out of curiosity I was wondering whether your so called tor "platform"
> string ("??B`?\u0001") or your tor relay [1] was generated by a modified
> tor installation on Windows 8 or if we are looking at some bug in
> vanilla tor?

We plan on authorities rejecting descriptors with non-ASCII characters in 
0.2.9, if we get it implemented before the code freeze.
https://trac.torproject.org/projects/tor/ticket/18938

> 
> thanks!
> 
> 
> [1]
> https://atlas.torproject.org/#details/21E84B294794821E2898E8ED18402E45E4FC351E
> 
> descriptor containing that platform string:
> https://collector.torproject.org/recent/relay-descriptors/server-descriptors/2016-07-07-06-05-14-server-descriptors
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Tim Wilson-Brown (teor)

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






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

[tor-relays] interesting tor platform string or tor bug?

2016-07-07 Thread nusenu 
Hi Seongmin,

out of curiosity I was wondering whether your so called tor "platform"
string ("??B`?\u0001") or your tor relay [1] was generated by a modified
tor installation on Windows 8 or if we are looking at some bug in
vanilla tor?

thanks!


[1]
https://atlas.torproject.org/#details/21E84B294794821E2898E8ED18402E45E4FC351E

descriptor containing that platform string:
https://collector.torproject.org/recent/relay-descriptors/server-descriptors/2016-07-07-06-05-14-server-descriptors



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

[tor-relays] AS: "SIGTERM MIKAL VILLA" - Linux (15)

2016-07-07 Thread nusenu 
Dear sigterm support,

thanks for adding relays. In case you are aiming for the exit flag, you
will have to add port 80 or 443 to your current exit policy
(accept *:6660-6667) because 2 out of 3 ports are required to gain the
exit flag, see:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2216

Should you ever add relays outside your current /16 netblock, please set
the MyFamily setting properly.

btw:
your piwik installation wants to be taken care of
https://sigterm.no/

ornetra...@riseup.net wrote:
> 2016-07-06
> ---
> Up|Ext|JoinTime| IP  | CC | ORp   | Dirp  |Version   | 
> ContactInfo| Nickname | eFamlen 
> ---
> 0 | 0 |05:19:24| 193.150.121.140 | no | 9001  | 0 |0.2.5.12  | None   
> | sigtermsupportsrv | 1 
> 0 | 0 |05:20:17| 193.150.121.139 | no | 9001  | 0 |0.2.5.12  | None   
> | sigtermsupportsrv | 1 
> 0 | 0 |05:21:08| 193.150.121.141 | no | 9001  | 0 |0.2.5.12  | None   
> | sigtermsupportsrv | 1 
> 0 | 0 |06:04:26| 193.150.121.133 | no | 9001  | 0 |0.2.5.12  | None   
> | sigtermsupportsrv | 1 
> 0 | 0 |07:05:22| 193.150.121.131 | no | 9001  | 0 |0.2.5.12  | Sigterm AS 
> darknet server | sigtermsupportsrv | 1 
> 0 | 0 |07:33:52| 193.150.121.130 | no | 9001  | 0 |0.2.5.12  | Sigterm AS 
> darknet server | sigtermsupportsrv | 1 
> 1 | 0 |08:14:46| 193.150.121.131 | no | 9001  | 0 |0.2.5.12  | Sigterm AS 
> darknet server | sigtermsupportsrv | 1 
> 1 | 0 |08:46:35| 193.150.121.132 | no | 9001  | 0 |0.2.5.12  | Sigterm AS 
> darknet server | sigtermsupportsrv | 1 
> 1 | 0 |08:53:18| 193.150.121.133 | no | 9001  | 0 |0.2.5.12  | Sigterm AS 
> darknet server | sigtermsupportsrv | 1 
> 1 | 0 |09:12:50| 193.150.121.134 | no | 9001  | 0 |0.2.5.12  | Sigterm AS 
> darknet server | sigtermsupportsrv | 1 
> 1 | 0 |09:36:12| 193.150.121.135 | no | 9001  | 0 |0.2.5.12  | Sigterm AS 
> darknet server | sigtermsupportsrv | 1 
> 1 | 0 |10:37:52| 193.150.121.136 | no | 9001  | 0 |0.2.5.12  | Sigterm AS 
> darknet server | sigtermsupportsrv | 1 
> 1 | 0 |11:03:56| 193.150.121.130 | no | 9001  | 0 |0.2.5.12  | Sigterm AS 
> darknet server | sigtermsupportsrv | 1 
> 1 | 0 |11:13:48| 193.150.121.137 | no | 9001  | 0 |0.2.5.12  | Sigterm AS 
> darknet server | sigtermsupportsrv | 1 
> 1 | 0 |11:44:06| 193.150.121.138 | no | 9001  | 0 |0.2.5.12  | Sigterm AS 
> darknet server | sigtermsupportsrv | 1 
> Fingerprints:
> 506088E8CC79AB70A58E47D99D048E4560236B0C,0FFBA0D381CA6E8E2CA444C0F4B86C99BC228FAB,176EC54479BE0A2D700621D897B33B4AA000EE2F,C63EF61EF3615B6B14ACD5972C5EA1DA5BC7857D,D4F93347D639D8AF7A2144C94CD2196F107F4893,E6D022954AE4CA368F67633660165DADDA95C62B,9919526DCACE9B1D117978FD698E160457C9DA56,197B3FC47FD5C8F22929C7076FF0E66815DC044A,798DFE9B219E2CE0E737447EAF388320EACCFE8A,E8F1959686700D522B93125527F7087643BD,038C5BD680C5101AB0E2E43DFD178FD2B3AACF97,46DDFEACB49429EC6664248223FDEED712E71BBB,010D54F9C9047768E7FA8C835EFC01BCF379106D,799B19EF0F409CF237EA53FC636FA5FCBB779912,662142681939C03F3A17A1D8C6BDA8AF362A5E81
> 



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] suspicious "Relay127001" relays

2016-07-07 Thread Ivan Markin 
simon:
> As I see it, removing via directory authority consensus is still the
> cleaner way, especially in a case of ~100 similar nodes.
>
> What came to my mind was something like a bugtracker for bad nodes.

Yes, but it's too crafty and should be done by hand. Doing so is error
prone/unstable/complicated/unscalable if there is no algorithms to seed
sybils out (like ones by Philipp Winter et. al.) in automatic manner
integrated into DirAuths.


> This way, all node operators can file suspicious nodes to be excluded,
> which achieves more than blacklisting on their tiny fraction of the network.
> It would introduce more transparency because relay operators can
> actually see someone is working on getting a dir auth consensus and get
> status updates; or at least there is a discussion why there won't be any
> blocking.

As any reporting this can open new attack surface for 'report sybils'
who report against some relays to influence path selection.

With peering policy, I see it like relay operator can decide that they
do accept ('accept' policy) only 'this-group-of-relays' and nothing
more. In case when a new group of sybils appears it cannot be used with
the relay. It raises diversity in the network. So if something goes
wrong with global or fenced 'part' of the network, it can have less
damage since not all relays are affected.
It's more like not all relays on the Tor network are exits. And it's for
a reason, e.g. one can get into a legal trouble for running an Exit node
in some countries but everything is fine without exiting there.

--
Ivan Markin

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

Re: [tor-relays] VPS for Exits and non-Exits

2016-07-07 Thread Jean-Philippe Décarie-Mathieu 
In my case, the decision to host my Tor VPS on OVH's infrastructure is
to support a business that is based in Québec. Ideology aside, I agree
that network diversity is key (along with the multiplication of exit nodes).

Regards,

*Jean-Philippe Décarie-Mathieu*
j...@jpdm.org  - PGP: 0x2D61F80F - 514-799-0789
http://www.jpdm.org/ - https://www.crypto.quebec/

On 2016-07-06 04:39 PM, pa011 wrote:
>
> Am 06.07.2016 um 22:09 schrieb Iain R. Learmonth:
>> Hi,
>>
>> On 06/07/16 18:25, tor relay wrote:
 I've been running an exit node for over a year on OVH now, no problems
 so far. Highly recommended (especially since they give me 10TB of
 traffic for about 10$USD/month; considering I use about 7-8TB of that
 per month, it's well worth it).
>>> OVH is used to much by tor operators already (>12% of the tor network
>>> capacity is there).
>> Not the most performance enhanced page on the web but:
>>
>> https://metrics.torproject.org/bubbles.html
>>
>> This bubble graph shows where relays are located by autonomous system.
>> If you're looking to set up new relays, attempting to grow smaller
>> bubbles here (the names should be googleable enough) or trying to add
>> new ones would definitely be preferred over adding more to OVH.
>>
>> It's great that OVH are Tor-friendly, but diversity of the network is
>> important.
>>
>> Thanks,
>> Iain.
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> "..diversity of the network is important." -very important - what if a
> far Western European government decides on the next "state of emergency"
> to ban Tor and "asks" their domestic ISPs for support?
>
> There are other Providers who give you 15-50 TB/month for less than 10 Euro.
>
> Dig for them - don’t follow the pack!
>
>
> ___
> 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] suspicious "Relay127001" relays

2016-07-07 Thread simon 
On 06.07.2016 15:50, Ivan Markin wrote:
> The introduction of peering policy definitely solves this issue in a
> transparent and harmless way. Filed a ticket #19625 [1] to move this
> discussion
> there.

On 06.07.2016 14:56, Roger Dingledine wrote:
> Speaking of which, a while ago I started a discussion of how to
> streamline that process:
> https://trac.torproject.org/projects/tor/ticket/16558

As I see it, removing via directory authority consensus is still the
cleaner way, especially in a case of ~100 similar nodes.

What came to my mind was something like a bugtracker for bad nodes.

This way, all node operators can file suspicious nodes to be excluded,
which achieves more than blacklisting on their tiny fraction of the network.
It would introduce more transparency because relay operators can
actually see someone is working on getting a dir auth consensus and get
status updates; or at least there is a discussion why there won't be any
blocking.
Lastly, it would prevent partitioning attacks or similar in contrast to
per-node blacklisting.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Darknet Shenanigans [was: suspicious "Relay127001" relays]

2016-07-07 Thread Yawning Angel 
On Thu, 7 Jul 2016 07:29:04 +0200
Andreas Krey  wrote:

> On Wed, 06 Jul 2016 15:06:00 +, grarpamp wrote:
> ...
> > https://boingboing.net/2016/07/01/researchers-find-over-100-spyi.html  
> 
> Is there a way to make tor log connection attempts to any ports
> on an hidden service address, independent of whether the port
> actually has a HiddenServicePort?

Not on any reasonable log config as is (I didn't check unreasonable
ones like the debug one.).

Patch `rend_service_set_connection_addr_port()` in rendservice.c if you
want this behavior.  Note that it will already log connection attempts
to unknown ports by default (to the `LD_REND` domain).

There's also an option (disabled by default) to tear down circuits
that attempt to open streams to unknown ports, but that won't stop
anyone moderately dedicated, just make things take more time. 

> > All quite expected and well known ever since the
> > dawn of overlay networks. Same with the Internet.  
> 
> Also, wasn't there a change that made discovery impossible?

Prop 224 will fix it, but that hasn't been fully implemented yet.
Using `stealth` HS auth in the mean time frustrates this.

-- 
Yawning Angel


pgpojBDIhEIhA.pgp
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays