Cryptostorm VPN integration for Qubes?

[Ken Watanabe]

Hello,

A recent study has revealed 14 of the top VPN providers are vulnerable to leaks via IPv6 as well as DNS.

http://www.engadget.com/2015/06/30/vpns-leak-your-information/

Cryptostorm has been researching VPN service providers for a while and additional failure modes observed include VPN client binary blobs that install adware, key loggers, trojans, etc. The details down to the level of traffic captures from the offending services are found at this Cryptostorm project site:

http://cleanvpn.org

Cryptostorm's offering is fundamentally different from every other provider out there. Specifically:

Zero Customer Knowledge VPN - buy a token, hash it, the hash is your username, your password can be anything. Bitcoin is just one of a number of purchase paths. Cryptostorm doesn't need to make dramatic vows about not logging it users - the system can't, as it never *has* your identity. The hash is impossible to reverse, this provides additional protection since it's impossible to derive the original token from it.

Adversary Resistant Networking - the Cryptostorm client, an open piece of Perl code, was modified to interdict the webrtc/STUN public IP address leak within days after this became public.

https://cryptostorm.org/viewtopic.php?t=8549

Recently, malware analysis experts Kaspersky reported that they faced a six month battle to eject espionage-ware from their network, identifying the effort as Duqu Bet, with Bet being the second letter in the Hebrew alphabet, a not so subtle slap at the Israeli government, whom they believe to behind the campaign.

https://securelist.com/blog/research/70504/the-mystery-of-duqu-2-0-a-sophisticated-cyberespionage-actor-returns/

Cryptostorm has had direct experience with Duqu Bet and from that have developed NIC parameter and sysctl hardening that interdict some of the midpoint injection methods used. This is still in the process of being included in the client side configuration, but it an example of the attention to detail Cryptostorm provides above and beyond the simple transport of packets.

Cryptostorm offers a free rate limited service which can be found at http://cryptofree.me - this service provides 256k symmetric capacity and mixes the free customers in with the paid customers of a busy node. It is felt that this serves several purposes, providing a no-cost means to evaluate the product, as well as supporting users in developing countries who need an alternative to Tor for whatever reason. You can examine the free service by using this config file:

http://pastebin.com/fvWgdYNn

We would like to hear from someone at Qubes regarding the following:

1. We want to share the particulars of the NIC and sysctl hardening being used, and what specific threats this eliminates, with an eye on this being included in the sys-net VM.

2. We would like the Qubes distribution to include a Cryptostorm ProxyVM preconfigured for the free low speed service.

Interested parties can send me a note at this address and I'll share my actual cryptostorm.is mail account so we can continue the discussion. I am happy to answer questions from other Adversary Resistant Computing efforts such as Whonix, TAILS, etc - we'd love to see Cryptostorm Zero Customer Knowledge VPN service bundled with all of them, and we're hoping given the recent negative attention on other providers that we can stampede a portion of the market into not simply vowing that they don't log, but instead using methods similar to ours, which eliminates that possibility entirely.

[syd2...@gmail.com]

Cryptofree VPN sounds good. Proxmox VPN is also good and should be included in Qubes. VPNs are better than TOR, because it uses people's computers/servers as its network. It's very suspicious - just looking at the strange names on the computers and you get the idea about the quality of some of the people who are part of that network. Personally I think it's a hideout for criminals and hackers.

[conp...@gmail.com]

On Saturday, 4 July 2015 03:21:26 UTC+1, Ken Watanabe wrote:

> A recent study has revealed 14 of the top VPN providers are vulnerable to leaks via IPv6 as well as DNS.

IMHO Qubes infrastructure provides everything necessary to prevent these. I'll admit that the wiki page on VPN configuration is bad and users might misconfigure openvpn and firewalls. Still, it's not a reason to install software that hasn't been reviewed/tested extensively, so I can't see it in a standard template. Qubes users don't trust their sys-net, consequently there can't be any reliance on any hardening in there :)

Of course, I'm speaking from my own standpoint and I don't represent our wonderful developers :)

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/06/2015 04:03 PM, conp...@gmail.com wrote:
> I'll admit that the wiki page on VPN configuration is bad

Can you please point to the "bad things" in the documentation?
https://www.qubes-os.org/doc/VPN/


I guess you are thinking about a specific service not a simple general
VPN. Because the VPN is only promising you to a directly routed remote
network optionally over an encrypted tunnel. Nothing really more.

So DNS leaking is really out of scope of ANY kind of VPN. For example
I have lot of use case where the DNS traffic is NOT expected to be
routed to the tunnel in any way.

However I admit that many of you are using a VPN in a specific way
where you want to route ALL of your traffic trough a VPN tunnel - but
this case the VPN itself is just a part of the solution. Because of
that I think this case should be documented as a service/solution for
your specified needs. Just like Whonix - and all the solutions around
that.



- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVm3G6AAoJEACyhZsQIQUVHPEP/0pUJonuVxarlzQExwbLL0aA
kYLqrfdcLJu+swOHMyR0mCPMOxjgiNvLRbXS3oijZGJsDS/VxDA66zavyusn3aS8
p0Y2058QlZqskauiqR59FXMtPpg5PI+PwYfzdAYHC80tT4hhlfY37EKVtn0Kxh71
V2Cz+34F0xL+1z1gW6iUHRdf/ZLFEy9P2AfpiRWVB41R8Lpv/mwPV/f+8/BqUcPq
v1t3mOgNvSUCoUB+8/LHqYgu+3/aHjbTEejGBOc7zDWxe6c7s0yimbikgxKaO3hQ
qz5oaEzzRKN4buOJiRkF8Dph0v64KpviXI10cFLtAT+q5e6jxLq0pY0pnlet79Bq
b4+iRrdUBy1/PgRw0L2xZCL5qBAruulQiueMcDKYJ/vCzeQnYy5oe/xOMrnptAWE
ukn8B25S8Ewxyqr+VNxgK3dJpe6GwZoT8b+gzbeJEOvYk61uZvu4gGvqNVZedCXI
P4P/W4XOSrDcuWVBiJA6FCZhfN8oXBndQwRoP4JlgmXUX5XdvkzkrYQckNoj+iGA
yCEPEvnTfEvw48qJOEnP4GaJkY+i9dlRKOybiB7qJ/PF+qFvFPB5Cjj6Fqw/UuEF
uwGqz9t2rVU3GlfEDSxo6XQ5L/AZA+hskDPwtQUZ3f56BsJPWSDOd+fpwV5LYsM6
boYWW8tI2IxCMbO8sS6B
=NuuI
-----END PGP SIGNATURE-----

[conp...@gmail.com]

On Tuesday, 7 July 2015 07:29:20 UTC+1, Laszlo Zrubecz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 07/06/2015 04:03 PM, conp...@gmail.com wrote:
> > I'll admit that the wiki page on VPN configuration is bad
>
> Can you please point to the "bad things" in the documentation?
> https://www.qubes-os.org/doc/VPN/
>

When users encounter this they get lost:
"WARNING: Currently the NetworkManager is not working in ProxyVMs as expected. Actually it will mess up the routing table and because of that your packets may not be routed to the VPN tunnel. - This surely occurs if your VPN wants to be the default gateway."

There was a thread some time ago which covered a firewallvm based on openvpn which has some hardening and convenience features that most probably can be applied to other VPN solutions as well. It even included scripts for obtaining DNS servers from VPN server and using those in Qubes DNAT rules.

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/07/2015 09:00 AM, conp...@gmail.com wrote:
> On Tuesday, 7 July 2015 07:29:20 UTC+1, Laszlo Zrubecz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> On 07/06/2015 04:03 PM, conp...@gmail.com wrote:
>>> I'll admit that the wiki page on VPN configuration is bad
>>
>> Can you please point to the "bad things" in the documentation?
>> https://www.qubes-os.org/doc/VPN/
>>
> When users encounter this they get lost: "WARNING: Currently the
> NetworkManager is not working in ProxyVMs as expected. Actually it
> will mess up the routing table and because of that your packets may
> not be routed to the VPN tunnel. - This surely occurs if your VPN
> wants to be the default gateway."

Well yes unfortunately that is a known bug.
Just revisited the issue and filled an up to date bug report:
https://github.com/QubesOS/qubes-issues/issues/1052

and there is no CLI related documentation maybe because that part is
completely not Qubes specific.

