This is sort of a general question to the DigitalOcean staff at large:
Given this piece of recent news:
Republican senators yesterday introduced legislation that would overturn new privacy rules for Internet service providers. If the Federal Communications Commission rules are eliminated, ISPs would not have to get consumers’ explicit consent before selling or sharing Web browsing data and other private information with advertisers and other third parties.
and following it up by saying “It is time for permanent VPN’s” .
Can anyone comment as to how DigitalOcean treats user-data from droplets that are being used as a VPN? If DO is my endpoint, then is/will my data be collected? Does DO still have a commitment to privacy in this case?
If so, then I think DO should have that clearly stated as a selling point. I have a hunch that VPN’s are about to become very popular.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
@hansen
Yes, traffic is going in and out to DO is viewable to them and their ISPs - unless it’s encrypted, which it would be in case of OpenVPN/SWAN/etc. * your ISP can’t see anything but an encrypted VPN tunnel. DO (and their ISPs) will only be able to see traffic from DO to the final website, if it’s non-HTTPS*
so that jibes with what I was thinking…using a droplet as an openVpn server essentially encrypts things up to DO (and their ISP)…so, going back to the first post:
ISPs would not have to get consumers’ explicit consent before selling or sharing Web browsing data and other private information with advertisers and other third parties.
I would like to know if DO has plans to take advantage of this data to share/sell to advertisers and third parties, or does their dedication to privacy extend to using them as a VPS end-point
There is still the issue of DNS. In my freebsd droplet, they use google for DNS.
If someone wants to do a write up on strongswan on DO FreeBSD, I’d sure appreciate it. I’m sort of there. I can connect from my phone, but can’t connect to the internet from DO. Strongswan is quite cryptic, but then again, most computer stuff is cryptic until you know it, then you can’t understand why someone else finds it confusing. ;-)
@sierracircle
When it comes to Droplet access, DigitalOcean isn’t able to physically login to your server from their end – this is even more so the case when you’re using SSH Keys instead of just a password.
If you lock the
root
user, create asudo
user, and then create a 4096 or 8192bit SSH Key for login, there’s basically one way in unless somehow someone manages to crack a 4096 or 8192bit key. If someone has that much time, then you’ve got bigger issues – that, or your server is hacked due to some sort of security issue stemming from packages or software in general being out of date.Generally, the last issue isn’t an issue if you stay up to date and if you’re using SSH Keys, logging in using the console is no longer a valid option (with the
root
user locked).In terms of logs, if logging is disabled on the VPN service, and the VPN is properly setup, encryption would be to and from the VPN and logs would not exist. With proper setup, this shouldn’t be an issue either.
That being said, one other party plays a role and that’d be your ISP. Since encryption is two-way, they would have to physically intercept and decrypt the traffic. If SSL is correctly setup, this shouldn’t be a concern either. It’d take far too many resources (which even at scale, your ISP doesn’t have) to sift all data from all customers and then decrypt it.
If you’re overly concerned, I’d recommend looking in to StrongSwan as a VPN. Of course, there are upsides and downsides to both (comparing StrongSwan and IKEv2/IPSEC to OpenVPN), so you’d have to find what you’re most comfortable with. Both are, at the end of the day, secure ways to connect when you want sensitive data encrypted.
NOTE: Since there’s some back and forth on whether 4096/8192bit keys are worth it, if you lean towards the side that sides with little gain being the result from their use, there’s also elliptical curve cryptography. It all depends on what your SSH client will support (as not all support both RSA and ECC).