3 ms·
Yeah, so? If the server network is MITMed, you are fucked at so many levels that it doesn't even matter anymore.
by Nyr 11y ago
Yeah, so? If the server network is MITMed, you are fucked at so many levels that it doesn't even matter anymore.
- laumars 11y agoNot if you're running HTTPS you're not. You cannot have code injected into a HTTPS connection like you could with plain text HTTP. And even in the worst case scenario where the entire connection is re-routed to a rogue server: you would get a nice big warning that your connection isn't secure and the download would fail. Thus again preventing the malicious code from running on the users VPS. 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.
- Nyr 11y ago> Not if you're running HTTPS you're not. 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.
- laumars 11y ago> 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. 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 It's called "social engineering" and actually quite a comment method of attack. > 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.
- Nyr 11y ago> One cannot simply obtain a cert from a trusted CA. 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.