> There was a thread some time ago which covered a firewallvm based
> on openvpn which has some hardening and convenience features that
> most probably can be applied to other VPN solutions as well. It
> even included scripts for obtaining DNS servers from VPN server and
> using those in Qubes DNAT rules.

That's another story and really not a general vpn howto.
It is only covers an OpenVPN based service.

Any can write a proper documentation (by forking the repo and create a
pull request) and I (or any who have push rights) will include that
one to the official documentation to.

But again that is an openvpn only solution.

- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVm5gDAAoJEACyhZsQIQUV0HsQAJWSGGkGB9bf0tTQIzHjAvyL
aQ+3tz4CJkIKU3menGudOV9MWjeozP2TglVWevx0UHIX+7qJwgD1i4410VSbRS5K
5s/u8lpCdI/MNrO58RJn9zSLg1JGC9GqvvlKx5y/Me9qE/2afPnHTUqzkxDUqp7v
QZ0nF3lB8sgqNu5xkdeYltk+HrtwWnDvugDINoCVgArms1g2toUS+BTjl+qpoZWF
7GPAJ2MZAbRt6tO/Tyo9jDici7hBLMCRmSaozROs+VtwWrmR6m97jEj7eHY8v0lD
k76RMgvxY6cVnhzKOxtU7yoECZ13BG1HgFdcT3R1DmU2PvRLw15fze5pF7baGtBC
L2sJiZ/feGo4NS8V1i31RhxbUkDf3W/93WgBGHOy78QhQEYh4sszTPZ21DZE6gZl
0e6CVYU97OCw8EpEPfo8NUrEFEHg+3psJ1OX7M4AcKmXiLXjNXINV4RkEQPwkFfN
HLOEhtbFLgPgqBk9XS6oyuotPOWz8QJPopi5+WHUpULC4Wds/gByt5M8Y0WLCtJY
f8zOG/wzQff7CW0Aj7Wh6OznAv6j2cNoz3wXnM7XuivSdwTx4zp8r6YmZPo/2wCe
6isxV3qQ9UVcUHa0t4EALxdxlvS3jgEWINl02HtenIbldWolvySXhcGaighz1NB8
mlnInUeP5TzV2bu1VNWo
=U7w+
-----END PGP SIGNATURE-----

[cprise]

On 07/07/2015 02:29 AM, Zrubi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 07/06/2015 04:03 PM, conp...@gmail.com wrote:
>> I'll admit that the wiki page on VPN configuration is bad
>
> Can you please point to the "bad things" in the documentation?
> https://www.qubes-os.org/doc/VPN/

As is, this doc is far from helpful. About 2/3 of it (proxy vm + network
manager) is a description that denies it will even work.

The net vm portion is a few sentences that says 'Use NM in net vm but
your password/secret is unsafe there.' (I'll also add the f20 NM would
go berserk when asked to auto-connect both wifi and VPN.)

The rest is a brief recommendation to 'do something else' using appvms.

>
> I guess you are thinking about a specific service not a simple general
> VPN. Because the VPN is only promising you to a directly routed remote
> network optionally over an encrypted tunnel. Nothing really more.
>
> So DNS leaking is really out of scope of ANY kind of VPN. For example
> I have lot of use case where the DNS traffic is NOT expected to be
> routed to the tunnel in any way.

Of course it isn't out of scope. Using that logic above, Qubes should
leave it to the users to configure all the VM firewalls, as implementing
VM functionality is not in the scope of ipchains.

