[tahoe-dev] keeping private grids private

[Vladimir Arseniev]

On 12-03-20 10:59 PM, sickness wrote:

> If you're that paranoid about the network part
> have you tried tahoe on i2p? ;)

Well, we consider it prudent :) And yes, we have tried I2P, using one of
the public Tahoe-LAFS grids. It was painfully slow. But that was I2P via
VPNs, with no open ports. Maybe we could do better, using VPN servers
that permit port forwarding.

> (this is not entirely a joke, you could bootstrap a private
> i2p/ network in friendnet/darknet mode and route/tunnel only
> between your nodes ;)

Thanks for the suggestion. We'll look into it.

> On Mon, Mar 19, 2012 at 01:15:41AM +0400, Vladimir Arseniev wrote:
>> Thanks for your responses, Markus and Brian. Running the grid on a VPN
>> is still the best option, it seems (with firewall rules to block non-VPN
>> traffic). Only VPN clients can see the introducer, and connect to other
>> nodes on the VPN. But there are vulnerabilities.
>>
>> We've been using OpenVPN's commercial Access Server, which is presumably
>> well secured. However, the setup is vulnerable to attackers with
>> physical access to the server. We've mitigated the risk by encrypting
>> the server's credential databases, but determined attackers can read
>> passphrases from memory. We've tried running the server locally, and
>> forwarding the access port to a VPS, but connections (through commercial
>> VPNs) haven't been reliable enough, and latencies are huge. Still, we do
>> control the introducer, and could readily move our grid to a new VPN, if
>> necessary.
>>
>> OpenVPN's default star topology is also problematic, and creating mesh
>> networks seems complicated. We've looked at CloudVPN, but nodes can be
>> cloned, and there's no mechanism for refusing connections. Access
>> control depends on firewall rules, and using a public DHCP server with
>> static mapping and static ARP. That may be the way to go, however, if
>> the OpenVPN server bottleneck becomes an issue.
>> _______________________________________________
>> tahoe-dev mailing list
>> tahoe-dev at tahoe-lafs.org
>> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev