Of course then the VPN provider is the single point of failure, but if it's trustworthy enough only folks with proper court orders should have access to my traffic. And it's an extra ten bucks per month or so.
Is it possible to run your own VPN on a VPS host, digitil ocean or linode or similar?
Will happily cancel my service if it continues.
Yes. I run several types of VPNs and shadowsocks on a VPS host. I mainly use it to bypass GFW though.
Of course, trusting the VPS provider and its ISP is no different than trusting a VPN provider and its ISP.
It's possible and very easy: https://github.com/Nyr/openvpn-install
Disclaimer: I'm the script creator.
wget git.io/vpn --no-check-certificate -O openvpn-install.sh && bash openvpn-install.sh
Granted the double ampersand offers some protection, sadly it's still little better than the often criticized:
curl http://example.com/install.sh | bash
I do appreciate the work you've done. But given the security and privacy expectations of VPN, it might be worth having a little more transparency in your install instructions - even if that means splitting your instructions into 2 lines.
But, I always feel a little annoyed when people complain about piping curl into bash. If you know enough to see the danger, you also know enough to avoid it. Just curl to a file and read it, or open the web page and read it. Take some responsibility.
I'm with you on the https and the short link, though.
https://github.com/Nyr/openvpn-install/issues/24 https://github.com/Nyr/openvpn-install/issues/66
> given the security and privacy expectations of VPN
The security and privacy expectations are that the network for the server is not compromised. If that's not the case, why would you want the VPN hosted there in the first place?
Just because a persons hosted VPS might be trusted it doesn't mean that:
1. The git.io redirects to the expected location. Anyone could clone your git repo then put a malicious script in a different shortened URL
2. Nor that someone couldn't MITM between the the user and the git.io
3. Nor similar MITM attacks between git.io and github
Security is only as good as the strength of your weakest link.
You're also still ignoring my first point as well.
I really don't get your careless stance here. Github already comes with an SSL cert and you don't actually need a URL shortened for the type of link you're publishing. So all of these complaints people are making are so very easy to solve. But instead you are intentionally following bad practices. Frankly, if this is your attitude towards security then I really don't think you're the sort of person who should be writing installers for VPN servers to begin with.
Yes, you are. If your adversary can MITM a datacenter, it's likely that a rouge cert can also be obtained from a trusted CA. If your threat model includes this kind of adversary, please don't use my script. You should also consider how funny would be to host a VPN and route your traffic like this in a network which you don't trust.
> You're also still ignoring my first point as well.
What would an adversary accomplish pointing a DIFFERENT short URL to a malicious script? I don't understand. I'm only using/listing git.io/vpn, so whatever someone does with other URLs is not my problem. There is some fork using git.io/ovpn for example.
> I really don't get your careless stance here.
I'm not careless. You can either run the one-liner which clearly states --no-check-certificate or download and examine the script as long as you want. The choice is on you.
> Github already comes with an SSL cert
But minimal distro images don't come with trusted CA certificates, so it's useless. Yes, I could install them. No, I don't want to.
One cannot simply obtain a cert from a trusted CA. Hence how they become signing authorities. Granted it's not impossible to do, but it is very difficult. Certainly a far better assurance than not running HTTPS at all.
> If your threat model includes this kind of adversary, please don't use my script. You should also consider how funny would be to host a VPN and route your traffic like this in a network which you don't trust.
We're not talking local network here - literally nobody can trust the internet. Hence why CA's exist in the first place. This isn't some weird edge case threat model, this is something that's well known and already handled. And it's something that is already supported by Github but you are intentionally breaking.
> What would an adversary accomplish pointing a DIFFERENT short URL to a malicious script?
Do you really need that answered for you?
1. Clone repo
2. Publish their own shortened malicious URL in cloned repo
3. ???
4. Profit
> I'm not careless.
Given this script is aimed at less-technical people, I'd say it's rather presumptuous to assume they'd even realise just how careless it is to run a script downloaded from an unverified source.
> But minimal distro images don't come with trusted CA certificates, so it's useless. Yes, I could install them. No, I don't want to.
That's an edge case. You can add a comment to disable the certs in that edge case - or better yet, instructions on how to install the CA certs.
Every excuse you make is really just a plea for your own laziness. "it's the users responsibility" - no it's not, you're providing instructions for them thus it's your responsibility to get those instructions right. "they might not have CA installed", so add a footnote about installing that. I mean seriously dude, Github have already handed you the tools you need securing the install - there's literally no good excuse for disabling them.
One can't simply MITM a datacenter.
> literally nobody can trust the internet. Hence why CA's exist
lol
> it's something that is already supported by Github but you are intentionally breaking
I'm not breaking anything. It is supported by GitHub but not by many of the client machines (by default).
> It's called "social engineering" and actually quite a comment method of attack.
I unfortunately can't fix user stupidity.
> That's an edge case.
That's when you've proved you have no idea about what my user base is. Minimal images are very common for OpenVZ templates.
Anyway, and to end this: you've already stated your points and I've given you my explanations. You can either accept them or not, but I don't want to waste more time on this - feel free to fork if you don't like it.
SSHing onto a Linux server in some secure datacentre doesn't magically mean that everything that server connects to outside of the datacentre is also going to be secure. I assume that you do actually understand how the internet works? :p
> I'm not breaking anything. It is supported by GitHub but not by many of the client machines (by default).
Of course you're breaking things. You're breaking the security of HTTPS by disabling cert checking. And you're breaking readability of your install code by using URL shorteners.
As for HTTPS not being supported by many of your client machines by default, it's so very easy to rectify:
$(which apt-get yum) install ca-certificates
> I unfortunately can't fix user stupidity.
But you're forcing user stupidity by using stupid defaults. It's quite literally your fault that they're being stupid as you're recommending they do stupid things.
> That's when you've proved you have no idea about what my user base is. Minimal images are very common for OpenVZ templates.
I happen run a hosting as a side project and almost exclusively use OS containers for personal projects. So I'm well versed in these kinds of containers and the kind of users you're targeting. You're just making excuses for bad security practices.
> Anyway, and to end this: you've already stated your points and I've given you my explanations.
You've given excuses, not explanations. I've demonstrated how easy it is to work around the limitations you've put in place. You've just given lazy excuses as to why you couldn't be bothered.
The crux of the matter is when building gateways you should NEVER default to insecure settings like you are currently doing. Period.
> feel free to fork if you don't like it.
To be quite honest, it could benefit from a complete rewrite. The code is functional but messy, your OS detection could use a little fine tuning too. But the real problem is that there's more instances within your script of code getting pulled from the internet with certificate checking disabled, and that would also need to be fixed (but at least you're not using URL shorteners there).
Your intentions are noble, but sadly your execution is less so. Which is what happens when you never listen to advice. And looking at the comments on your repo, this has been an issue that has been raised a multitude of times before. So it's not just me being an elitist :)
Feel free to submit a pull request if you can improve OS detection, it certainly is primitive.
> But the real problem is that there's more instances within your script of code getting pulled from the internet with certificate checking disabled
I have just pushed a commit with a better approach.
" Streisand sets up a new server running L2TP/IPsec, OpenSSH, OpenVPN, Shadowsocks, sslh, Stunnel, and a Tor bridge. It also generates custom configuration instructions for all of these services. At the end of the run you are given an HTML file with instructions that can be shared with friends, family members, and fellow activists. "
It's effortless.
Yes, but that's okay. Privacy is part of the VPN market's value prop; companies in that space compete on it, unlike ISPs.
I tried doing the same with my mobile but it either eats my battery alive or kills instant notifications. I HATE that tracking tag that mobile carriers are adding.
Sure, but the issue at hand is js/html injection, which a VPN more or less (generally more) obviates.
A.) a dumb-pipe retailer, who you may not have freely chosen, and who has no motivation to respect privacy, to
B.) a privacy provider who is easily replaceable and whose entire business is based on quality and integrity.
Seems rational to me.
If you try to do that, the VPN client will notice that the spoofed server isn't presenting a valid certificate or doesn't use a valid key, and refuse to connect. Same reason you can't "just" middleman an HTTPS connection.
Besides, there's no need to spoof. The point of the VPN connection is to protect against the wifi router (even the legitimate one!) reading the traffic. By spoofing, you're just replacing a dodgy wifi router with another dodgy router.
Many PC antivirus/firewall programs do it right now.
Entities not in control of your PC can't MITM an HTTPS connection, barring a catastrophic bug. And it is catastrophic. If you have a way to do this, please tell everybody because it's going to be the next Heartbleed.
The entire point of HTTPS is to prevent stuff like you're describing. And it does work, for the most part. Bugs happen, but they get fixed as they're discovered. It's definitely not "extremely easy."
Please go read up on this stuff before speaking authoritatively:
More succinctly, the phrase "man in the middle" kinda loses meaning when the man in question is your own computer.