If it involves network activity its a candidate for routing over a VPN.
Tools like OpenVPN simply leave the DNS and firewall aspects of a
tunneling solution to a different layer above (though none of those
layers are meant for Qubes). Similarly, using Tor with reasonable
privacy has required some integration between different layers of
software (that's where the Tor Browser Bundle comes from).

This type of VPN represents a critical use case that Qubes should have
covered _out_of_the_box_ so to speak. Why?

* It is popular

* It demands a 'no leaks' configuration

* Its the simplest configuration that's considered useful and truly
"private"

* It adds a lot of security when one must use public/misc wifi access points

* Qubes handles it easily[1], even if the instructions are more involved
than clicking a few icons.

There's no reason not to offer a solid example for complete VPN
tunneling. Example scripts could even be made part of the Qubes firewall.

>
> However I admit that many of you are using a VPN in a specific way
> where you want to route ALL of your traffic trough a VPN tunnel - but
> this case the VPN itself is just a part of the solution. Because of
> that I think this case should be documented as a service/solution for
> your specified needs. Just like Whonix - and all the solutions around
> that.

I'm not even sure where the value is in configuring more complex
subnet-specific routing for any given Qubes VM. In a way its akin to
user-based security, mixing threat models under a single kernel instance.

Most people who need this capability will either already have
partitioned their work between Qubes domains which do/don't route
through a VPN VM, or else they will have been assigned a corporate
machine that is pre-configured for the purpose.


1. https://groups.google.com/forum/#!topic/qubes-users/-9gR1Va3BnY

[cprise]

I think he's referring to my thread here:

https://groups.google.com/forum/#!topic/qubes-users/-9gR1Va3BnY

Noted about pull requests. However, the Howto does not have to be
generalized in order to be helpful; It can be specific and also be
expanded later to include some other recognizable scenarios as other
users present them.

[conp...@gmail.com]

On Tuesday, 7 July 2015 13:35:58 UTC+1, cprise wrote:
> I think he's referring to my thread here:
>
> https://groups.google.com/forum/#!topic/qubes-users/-9gR1Va3BnY
>
> Noted about pull requests. However, the Howto does not have to be
> generalized in order to be helpful; It can be specific and also be
> expanded later to include some other recognizable scenarios as other
> users present them.

Maybe for now it would be good to at least reference the thread in the wiki until someone makes a tutorial out of it?

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/07/15 14:34, cprise wrote:
> I think he's referring to my thread here:
>
> https://groups.google.com/forum/#!topic/qubes-users/-9gR1Va3BnY
>
> Noted about pull requests. However, the Howto does not have to be
> generalized in order to be helpful; It can be specific and also be
> expanded later to include some other recognizable scenarios as
> other users present them.

Absolutely agree.

And just a suggestion for any specific guide:
Summarize the goals/problems to be addressed with the solution. Than
the reader can decide if it is something useful for him or not.

- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVm+0WAAoJEACyhZsQIQUV0GIP/2F5Ty3qj04SR8KaWpvXrccq
toPf+oV3HasL1zsCudEzEKFNdoRDwbCl93LCbIpQIB53pTUCfKtN1TRSsa8tgQHi
OKZTE//D6PZrmro2nYgN7XTd2SMkTh/kLMcy90CbdzBAevNvPVbNSlhfjqj7Nx3M
ZI9D0ULc43v3xkFCncZnSdGw9rm5KXVYmyImIYktJRazT1L+Kx2RrlzKVfE7kJoB
7N9jiEOzcLDMBrTaoM6VyPgrhFCNZr18KzYxOPXF+lWpTrVR4lGZd0DAIR5MwLEq
i+EE4SA/OPsZVD5AerUc7Yutc/I0EsH5bgW511q4Iybj7Xq4k0V0cyX8+LF/mGNH
6nytbfzkG+3CtmC4Q2L/LzXviPG8vK+C+Y3IkAIWPL3S6mHCIzYNYGFMB3NfN6o2
ueswTVYWaxYAwqUKG4uN/qyLk19J+wNRKHItKvHy5tJ4wuLEabqT0gJEBLy6qUwv
OnxTtz1bGRIAmwleJILjud6QXmRu38FtgJac4f9mi8eR9xAznWMiS5F8uCvSZJSo
ybNKAPjqRAnzGwFLKBhDm0lh35Tki2q1cGFQbzNZn6iOXRI+KB9o2L+Z4Bb3rWa3
3P5i4dXxBpJzkg9CKQNvElVmQiTlxzvEzUHPLhwyfzQhPbBMiC0LCI2Ul58vqc60
/YZ329fl6MXt/9fCzvox
=lTVU
-----END PGP SIGNATURE-----

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/07/15 14:20, cprise wrote:
>> On 07/07/2015 02:29 AM, Zrubi wrote:

>> Can you please point to the "bad things" in the documentation?
>> https://www.qubes-os.org/doc/VPN/
>
> As is, this doc is far from helpful. About 2/3 of it (proxy vm +
> network manager) is a description that denies it will even work.

Yes, you are right again :)

