[tahoe-dev] keeping private grids private

Vladimir Arseniev vladimira at aport.ru
Sun Mar 18 14:15:41 PDT 2012


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

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE





More information about the cypherpunks-legacy mailing list