Re: [tor-talk] Bittorrent starting to move entirely within anonymous overlay nets

[grarpamp]

On 6/10/16, Mirimir  wrote:
> But there's still the traffic load. Or maybe, one could consider it as
> chaff. Just sort of, though. Right?

If that's the old "OMG, too much" argument... load re anon overlay nets
may be more like bitcoin's interrelated variables... difficulty, txfees, reward,
watts, price, txrate, etc... they'll slide nicely around to compensate until
some unsolveable fundamental limit is reached. ie:
Private (non-exit/I2P) use of these nets... if they slow, users will start
talking urging more nodes, which they'll readily deploy themselves since
private is low risk and satiates their use case. If the required node count
to support n-million users starts blowing up CPU/RAM, devs will
start getting poked to work on layering that. Even parallel nets
with usage charters may arise by then as a given networks adversary
resistance begets users begets trust begets honoring narrower charter.
Besides, load happens to useful nets, no point trying to stave it off
(nets are anon so staving is a no anyway), and trying to stave makes
the stavers look stupid.
A little education helps too, users will self regulate if they sense that,
"Oh shit, I know this net is used for , but I can't
even get my own  through, so I better ease up on variable ".

Is it chaff, and good as to filling otherwise quiet parts of the net?
Perhaps. But as in other GPA threads, I think fill traffic may need
to be actively managed to defeat that, rather than just flooded.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor 0.2.8.4-rc is released

[Sarah Alawami]

Thanks for this. Hopefully it will make it to homebrew for when I run my update 
script in a few weeks.

Happy Thursday.
> On Jun 15, 2016, at 10:00 AM, Nick Mathewson  wrote:
> 
>  Tor 0.2.8.4-rc is the first release candidate in the Tor 0.2.8 series.
>  If we find no new bugs or regressions here, the first stable 0.2.8
>  release will be identical to it. It has a few small bugfixes against
>  previous versions.
> 
> You can download the source from the usual place on the website.
> Packages should be available over the next several days. Remember
> to check the signatures!
> 
> PLEASE NOTE: This is a release candidate. We think that we solved all
> of the showstopper bugs, but crucial bugs may remain. Please only run
> this release if you're willing to test and find bugs. If no
> showstopper bugs are found, we'll be putting out 0.2.8.5 as a stable
> release.
> 
> The changelog follows.
> 
> Changes in version 0.2.8.4-rc - 2016-06-15
> 
>  o Major bugfixes (user interface):
>- Correctly give a warning in the cases where a relay is specified
>  by nickname, and one such relay is found, but it is not officially
>  Named. Fixes bug 19203; bugfix on 0.2.3.1-alpha.
> 
>  o Minor features (build):
>- Tor now builds once again with the recent OpenSSL 1.1 development
>  branch (tested against 1.1.0-pre5 and 1.1.0-pre6-dev).
> 
>  o Minor features (geoip):
>- Update geoip and geoip6 to the June 7 2016 Maxmind GeoLite2
>  Country database.
> 
>  o Minor bugfixes (compilation):
>- Cause the unit tests to compile correctly on mingw64 versions that
>  lack sscanf. Fixes bug 19213; bugfix on 0.2.7.1-alpha.
> 
>  o Minor bugfixes (downloading):
>- Predict more correctly whether we'll be downloading over HTTP when
>  we determine the maximum length of a URL. This should avoid a
>  "BUG" warning about the Squid HTTP proxy and its URL limits. Fixes
>  bug 19191.
> -- 
> tor-talk mailing list - tor-talk@lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Food for thought

[foodforthought]

Things are never black and white, there are always two sides of a story
and people are never only good or bad.

But was it really our first and foremost concern to find out the "truth"?
Is the lesson to be learned, if you will, about who is to blame? About
shaming the victims or shaming the alleged perpetrator? About whether or
not the "accused" will be found "guilty"? Is an "evidence-based
discussion" or "due process" really going to solve the greater issue here?