But it has a history:

When I was creating that page It was a working and tested setup.

Then it was broke by an unknown update (not even know if it was a
fedora or Qubes one) and that easy and general Network Manager based
setup was not working any more :(

Instead of deleting that page - just noted that will not even work.

Still believe that this is the way if any wants a "one click" VPN
solution. I already 'created' some nice icons for the NM applet - but
because it is not really working this shiny thing just useless - so
that project is just waiting for the real bug to be eliminated :)

> The net vm portion is a few sentences that says 'Use NM in net vm
> but your password/secret is unsafe there.' (I'll also add the f20
> NM would go berserk when asked to auto-connect both wifi and VPN.)

At least someone tried such a "not recommended" setup ;)
But for sure: we should note such experiments as well.

> The rest is a brief recommendation to 'do something else' using
> appvms.

Well, because it is really up to the user. - But improvements are
always welcome :)

>> So DNS leaking is really out of scope of ANY kind of VPN. For
>> example I have lot of use case where the DNS traffic is NOT
>> expected to be routed to the tunnel in any way.
>
> Of course it isn't out of scope. Using that logic above, Qubes
> should leave it to the users to configure all the VM firewalls, as
> implementing VM functionality is not in the scope of ipchains.

My definition for Qubes:

It will allow you to be the weakest link - even if you are a highly
skilled security expert.

That's why I really don't believe in any preconfigured 'easy to use'
security solutions. If the user not fully aware of what he is doing he
will fail. Sooner or later - but for sure.

> This type of VPN represents a critical use case that Qubes should
> have covered _out_of_the_box_ so to speak. Why?
>
> * It is popular

Sure :)

> * It demands a 'no leaks' configuration

Demands: yes. Ever be able to achieve that: NO. Never ever. at least
not with a single VPN.

> * Its the simplest configuration that's considered useful and
> truly "private"

It is really depends on the server side AND the expectation of the
user. They are always expecting too much - if not impossible things.

> * It adds a lot of security when one must use public/misc wifi
> access points

It is depens on what you think about security.
Again the average user usually expecting too much from a simple VPN.
for example that DNS leak issue.

> There's no reason not to offer a solid example for complete VPN
> tunneling. Example scripts could even be made part of the Qubes
> firewall.

Agree.
And - as I noted - pull request are welcome.
I'm also just a contributor as many of us.



> 1. https://groups.google.com/forum/#!topic/qubes-users/-9gR1Va3BnY

I'm sure that this "howto" is really useful - and it should be
rewritten in a proper format to be able to include to the
documentation site.

- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVm/S5AAoJEACyhZsQIQUVhK0QAIvYzH+LVob4ypIrnf3qD8Es
khjDckRuj0YIhfex5ghypy8dC8ifblFar+gd0m+GuVte2Z4rkOR2xgQS1faLOUyk
WaOK/P1KvMAFi0QmD6im5jwF+V6cY5QG5V/4VQCzNP+lVh8StPeD/FN51/WO13Cy
7K4sMGQlRXU5zEbeanHmA8OXH1HJXlz/Qt2TH+XKqyhAYI41U6w9gHjBt0FmaYlD
gHn6e+jOdGC1FlkSU022ARJmPMu4UdD/aof2ZBv3c3KC/9kBR5SMg2t2de/XRjUW
kO1SHsvWUP/mHbg3/tEN4TLMW5MB3ZiUUid6tTw4x3q8OCYt6i/6aDUboeVImNes
ys3DRCqpjl7IbD0eH943BAjytZ8PKuzD855eri52tiqOiOGA8W/+/Ckbcx2QVtV/
CXAxJLB0wI5EGwJl7RAx//AtgOTl6sABXHI48q7g/41SglME3Uo1VfDw4E5rZvrQ
wa76DYrVImLXJ+f6tBFOAvSzggARFC1hab4Audpa4AJLJFlEuzhkq2O5phq76t3O
A8QozdyJBE9rX5OfrL+vrUffMsY7i/I/LCR6jL8FtggNM2+nVX7pbZR8fKAv75co
ibRl8aY1ISNfxv1MGJwMX+SX9ro/2zp3sD6yDtWD9GsFlTvdJr6YVKmynnffgDep
c81t/LKPUiCLmxEjS/jY
=QYuo
-----END PGP SIGNATURE-----

