[tor-talk] Silk Road taken down by FBI

[mirimir]

On 10/06/2013 03:19 AM,
BM-2cWto4coLsoD6LrFmFcUeBAua7UU2gvTSR at bitmessage.ch wrote:

> If there is any wiretap in place to monitor VPN then it would instantly drop the connection because encryption has been tampered with - that's the whole design for VPN. Once a VPN server detects a line that has been tampered with, it will drop the connection and proceed to create a new connection. 

If the cable/fiber/etc just leaks a little signal to a passive tap, the
tap is undetectable (except through changes in adversary behavior).

> ---- Original Message ----
>  From: "mirimir" 
>  To: tor-talk at lists.torproject.org
>  Sent: Sun, Oct 6, 2013, 02:41 AM
>  Subject: Re: [tor-talk] Silk Road taken down by FBI
> On 10/05/2013 12:08 PM, Lunar wrote:
> 
> BM-2cWto4coLsoD6LrFmFcUeBAua7UU2gvTSR at bitmessage.ch (mailto:BM-2cWto4coLsoD6LrFmFcUeBAua7UU2gvTSR at bitmessage.ch):
> Not necessarily, as long VPN provider doesn't keep logs of your
> traffic. Like for instance, Phantom Peer works wonderfully since you
> can use bitcoin for their service.
> 
> Sorry, but no.
> 
> It is easy to order a wiretap on the VPN uplinks (without even the
> VPN operators knowing it) and to match packets going in and out.
> 
> Nobody is plausibly claiming that VPN services are as anonymous as Tor
> is. However, it's just as easy to tap uplinks for Tor routers. But of
> course, there are (probably) many more Tor routers than VPN services.
> And Tor routers are distributed among several spheres of influence, some
> of which don't cooperate readily.
> 
> Still, if one uses nested VPN tunnels from multiple providers in
> suitably chosen spheres of influence, it will be nontrivial for
> adversaries to install enough taps. Going through China, for example,
> would be a serious roadblock for US-aligned TLAs. Even with four nested
> VPN tunnels, latency and bandwidth are far better than using Tor.
> 
> Finally, it's not either/or. It's easy to include Tor in nested VPN
> configurations. Latency is typically over two seconds, but bandwidth is
> adequate, especially for UDP traffic.
>