In a community that claims to strive for equality, accusations against one
person raise much broader questions and issues, like:

-) How much leadership/charisma/hero-worshiping can be healthy for a
community of self-empowered people?

-) What is not criminal can still be harmful, disrespectful, humiliating or
violating consent, just as what is criminal can still be ethical or
consensual. Innocent until found guilty misses the mark in this context.

-) If we were living in a community/society of fulfilled people, who feel
accepted, approved of and loved by their peers, there would be no such
thing as abuse or harassment. But we don't. (Yet?) How do we deal with
this discrepancy in a constructive way?

-) If someone voices concerns about a certain individual, how do we open
lines of communication before too many get harmed? How do we treat both
parties involved respectfully?

-) Even when a person, from the bottom of their heart, talks about
sex-positivism, respect for others, transparency and equality, it does not
mean that they can live up to their own expectations. Their own disability
to do so may make them even more enthusiastic talking about it.

-) We are all humans, we are fallible, we are flawed, we cause harm in
others. The question is, do we create an environment where failure is
recognized, do we surround ourselves with friends who will tell us we
failed? Will they express concern, when self-reflection and self-criticism
have failed us? Will people speak up even to the one person considered a
role model? Or do we kick issues into the long grass and surround
ourselves with yes-men?
This ties in with the first question.


-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Only nine of the 29 Windows VPN clients that I tested didn't leak

[s7r]

As far as I was able to find one defense against TCP/IP stack
fingerprinting is blocking outgoing ICMP entirely and disabling replying
to ICMP requests on the defensive host, but this could be somehow wrong
since it's stated that just inspecting the initial TTL and window size
fields could be enough.

Wonder what is a good way to disguise VPN usage (any VPN implementation)
at OS level.

On 6/16/2016 8:34 PM, Mirimir wrote:
> On 06/16/2016 10:51 AM, s7r wrote:
>> Hello grarpamp, mirmir
>>
>> Speaking of, there is this website:
>> http://ipleak.com/
>>
>> If you go to Proxy/VPN in the left menu it will show you some info
>> related to vpn usage detected.
>>
>> In my latest firefox it says:
>>
>> First seen   2016/06/16 16:47:04
>> Last update  2016/06/16 16:47:04
>> Total flows  1
>> Detected OS  Windows 7 or 8
>> HTTP softwareFirefox 10.x or newer (ID seems legit)
>> MTU  1406
>> Network link OpenVPN TCP bs64 SHA1 lzo
>> Language English
>> Distance 11
>>
>>
>> Where I use exactly OpenVPN in TCP mode. In Tor Browser this is not
>> detected.
> 
> It won't work in Tor Browser using Tor, because Tor isn't just TCP/IP.
> If you mangle Tor Browser to work without Tor, you'll see it.
> 
>> I am not sure how reliable is this tool, but what's the trick in normal
>> firefox to disable this so that networking info is not revealed any
>> more? How is this information gather by this website?
> 
> I'm not aware that it's blockable. It's not an HTML5 thing. Read up on
> TCP/IP stack OS fingerprinting.
> 
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Only nine of the 29 Windows VPN clients that I tested didn't leak

[Mirimir]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/16/2016 10:28 AM, grarpamp wrote:
> On 6/16/16, Mirimir  wrote:
>> https://vpntesting.info/
>> 
>> I tested 29 Windows VPN clients for DNS, IPv4 and IPv6 Leaks.
> 
> Nice.
> 
> You might want to include - For clients that may be doing packet
> filtering instead of just modifying kernel routing tables... test
> ICMP, generic UDP (non-DNS), TCP, etc. - The codebase and VPN
> protocol of each client (OpenVPN, SoftEther, etc)

Thanks. I've been thinking about how to test harder. I did ICMP ping
8.8.8.8 and wget google.com, but not other packet types.

