[tahoe-dev] keeping private grids private

sickness sickness at tiscali.it
Tue Mar 20 18:59:13 UTC 2012


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

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

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
> 



More information about the tahoe-dev mailing list