[Ken Watanabe]

Documentation pages should have a "last date modified" so viewers have an idea of how old the information is. This particular one would also benefit from mention of more than just the graphical widget version.

Some people need screen shots and for those that do it's a vital resource, but there are just as many of us who'd like information on what's in /etc, /usr/local/etc, and so forth.

The retraction should be at the very top, so Google picks up that fact and fewer people will get sucked into spending five minutes on a page at an authoritative site that is no longer authoritative.

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/5cQd7UTN4kg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/559BF4BA.6050808%40zrubi.hu.

For more options, visit https://groups.google.com/d/optout.

[Franz]

Zrubi you seem too hard here. I admit it is better to stop people hurting themselves, but we are dealing with a VPN, that most people use for some additional security when connecting from a hotel room or for accessing stuff reserved to other country IP addresses.
 

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CADyx%3DktAG%3DzR7vSnxd6Dr9gNTWZ3wj-1NO147E7wQYhZ6401jQ%40mail.gmail.com.

[Noah Vesely]

On Sunday, July 5, 2015 at 8:53:15 PM UTC-7, syd2...@gmail.com wrote:

Cryptofree VPN sounds good. Proxmox VPN is also good and should be included in Qubes. VPNs are better than TOR, because it uses people's computers/servers as its network. It's very suspicious - just looking at the strange names on the computers and you get the idea about the quality of some of the people who are part of that network. Personally I think it's a hideout for criminals and hackers.

Most users of Tor seek to avoid mass surveillance and/ or censorship. Many, such as journalists and activists also use it to avoid targeted surveillance and attacks (computer and physical). Some use it to commit both moral (e.g., selling alcohol in UAE) and immoral (e.g., sharing child pornography) activities. What's interesting is that a recent analysis revealed that only 1-3% of Tor activity is related to criminal activity. (A quick Disconnect search did not pull up a source for this--maybe someone has it or could help find it--anyway, I'm sure I remember this figure correctly.) That's about the same for normal internet activity.

Phishing, malware distribution, sale of illegal substances, child pornography, the plotting of terror attacks, etc. still occurs over the normal internet. From the Tor website:

"Criminals can already do bad things. Since they're willing to break laws, they already have lots of options available that provide better privacy than Tor provides. They can steal cell phones, use them, and throw them in a ditch; they can crack into computers in Korea or Brazil and use them to launch abusive activities; they can use spyware, viruses, and other techniques to take control of literally millions of Windows machines around the world.

Tor aims to provide protection for ordinary people who want to follow the law. Only criminals have privacy right now, and we need to fix that.

Some advocates of anonymity explain that it's just a tradeoff — accepting the bad uses for the good ones — but there's more to it than that. Criminals and other bad people have the motivation to learn how to get good anonymity, and many have the motivation to pay well to achieve it. Being able to steal and reuse the identities of innocent victims (identity theft) makes it even easier. Normal people, on the other hand, don't have the time or money to spend figuring out how to get privacy online. This is the worst of all possible worlds.

So yes, criminals could in theory use Tor, but they already have better options, and it seems unlikely that taking Tor away from the world will stop them from doing their bad things. At the same time, Tor and other privacy measures can fight identity theft, physical crimes like stalking, and so on" [1].

It seems like your diagnosis of Tor users stems from too much uncritical exposure to mainstream media sources. This is evident too in your un-prefixed (e.g., malicious) use of the word hackers. It has quite a different meaning in CS/ programming circles [2], which has also garnered more mainstream attention as of late in the form of "life hacks."

When you say Tor is "a hideout for criminals and hackers," you are saying a good portion of this mailing list are criminals and (malicious) hackers.

[1] https://www.torproject.org/docs/faq-abuse.html.en

[2] https://stallman.org/articles/on-hacking.html

~*~*~*~

Noah

[syd2...@gmail.com]

There's an easy way to check if your activities are being tracked in TOR. Just go to a website that has a counter for members and guests. Go during a lull so that you are the
only "guest" listed. Then stay on the site for a while to see if the guest counter rises after you. If it does - at a number of such sites - then you are being tracked. Since
this is TOR - which is supposed to be private and anonymous - it indicates that TOR is not as safe and secure as it is claimed. There appears to be some people - probably with
computers as part of the network - who act as predators (black-hat hackers) capable of preying on other TOR users. And some typical TOR computer names reflect delinquency - like "billythepirate"
or "sallymicrowavescats" - which also doesn't engender much confidence in the quality of the network. A freebie VPN doesn't have this type of problem. It might have other
problems, but it is safer than TOR IMHO.

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/11/2015 04:48 AM, syd2...@gmail.com wrote:
> There's an easy way to check if your activities are being tracked
> in TOR. Just go to a website that has a counter for members and
> guests. Go during a lull so that you are the only "guest" listed.
> Then stay on the site for a while to see if the guest counter rises
> after you. If it does - at a number of such sites - then you are
> being tracked.

This is a really bad conclusion.

TOR is ONLY hiding your public IP. But you will still have a public IP
(the IP of the TOR exit node) and it probably still unique on a single
site.

Moreover they may see your private IP, but surely your browser/OS
version and settings which easily makes you UNIQUE no matter if your
public IP is not really yours.

User tracking is not avoidable by using only TOR - or any VPN solution.

- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVoNeuAAoJEACyhZsQIQUVOBoQALN9OqOXQwFpeLXVZZva90+d
ofGBsXIf+1lQwtO6+zhnNzXqUrEqzhnrCVlSXxDvYK7ZX4kCqAD/DkaOsi3o9tcX
BFIbopPKqhxAe8Z7WxWx2DJMuffMOf1alGCg/D0LpqmMks1Nibd32/3Tqgk3a7/6
sHrkX7X+0qW2VLXK95ULtpnttgnsPtPjW3or0AqzLQI8TG57prhdL5ow9VIBLP3p
uPsD5FeECK1ZcJaQVLE8X5XNCQYisZDKLjXYuYxDiZu31h2Gtv0cNsu1TPHJixwd
gsGVm6uHKxtXIVzYKf6fifLZUlgVP7K/rlnWneRFxCPGEvuSP5IY826KaswZ4e1X
V3rpDj2eRTo0wQuOmtvRldp+auKvfXcNRpwlPtiUkR1ue1bsZKheMxaZLJYde86i
yLRDCk+1r4gbB35TQ3czaTQuLtqGo9B8ZVpMNhn7Mw2ETDHIvNfgXPRMLedpvgky
DErdrTpEGCkwh7fu+hY+xORS5vhO6ZaokOrUFNxdgjV8hyUmkga2yq6Z4Azc17BN
hIfqCGtguGKsnZ6UKLMHIcCueJq3i2dkorz2KYVVq3DkilSVXDAFuYgKAqpQu2E/
PKARG6CsH1H29FePadM9+xlYS3EE9J9T+BuyfSE0LGPT1klj6nHAXowMVKlcSsFp
yPh8Vno/j7Snb39iAJs+
=gc0g
-----END PGP SIGNATURE-----

[Zrubi]

On 07/11/2015 08:45 AM, Zrubi wrote:

> User tracking is not avoidable by using only TOR - or any VPN solution.

Check this link to see:
https://panopticlick.eff.org/




--
Zrubi

[J.M. Porup]

Others have noted that occasionally appvms will fail to mount /home/user
properly. It happens every now and again, and shutting down and
restarting the appvm always fixes the problem.

I usually notice this problem when hitting Ctrl-R in a shell and find
.bash_history missing.

Once or twice I've observed this behavior in dom0, and a system restart
is needed to correct it.

A couple of days ago, however, I hit Ctrl-R in dom0 shell and found the
attached file sitting where my .bash_history should be.

Running R2.

Jens

[Gustav van der Merwe]

Most interesting, I too have had the private image fail to mount properly. What large confuzzles me is how .bash_history could disappear, much less be replaced by a log. Note, in my case the .bash_history disappeared in an AppVM not dom0. Most annoying, the history could have been nicely edited and I wouldn't have minded but I had to manually reconstruct a few complex commands that I usually recall via Ctrl-R.

Regards,
Gustav van der Merwe