I'll take a closer look at the clients. In many cases, it was just
stock OpenVPN, or maybe with a wrapper.

>> hit VPN-specified nameservers directly while reconnecting after
>> uplink interruption. But that's not a huge issue, in that they
>> didn't hit other nameservers.
> 
> Seems big if the direct hits were not encrypted over the VPN and
> user's requirement is to encrypt to the VPN termination.

Good point. I'll tweak that language.

>> After uplink interruption, some failed to reconnect
>> automatically
> 
> These interruption, reconnect, renegotiation, timeout, edge cases
> are important to discover.

Yes, it's why doing your own leak prevention is best. Unless the VPN
provides its own IPv6 address, disable IPv6 everywhere you can, and
block it with firewall rules. Use firewall rules to allow connections
on physical interface only to VPN server. Restrict everything else to
VPN tunnel. And make sure that you're using VPN-assigned DNS server(s)
through VPN tunnel.

But the six totally leak-free Windows VPN clients do that. Indeed,
FrootVPN and Perfect Privacy provide their own IPv6 addresses. And
FrootVPN is leak-free using stock OpenVPN, doing just server-side.

> More advanced users of Tor + OpenVPN might be interested in this
> capability... https://community.openvpn.net/openvpn/ticket/577

Interesting. VPN SOCKS5 port.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJXYubxAAoJEGINZVEXwuQ+SPIH/igDGoMyQeqm/ZD8XlluRuOK
A7ZhSW5aYZ8si8nel9ulj1EyS1AsfUnMJHZmidHDp7PaQMWjyt0fk1StiAIaqaoq
NKc4qF68QpZOpfuhijL6JFvaWbNYnsn1aAZ5KDINDz2VRKfGNOnOjkx6BwqXKApg
3VcCV4oc9L79nbXZzjA3JdERQVSA2mA32g6VMN/BkLXXYkb2escV3QlWOst4SaCQ
v11hITwGDP0jMRM/hfiTLND2r/h0kzhCVqV7AVLodB09wIZm0pT7fG4Uw1EADwoa
x6YV/PHRjqKVsTHc9v/B+WsI1R+AG7Vsv/nQL6smHeqjC3k++ClgUtyAEKErdq8=
=T60g
-END PGP SIGNATURE-
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Only nine of the 29 Windows VPN clients that I tested didn't leak

[Mirimir]

On 06/16/2016 10:51 AM, s7r wrote:
> Hello grarpamp, mirmir
> 
> Speaking of, there is this website:
> http://ipleak.com/
> 
> If you go to Proxy/VPN in the left menu it will show you some info
> related to vpn usage detected.
> 
> In my latest firefox it says:
> 
> First seen2016/06/16 16:47:04
> Last update   2016/06/16 16:47:04
> Total flows   1
> Detected OS   Windows 7 or 8
> HTTP software Firefox 10.x or newer (ID seems legit)
> MTU   1406
> Network link  OpenVPN TCP bs64 SHA1 lzo
> Language  English
> Distance  11
> 
> 
> Where I use exactly OpenVPN in TCP mode. In Tor Browser this is not
> detected.

It won't work in Tor Browser using Tor, because Tor isn't just TCP/IP.
If you mangle Tor Browser to work without Tor, you'll see it.

> I am not sure how reliable is this tool, but what's the trick in normal
> firefox to disable this so that networking info is not revealed any
> more? How is this information gather by this website?

I'm not aware that it's blockable. It's not an HTML5 thing. Read up on
TCP/IP stack OS fingerprinting.

> On 6/16/2016 7:28 PM, grarpamp wrote:
>> On 6/16/16, Mirimir  wrote:
>>> https://vpntesting.info/
>>>
>>> I tested 29 Windows VPN clients for DNS, IPv4 and IPv6 Leaks.
>>
>> Nice.
>>
>> You might want to include
>> - For clients that may be doing packet filtering instead of just modifying
>> kernel routing tables... test ICMP, generic UDP (non-DNS), TCP, etc.
>> - The codebase and VPN protocol of each client (OpenVPN, SoftEther, etc)
>>
>>> hit VPN-specified nameservers directly while
>>> reconnecting after uplink interruption. But that's not a huge issue,
>>> in that they didn't hit other nameservers.
>>
>> Seems big if the direct hits were not encrypted over the VPN
>> and user's requirement is to encrypt to the VPN termination.
>>
>>> After uplink interruption,
>>> some failed to reconnect automatically
>>
>> These interruption, reconnect, renegotiation, timeout,
>> edge cases are important to discover.
>>
>>
>> More advanced users of Tor + OpenVPN might be interested
>> in this capability...
>> https://community.openvpn.net/openvpn/ticket/577
>>
> 
> 
> 
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Only nine of the 29 Windows VPN clients that I tested didn't leak

[s7r]

Hello grarpamp, mirmir

Speaking of, there is this website:
http://ipleak.com/

If you go to Proxy/VPN in the left menu it will show you some info
related to vpn usage detected.

In my latest firefox it says:

First seen  2016/06/16 16:47:04
Last update 2016/06/16 16:47:04
Total flows 1
Detected OS Windows 7 or 8
HTTP software   Firefox 10.x or newer (ID seems legit)
MTU 1406
Network linkOpenVPN TCP bs64 SHA1 lzo
LanguageEnglish
Distance11


Where I use exactly OpenVPN in TCP mode. In Tor Browser this is not
detected.

I am not sure how reliable is this tool, but what's the trick in normal
firefox to disable this so that networking info is not revealed any
more? How is this information gather by this website?

On 6/16/2016 7:28 PM, grarpamp wrote:
> On 6/16/16, Mirimir  wrote:
>> https://vpntesting.info/
>>
>> I tested 29 Windows VPN clients for DNS, IPv4 and IPv6 Leaks.
> 
> Nice.
> 
> You might want to include
> - For clients that may be doing packet filtering instead of just modifying
> kernel routing tables... test ICMP, generic UDP (non-DNS), TCP, etc.
> - The codebase and VPN protocol of each client (OpenVPN, SoftEther, etc)
> 
>> hit VPN-specified nameservers directly while
>> reconnecting after uplink interruption. But that's not a huge issue,
>> in that they didn't hit other nameservers.
> 
> Seems big if the direct hits were not encrypted over the VPN
> and user's requirement is to encrypt to the VPN termination.
> 
>> After uplink interruption,
>> some failed to reconnect automatically
> 
> These interruption, reconnect, renegotiation, timeout,
> edge cases are important to discover.
> 
> 
> More advanced users of Tor + OpenVPN might be interested
> in this capability...
> https://community.openvpn.net/openvpn/ticket/577
> 



signature.asc
Description: OpenPGP digital signature
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Only nine of the 29 Windows VPN clients that I tested didn't leak

[grarpamp]

On 6/16/16, Mirimir  wrote:
> https://vpntesting.info/
>
> I tested 29 Windows VPN clients for DNS, IPv4 and IPv6 Leaks.

Nice.

You might want to include
- For clients that may be doing packet filtering instead of just modifying
kernel routing tables... test ICMP, generic UDP (non-DNS), TCP, etc.
- The codebase and VPN protocol of each client (OpenVPN, SoftEther, etc)

> hit VPN-specified nameservers directly while
> reconnecting after uplink interruption. But that's not a huge issue,
> in that they didn't hit other nameservers.

Seems big if the direct hits were not encrypted over the VPN
and user's requirement is to encrypt to the VPN termination.

> After uplink interruption,
> some failed to reconnect automatically

These interruption, reconnect, renegotiation, timeout,
edge cases are important to discover.


More advanced users of Tor + OpenVPN might be interested
in this capability...
https://community.openvpn.net/openvpn/ticket/577
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk