> One of these markets involves competing on security and privacy.
one of the points raised in the article is that it's difficult to evaluate whether the VPN actually follows its logging policy. if they say they don't log, you pretty much have to take their word for it until information to the contrary somehow goes public. it's entirely possible that LE could be using a VPN as a honeypot and forcing everyone they catch to stay quiet through a plea deal. you'd never know until someone broke ranks. the VPN company could just as easily log your traffic and sell your usage data. unless they're sloppy about it, how would you find out?
> One of them involves colluding on influencing FCC policy.
That is an extremely US-centric view.
Aside from that, physical ISPs have something to lose, as they have a very real infrastructural investment; whereas becoming a "VPN provider" literally does not entail more than "rent a few servers, run OpenVPN, buy a billing system license, hire a marketing guy".
It's entirely viable for a VPN provider to just disappear overnight and set up shop under a different unrelated name at virtually no cost to them, if their old brand gets burned. That significantly changes the trust equation, and not in favour of VPN providers.
Unless they're a (natural or artificial) monopoly, like... pretty much every ISP in North America is. Comcast has the reputation of, well, Comcast, and they're doing just fine.
> Becoming a "VPN provider" literally does not entail more than "rent a few servers, run OpenVPN, buy a billing system license, hire a marketing guy".
Yes, that's a good thing: it means that VPN providers, unlike telcos, are under selection pressure. Which means that for VPN providers, unlike telcos, reputation actually means something; the top VPN provider is striving much harder for your dollar than the top telco is.
Certainly, don't pick a VPN provider at random, but you wouldn't anyway.
> Unless they're a (natural or artificial) monopoly, like... pretty much every ISP in North America is. Comcast has the reputation of, well, Comcast, and they're doing just fine.
Once again, that is an extremely US-centric view.
> Yes, that's a good thing: it means that VPN providers, unlike telcos, are under selection pressure. Which means that for VPN providers, unlike telcos, reputation actually means something; the top VPN provider is striving much harder for your dollar than the top telco is.
Except that isn't how the industry works, at all. Virtually all "reputation" that VPN providers have originates from paid product placements (see: the myriad "VPN reviews" that are chock full of affiliate links, YouTube ads, etc.), and providers are assumed legitimate unless shown otherwise by default.
This means that said "reputation" is 100% reproducible under a new brand without ever having a single long-term customer vouching for you. There's no competition on quality; the competition is on marketing only.
Exactly why the industry has turned out that way and doesn't follow the "competition breeds quality" narrative that people on here love to put forward, is left as an exercise to the reader.
I would guess that it's because higher quality is pretty hard to achieve relative to most services. You can only offer a few things, stability, speed, perceived security and given the ease of use of the cloud, providing all three of those is relatively simple. The smattering of new VPN services are a little like altcoins in that respect. Going from perceived security to demonstrable security will require a strong demand and right now it seems ignorance is blunting that demand for individuals, where companies just roll their own servers they know they can trust and have access to.
> Once again, that is an extremely US-centric view.
It's a Canada-centric view, for me. :)
But seriously, does anyone care about VPNs outside of North America? Why would you, if your ISPs aren't awful? Do most VPN services even bother to advertise outside of the North American market?
> This means that said "reputation" is 100% reproducible under a new brand without ever having a single long-term customer vouching for you.
Why pay attention to word-of-mouth reputation, when survival under competitive pressure is a much more objective signal of reputation of its own?
If the bad actors need to restart with a new brand every few years, then why not just look for the oldest brands around (who must therefore have done this the least), and then sort those by the number of negative news articles you can find about them (which should exist, given that they haven't laundered their brand-identity much)?
It's the same thing you do to figure out who to order from on AliExpress: look at who's put themselves out there the longest while doing active business, without accruing negative ratings in the process.
Or, as well, it's the same thing you do when deciding whether it's worth it to try out a new restaurant in your neighbourhood: you give it a few months, and if it's still around, then it's probably good.
> Virtually all "reputation" that VPN providers have originates from paid product placements
I can think of a few prominent counter-examples, those being sold by security vendors. I run Freedome because I trust the people behind F-Secure to be doing approximately the right thing.
Most people use VPNs to get out region restrictions.
These are getting more and more common due to local governments making laws that affect the whole internet - think GDPR - that individual site owners do not want to abide by so they block IPs. VPNs solve this very real problem for those still wanting access to the content.
They're also used for subverting content region licensing. For example, with Netflix.
Come on. My point being - VPN isn't the limiting factor here. It's the people you're downloading from. If you can't see the connection I can't help you.
Also, it's a terribly constructed article, genuinely terrible. Completely wrongly assumes a specific threat model that isn't accurate for the target audience.
Sure, you're always trusting a VPN at their word that they don't log, the above gives a detailed analysis of which ones you probably shouldn't trust. You can always host your own: https://github.com/n1trux/awesome-sysadmin#vpn
You can also VPN chain (l2iptables), tunnel over TLS, etc. That gist post is pretty dumb imo
How many non-technical people read things on github? I'm seriously wondering, because whenever I see a link to something posted on github I always assume that it's intended for an audience with some technical understanding. I know that some laws and what not have put up onto github to provide easier access, but it never seemed like that non-technical people started using it.
I think if someone shared it to their facebook, a non-technical user wouldn't be much less likely to read it than say a medium article. Non-technical users don't really care about the domain.
Certainly most readers of github are technical, but that doesn't necessarily make it less suitable for non-technical people.
This post makes good arguments, but there's a very real reason to use a VPN provider over your own server - plausible deniability. With a VPN your traffic is mixed in with many, many other users', whereas with your own server, any traffic coming from that IP can safely be presumed to be yours.
When the vpn company is subpoenaed because someone saw suspicious traffic coming out of their servers, regardless of the number of people, the logs and connections would point directly to you.
I'm no expert on Tor but when I researched it years ago, it seemed like your privacy on tor was only as safe as the exit node you happen to go through. If you're in North Korea trying to get out and happen to go through an exit node run by the NK government, they could theoretically decrypt your traffic in some cases. If all the nodes you're going through are theirs, then they know exactly who you are even if they can't inspect the traffic.
Edit: I must stress I'm not an expert, and would love to hear if the above is wrong.
This is more or less true. The vulnerability of Tor is certainly the exit point.
Incredibly difficult to pinpoint you as the responsible party - but that information could certainly be outputting virtually anywhere, depending on the exit node.
No, that's not entirely true. No single node in a Tor circuit knows both who the user is and what site they are going to. In order to compromise a user's anonymity, you need to do a traffic correlation attack (where you look at packets going through both the guard node and the exit node and match up the timing of packets). There are some protections against this attack in Tor (guard nodes are not changed often by clients, relays need to be running for a long time in order to be permitted to be guards, and there is some randomised traffic sent to the guard by the client) but it is definitely not a solved problem.
But of course, if you aren't using TLS then your traffic is not encrypted as it leaves the pipe. So obviously you should use TLS over Tor.
thats not true, its well documented how various bittorrent clients can work through tor. the main drawback is that its slower than a direct connection, but that does not mean it doesn't work...
Well like others have said before, the company most likely wont go down in flames in order to protect you. Not all, but I assume the major providers will roll over.
The better VPN providers will be set up in a way that makes it difficult to touch them in the first place, e.g. they operate from a jurisdiction that sets a high bar for forcing a company to provide customer information.
I would never expect a company that did log to refuse to give those logs to a court. That would be corporate suicide and executives would end up in actual prisons. I also wouldn't expect a VPN provider to refuse a court ordered warrant to begin logging your particular traffic or something like that. So if a company has appeared in court and failed to produce any logs and the court has accepted that information as not existing, it's hard to get stronger verification than that. And that has occurred with at least a few VPN providers (while a few have provided logs to the courts, proving they log).
If the choice is between my ISP logging all of my traffic for whatever purposes they choose, commercial or otherwise, or adding the hurdle of someone getting a court order to get logs of my traffic, I'll take the added hurdle every time. I'm not worried about my traffic being "suspicious" - I'm not doing anything suspicious. You also aren't limited to using a single VPN. If you value your privacy spreading your browsing habits around to a variety of VPNs can only help you - there's no downside when the alternative is "trusting" your ISP.
>Because a VPN in this sense is just a glorified proxy. The VPN provider can see all your traffic, and do with it what they want - including logging.
This is a tautology. If you use it as a proxy, then its a proxy. VPNs arent for this, and so are bad at it.
VPN use case is either to securely leave a network (hotel Wi-Fi, airport wifi) or to securely get to a network (home resources, corporate resources). If you want a proxy, find a proxy.
I think the crux is you consider "VPN use case is either to securely leave a network (hotel Wi-Fi, airport wifi)" a core VPN use case when the author considers that a proxy use case.
I side with the author on this one, a virtual private network is meant to mean multiple private devices on a single network segment virtualized over some transport. Using it as the place you connect to to shove your internet traffic through a relay definitely fits the secure proxy use case/definition way better.
Can't easily configure a proxy for a mobile (ATT, VZ, et al) network connection (on iOS, at least), VPNs are easy-peasy to connect, so I use a personal, private VPN as proxy -- it obscures my traffic, blocks ads and malware...and I wouldn't say it was "bad at it" at all...
Well, you now control the endpoint and have a lower probability of your traffic being snooped, as major VPN's have a concentrated stream of "interesting" traffic while random VPS's don't.
Simply layers obscurity, it would be harder to subpoena multiple companies than a single vpn service. (Plus you "own" the vps and can quickly delete or create new services whenever) Before you browse, create a new vpn box, browse..., then delete the box after use. What logs, what box?
Well if you are really after anonymity, you have to also keep in mind your isp and browser fingerprinting and the million other things that can expose you online. :)
Is it guaranteed that your host doesn’t keep connection logs? They’re the endpoint. They see everything going to you and every site you go to regardless of VPN.
Correct, the endpoints are the weakness. My point was about being more difficult to find and not bringing attention by paying for a vpn service, a vps could be anything.
The opinions expressed in the article aren't new to me, but I thought the fact that I saw them on the front page of HN implied that they were becoming increasingly popular or there was some new development (eg. confirmation of certain VPN providers being honeypots). If I had realised this was just a link to a discussion that happened a few years ago and had no real impact on the general consensus among IT experts, I wouldn't have clicked on it.
I use a VPN because I want a proxy, and for e.g iOS it seems a VPN is the easiest way to set up a proxy.
The article lists several reasons to use VPNs but isn’t the biggest one these days simply to circumvent geographical content limitations for online services such as video streaming? Nearly everyone I know has used a VPN service at some point, and if you asked any of the non-technical ones what it is they might say ”a think that lets me watch the game broadcast when I’m in another country”.
People want proxies and the VPN providers provide VPNs that work like proxies. I can’t really see the downside to using the VPN as a proxy?
The primary reason people use VPN services, which articles like this always fail to address, is best illustrated at this URL: https://iknowwhatyoudownload.com/
It's very limited but tends to show normies some popular movies (and, crucially, embarassing pornography) they've torrented, which makes the overall point
Okay, so I just checked this out, and there is a non-zero amount of child porn on the list. Is my roommate downloading CP? Is there any other explantion?
Your IP is assigned on rotation by your upstream ISP, your router doesn't get to pick when the address changes unless you contact them and ask to have it changed.
My ISP assigns me the same IP address for months at a time before changing it seemingly at random. Without knowing how long you’ve had that IP address and how long the linked site keeps data for, it’s not really meaningful information.
keep an eye on that list, the last seen column should tell you if this is current of ancient activity, if he/she is seeding, correlating this with times your roommate is home (or his/hers pc on) should give you a good idea of whether this is him/her or someone else sharing your IP. Another such file coming up on that list is a strong indicator as well, and could help you even if he/she is no longer seeding. Keep in mind that remote control of a torrent client is possible. If you control the router you could try getting a new IP. All this without downloading the actual file
Thanks for the advice I'll keep an eye on it. As far as I'm aware he's home basically 100% of the time so that unfortunately doesn't help narrow anything down lol
The title is misleading because the article focuses on using VPN providers to obfuscate traffic when this is one use case of VPN technologies. The gestalt types of VPN usage are:
* Remote Access VPN: Connect to resources on your corporate network. An example of this is you're in a coffee shop on holiday and need to access a corporate resource.
* Site-to-Site VPN: Connect networks on two sites together. An example of this is you're in a branch office and need to connect to a resource in HQ.
Note that VPN providers give you a limited Remote Access VPN to their network, which they control. They can do whatever they want to your now-decrypted traffic before they send it out to the internet. If you want to obfuscate your traffic, Tor is a better candidate.
Quote:
> Note: The content in this post does not apply to using VPN for their intended purpose; that is, as a virtual private (internal) network. It only applies to using it as a glorified proxy, which is what every third-party "VPN provider" does.
"Service" here refers to a service in the "company" sense, not in the "system daemon" sense. Legitimate VPNs are typically run on one's own network, not outsourced to a third-party service.
The original title ("Don't use VPN services") is appropriate. The article talks about more than just anonymity - it also explains why you shouldn't use VPN services for greater privacy or security.
The article does say it's OK to use VPNs for accessing internal networks, but that wouldn't be a VPN "service".
Am I better off having my decrypted traffic in a VPN provider's network or in Comcast's network, given the amount of trust that I have for Comcast is not very impressive?
The title should be renamed to "Don't Use 3rd Party VPN Services".[1]
On-prem VPN deployments with solutions like AlgoVPN[2] from TrailOfBits is still very useful. Let alone mass majority of the the corporate IT's internal VPNs that is required for some workforces to perform their jobs remotely on public Internet.
I’ve seen a complete lack of arguments for why anybody should use Algo or Streisand. I don’t see the point. If you don’t trust VPN's, why trust literally anybody you choose to host a VPN, especially if there is arguably even less anonymity to be had.
That's the exactly the misnomer that the title didn't do justice. Of course you MUST trust VPN in order to make sense of using it. The differentiation is whether that VPN is some 3rd party manage it or you manage it on your own. With 3rd Party VPNs you have no idea how they setup it and no transparency how they secure the VPN node. If you manage your VPN node on your own, you have full control what algorithms and configuration you are using and you pick the right node in an "secure" environment, all are risks factored into the big picture.
> If you manage your VPN node on your own, you have full control what algorithms and configuration you are using and you pick the right node in an "secure" environment, all are risks factored into the big picture.
No, it's the exact same situation. Or do you happen to know exactly how whatever hosting provider manages the server you're using? They can be trusted exactly as much as VPN providers. There is no real security once you're using systems that you don't own, but there are benefits to using a VPN that can't be realized if your name is on the box.
> No, it's the exact same situation. Or do you happen to know exactly how whatever hosting provider manages the server you're using?
It's not exactly the same. In the case of cloud providers, you know what you are getting into and mostly having the freedom to setup your own VPC, your VM image, your firewall, even secure boot/TPM stuff, etc.
As far as the data security goes, many Cloud vendor provide data encryption at rest with your own keys (Of course data security in transit for a VPN, that goes without saying). This is even MORE true for Corporate ITs since they own and operate their own data centers and hardwares too (even with popular trend cloud computing migration).
Just think about it, if public cloud vendors can get government contracts (DoD/CIA/NSA), then they can ensure security at a high bar. But keep in mind that security is NEVER an absolute term, so your argument to me are moot.
I use a third party VPN service to get around the fact that my residence comes with broadband that hijacks all DNS and routes all HTTP (port 80) connections through a Squid...
I also feel sharing an IP with many other users adds to the level of anonymity.
> I use a third party VPN service to get around the fact that my residence comes with broadband that hijacks all DNS and routes all HTTP (port 80) connections through a Squid...
You could set up a local resolver to NXDOMAIN specific IP address replies. Dnsmasq has an option for this. Regarding Squid, what makes you sure your VPN services doesn't do the same?
> I also feel sharing an IP with many other users adds to the level of anonymity.
Can you explain how you feel this adds anonymity? There is still potentially a record of you using that shared IP at a certain time to do a certain thing, so what is your threat model in which the VPN helps anonymity?
> And remember that it is in a VPN provider's best interest to log their users - it lets them deflect blame to the customer, if they ever were to get into legal trouble.
Hmmm? If you don't have record of it, the courts don't do much, at least in the US. If they subpoena you, and you don't have logs, nothing ever comes out of it. Outside of fines and things of that nature.
> The $10/month that you're paying for your VPN service doesn't even pay for the lawyer's coffee, so expect them to hand you over.
How do you think insurance works, or why airlines habitually overbook?
A trivial word problem if you will:
If you had 10,000 users, you were subpoena'd and only 100 users did anything worth prosecution, that's what. For one lawyer, drinking a $10 coffee (or two $5 dollar) every week day for a month. that's 20 days, $200 a month. $2,400 annually. Assuming in this example only 1% of your users need defending, that's 99% of your coffee budget you don't have to worry about! For 10,000 users, a yearly subscription pulls in about $1,200,000 (we aren't doing any adjustment for taxes and all that garbage). If 99% of your users are behaving themselves.. or at least not doing something bad enough for the courts to take notice (which in the digital age, things like piracy are white noise) that means you still have $1,188,000 to help you in those, typically blanket cases (i.e. a court case in which 20 of your users were downloading illegal movies, and MGM got really upset). Since if you aren't logging, these infractions are dealt with in aggregate usually, since it can't be quantified. So number of lawsuits < bad users.
That's not bad, if all your lawyers needed was coffee monthly, then you could support, with 99% of your users cash, 495 lawyers coffee for a year! more than enough coffee to defend your business. Don't forget you can still use the "blood money" you got to buy them coffee!
The basic principle behind my oversimplified, and somewhat tongue-in-cheek example was to remind you that insurance is a lucrative business. I wonder how they survive if your monthly cost for liability (up to $500,000) isn't $500,000 per month!?!
While it's true that your VPN provider _may_ be lying about their "no logging" policy, at a minimum, you get additional layers of protection. Your source IP is masked. A subpoena would be required to reveal your source IP, and perhaps your VPN provider is telling the truth about not keeping logs. If your VPN endpoint is in a different country than your network endpoint, then the legal obstacles get even higher.
Surely you shouldn't depend on that alone. Tor would be a wise additional layer of protection, if applicable. But to suggest that you get no privacy benefit at all from a VPN is like saying your host may be compromised, so you might as well use regular telnet rather than SSH.
This. If we always assume the worst, we may as well stop using passwords or strong ones anyway, because we can assume that our machines per definition are hacked and local network infiltrated.
Not happening, right? That’s what i thought...
Yeah, I hate extreme opinions that say not to do something just because it's not 100% effective. It's like saying don't bother using a lock because all locks can be picked and cut anyway.
I consulted to an organisation that spent multiple years refusing to allow any form of MFA.
Everyone agreed it was extremely important and some password protected data was very sensitive. But the conversation about authenticator apps always got bogged down with risks about malware on phones. I would get asked "will you stake your career on it never happening?" Of course not. Therefore "for security reasons" we never supported authenticator apps. Of course it was pointed out that people might lose hardware tokens, so they didn't happen either. Because mobile MFA isn't perfect, I had directives to stick with easily phished passwords for years.
> I would get asked "will you stake your career on it never happening?" Of course not.
"Let's make a bet over whether a customer reports an authenticator app gets hacked before a customer's account without an authenticator is broken into. If the authenticator app is hacked first, I'll resign. If an account with no 2FA is compromised, you resign."
This is probably just meant to be a joke, but I have been in that situation before and I don't think offering to gamble away your job would be an effective way to convince others to accept your advice on risk management. I still don't know how to effectively convince others to take on new risks in order to avoid bigger risks presented by the status quo. Given the additional risk that my risk assessment is deficient, doing nothing is usually the easier decision.
I still don't know how to effectively convince others to take on new risks in order to avoid bigger risks presented by the status quo.
I think you just need to be talking to someone who can understand the risks you convey, has the responsibility for both risks and the authority to effect the necessary change.
IME that's straightforward in most small companies and in large government departments it's rarely one person but multiple committees of people who you'd never be able to explain the risks to and who won't make a decision.
It's meant to be talking trash online, so you're right to take it with a grain of salt.
But I'll stand behind the view that when ideas are being shot down with challenges like "would you stake your career on this" then a bull-headed approach is worth a try.
> I don't think offering to gamble away your job would be an effective way to convince others to accept your advice on risk management.
It won't persuade technically minded people, but it tells decision makers that you're confident, and offers them a measure of accountability.
> I would get asked "will you stake your career on it never happening?"
Was anyone being asked to stake their career on all the existing security practices? I've worked on a couple of projects with politics similar to what you described, yet they had encrypted (unsalted, decryptable) passwords in a database, and only about 3 tech people seemed to understand the implications of that.
That's implying there are consequences for dire mistakes, which I don't think has been demonstrated so far. In fact, I'd almost say there are barely any consequences at all.
And, to be clear, using them for sessions is not one of those intended use cases, as joepie91 is arguing in that article. Using an actual server-side solution is easier and safer.
Nowadays not much, but it used to be overrated and had serious reliability problems.
Your startup probably doesn't need Big Data (TM). Just use a relational database like Postgres and learn a bit of SQL. IIRC, Postgres outperformed Mongo at JSON processing, which was supposed to be one of the stronger points of MongoDB.
Mongo is the wrong choice for a solid 75% of the places it's used. In the vast majority of cases, it was brought in to replace a relational db because developers though it would be faster to not have a schema / constraints / relationships, etc. It usually lets you develop faster, at the cost of blowing up in your face a few months/years down the line, when you have to rebuild your app to use a real database because your devs remembered why relational dbs are useful in the first place.
Mongo is a document store, not a relational db. Mongo is a good choice if you're looking to replace ElasticSearch, not if you're looking to replace MySQL.
That is exactly why I don't use a lock on my house. Obviously, I can't keep any stuff in my house - my belongings are strategically buried around the tri-state area, it takes me about three hours to dig up my clothes ever morning - but the peace of mind is definitely worth it.
Sure, I went on holiday to Jacksonville - thought I would take in some culture - and the copper was stripped out of my house. But they can only rob you once ;) I go number two in a field a few miles out of town now...total peace of mind.
If you were running a VPN service would you rather: a. Pay for legal counsel and fight court orders for someone paying $10/mo or b. Just give up all info?
For someone paying $10/mo? No. For the trust of my thousands of customers paying $10/mo and to keep my public reputation afloat? Hell yes. A VPN service that hands over customer information constantly will very quickly go out of business.
Your reasoning assumes that a VPN couldn't hurt, but it can. If someone wants to track you and you don't have a VPN, they need to compromise your ISP. If you do have a VPN, they need to compromise your ISP or your VPN.
Part of the point of a third-party VPN is that the ISP/router can't tell what you're doing -- you assume that they're untrustworthy. Compromising the ISP would be useless, unless your VPN is for some reason sharing the same info with your router, in which case... install a competent VPN client.
I don't see how you're adding an additional failure point, you're just moving the same failure point somewhere else.
Yes, once the VPN endpoint makes the request, an ISP can still intercept it. But this is one of the few cases where adding an additional network hop very likely does not matter at all for your privacy. Once your request is going over the open Internet there are already so many opportunities for people to spy on it. The benefit is in disassociating that request from you, not in hiding it once it goes public.
The confidentiality protection is not really absolute - the encrypted VPN traffic is susceptible to traffic analysis[1]. For example, your traffic pattern fingerprint could be correlated and matched to your online identity if your ISP and an ad network or another globally positioned middleman actor colluded on it.
Why do you think it would be unworkable for a corrupt ad network in cahoots with your corrupt ISP to correlate your web requests based on time, length and previously seen traffic from the VPN IP?
I agree that the business case is not that obvious but converting a "can't be done" argument to a "not interesting enough" is already pretty significant. The amortized cost per user would be very low after all, assuming this was used for automated mass surveillance.
> [...] The amortized cost per user would be very low after all, assuming this was used for automated mass surveillance.
Honestly I think this is the total opposite case. "Full take" collection systems are notoriously money pits due to the nature (hence, full take). Targeted surveillance will ALWAYS be far more cost efficient than blanket mass surveillance.
This is much different from full take, as there is a well defined equation to be solved. There would be no need to store the traffic contents, just size+ timestamp + addrs, info that will compress very well.
No, they need to compromise your ISP and your VPN -- that's the whole value. With a VPN, your ISP doesn't see your traffic anymore, they just see you connecting to your VPN provider. Meanwhile your VPN provider can see the site you're connecting to, but they can't tell who you are, just "someone is ISP X's IP range".
> A subpoena would be required to reveal your source IP, and perhaps your VPN provider is telling the truth about not keeping logs.
I doubt this is necessarily true in the US due to the 3rd party doctrine (which I abhor). I think they may refuse and request a subpoena, though. But, nothing stopping a company (generally) from handing over your data if asked for. Maybe T.O.S?
The article makes a strong case. And no, it isn't "wrong as it is". This whole VPN business sounds like a big scam everyone keeps promoting to everyone.
It's not. I know of several instances where IP is at least used as a filter. Esp. the combination of user agent and IP require no JS and can help you to track users across domains easily for small to medium sized websites.
Yes, exactly! I use VPN exclusively for downloading movie torrents so I don't get nasty letters from my ISP. I have a friend who has gotten several such letters.
>A subpoena would be required to reveal your source IP, and perhaps your VPN provider is telling the truth about not keeping logs.
Not to mention the legal trouble for an LEO to be granted a subponea in a different country. By the obstacle of "a different legal system protects this part of my data chain" alone a VPN is worth it.
Say you use a Russian VPN provider. Sure, they can see that you're connecting to whatever site, but the actual data is protected end-to-end by TLS (hopefully). Meanwhile your local ISP can see you're connecting to something in Russia, full stop. For someone to track you down, they'd have to get the compliance of both your ISP and your Russian friends... AFAIK, there are exactly zero cases on record where this has been successfully done.
I mention this every time this comes up but it's info worth spreading... "sshuttle", make any server into a VPN without VPN server-side software, this takes the pain out of doing your own VPN, gives you far more obscurity, lots of flexibility and in my experience it also performs much better - which I believe is due to the TCP deconstruct-reconstruct vs traditional VPN which does TCP over TCP. The only disadvantage is it's only for TCP (no UDP or multicast).
For routing all your internet it's as simple as this (on the client only, no server setup):
sshuttle -r user@1.2.3.4 0/0
That's it... server requirements are met by almost anything, you don't need root access, but it does need python, which most distros have by default. Now you can use your own little obscure server, yes it's not invulnerable a VPS provider can still look at you if they wish, but it's far less of a target than a purpose built consumer VPN provider.
It's also far more powerful for slicing up and mixing subnets or only routing specific targets ... for example unblock a specific site, but don't re-route other traffic:
sshuttle -r user@1.2.3.4 sci-hub.tw
[edit]
Minor issue worth mentioning, not to disappoint people trying this out - it's currently necessary to use the -x option to exclude the server itself from being routed on Linux, I think this is due to a kernel bug? which is a little annoying, hoping this will go away eventually. This is not relevant to BSD or Mac, although on Mac you have other kernel bugs to worry about in XNUs network stack.
sshuttle -r user@1.2.3.4 -x 1.2.3.4 0/0
[edit]
As "icelancer" has pointed out bellow, please note that using your own server ties your activity to your identity more definitively if you are the only one using the server and you pay for the server in your name. Not being a purpose built consumer VPN makes it a less likely target through significant obscurity, however in the event it IS targeted, it's uniqueness will make it easier to associate activity with you via the VPS provider.
> This also ties your identity to a provider definitively. That's fine, as long as you tell people that's what is happening. A good consumer VPN that isn't a garbage one offers plausible deniability.
Yes you must have a login... but setting up a VPS is literally a button click these days, it's not going to be much more complicated. no need to even login to an interactive shell to configure anything (or at the most `adduser` if there are no default non roots), all you need is a user name and password, any of the generic VPS images will work no configuration beyond an ssh user.
It's almost as simple, faster, and importantly, far more obscure... vs consumer VPNs which are almost honey pots.
It's also more powerful, you can selectively route things through different servers simultaneously.
This also ties your identity to a provider definitively. That's fine, as long as you tell people that's what is happening. A good consumer VPN that isn't a garbage one offers plausible deniability.
Yes this is true, it really depends what you want from your VPN. For security and anti-cencorship this works, among many other useful things that you can't do with a normal VPN - but if you are evading authorities or something then you cannot be personally associated with the server.
I suppose that negates my point about it's obscurity, since you only care about that if you are evading prying eyes of some sort.
I've updated my original comment to include your point.
If you want to have any hope of anonymity when accessing the internet, use Tor. Don't use a single-hop proxy. Even if you assume that the VPN provider is trustworthy and won't roll over when they're handed an NSL (a questionable assumption), intelligence agencies can just as easily break into all the servers (owned by a single party) and log the traffic themselves. Personally, I would be surprised if they haven't already done this for some providers -- why wouldn't they?
These days WireGuard is just as easy to set up, and has lots of benefits over sshuttle (it's UDP based, supports roaming a-la Mosh, has a much more solid cryptographic design, and so on).
"Generate a private and public key pair for the WireGuard server:"
"umask 077
wg genkey | tee privatekey | wg pubkey > publickey"
"This will save both the private and public keys to your home directory; they can be viewed with cat privatekey and cat publickey respectively."
"Create the file /etc/wireguard/wg0.conf and add the contents indicated below. You’ll need to enter your server’s private key in the PrivateKey field, and its IP addresses in the Address field."
That's not within reach of your average computer user.
I don't think anyone is under the delusion that non-technical users are going to use sshuttle, but not everyone has the will to invest the time and effort doing server side configuration of a VPN client for their personal use. sshuttle makes it simple for anyone who is the least bit familiar with ssh and has some kind of server access or is happy to spin up a VPS quickly, nothing more is necessary.
There are plenty of scripts online that make it incredibly trivial to set up WireGuard (here's mine[1]). This isn't like configuring OpenVPN -- it actually only takes a minute or two to set up.
Given that WireGuard is headed for inclusion into Linux mainline soon, it probably would be a good idea for folks to take a few minutes to learn how to use a technology that is going to be part of core Linux.
Not fair, OpenVPN doesn't take that much more than a "minute or two" to set up and configure. ;) Last time I launched it[1], I could launch and connect to a new OpenVPN instance in less than six minutes, from my iPhone. Desktop is even faster.
Well yes, but OpenVPN has many dozens of different options and my experience with it is that it's a pain in the ass to get the right set of options (on both the client and server) which result in minimal latency and maximum throughput.
But you're quite right that if you already have a config that you know works, WireGuard has no significant advantage in this area (in terms of ease-of-configuration -- though the keys being quite short is nice for SSH-like key distribution). But if you're starting from scratch then you need to first figure out what is the right configuration to use (or you need to pick from the many dozens of "set up OpenVPN quickly" scripts) and then you need to hope that your configuration is not insecure.
WireGuard can be set up and work just as well as any other configuration without a script in a couple of minutes (or less than a minute with a script). The script that was linked in a sister comment to "set up OpenVPN quickly" also sets up Apache for god's sake...
It is just as easy as sshuttle to set up. I never said it was easy for an average computer user. Average computer users will probably buy some service which uses WireGuard under the hood.
Today it's solid. And tomorrow? The story for fixing it if it breaks is a flag day - works fine when you have ten users, not so much when it's ten million.
The "agility is bad" crew have a decade or two to wait before they can show anything at all meaningful beyond "my new thing is newer than your old thing".
That doesn't make them wrong, but it makes their position unproven in practice.
There is plenty of evidence that cipher agility weakens cryptographic protocols.
By having cipher agility, both clients and servers are incentivised to support the widest possible set of ciphers (because nobody can agree on what cipher to use). This means that it's hard for a known-bad cipher to stop being used (see: the entire history of RC4 usage in TLS) and any downgrade attacks become catastrophic (see: the entire history of SSL/TLS). It also ends up adding complexity to the protocol -- which is always a good thing to have in cryptographic protocols (see again: SSL/TLS)!
Most importantly, if all currently-known ciphers are broken tomorrow, then all servers and clients will have to be upgraded in order to be secure. So cipher agility doesn't help you with the doomsday scenario (everyone needs to upgrade anyway) instead it just ensures that older (completely insecure) clients will still be able to communicate with servers. Why is that seen as a feature? If you really want an insecure fallback mechanism you can implement it with non-agile systems by supporting the two most recent versions of the protocol (I expect this is what WireGuard will do once it's upstreamed). But not everyone wants the "feature" that some clients will silently become insecure.
I don't understand what you're saying with this point:
> The "agility is bad" crew have a decade or two to wait before they can show anything at all meaningful beyond "my new thing is newer than your old thing".
How can the "agility is bad crew" prove their point in a few decades if you're arguing that we shouldn't use such protocols? If they followed your advice, there wouldn't be any zero-agility protocols to compare against in a few decades...
Your last point first: Am I arguing that "we shouldn't use such [explicitly never agile] protocols"? I don't see that.
I'm arguing that the case for them is weaker than is often put, but that's not the same as nobody should use them. If a flag day is fine for your use case there's very little reason not to choose this design approach, it is simpler and simpler is good. But you'll notice that the example cited (including by you) for why agility is bad is almost invariably TLS and clearly a flag day isn't practical for TLS because it's far too broadly used.
TLS illustrates my other main thrust of concern on "agility is bad". You describe RC4 as "known bad" and the downgrade attacks as "catastrophic" and this sort of apocalyptic thinking is very popular in the "agility is bad" crowd, but it doesn't truly reflect the ground reality for actual users which is that things went from "It's definitely fine" to "It's probably fine but to be sure we should upgrade". Grey areas are a real thing.
There were protocols that didn't exhibit any cipher agility before by the way. Lots of them. What happened was that they broke, and so agility was added to them retrospectively in new versions that fixed the brokenness. The arguably new thing in the latest round of "no agility" protocols is a supposed determination never to do this. To see how that works out, as I said, you'll have to wait a decade or two.
I'm not talking about the selection of ciphers (though WireGuard doesn't have cipher negotiation because it has shown to be a universally bad idea because of downgrade attacks -- instead it uses versions and requires strict upgrades to operate).
Among many other things, you cannot do a port scan for WireGuard servers. You can do a port scan for SSH. This is because the WireGuard handshake was designed such that there is no response to unauthenticated packets (the first packet is authenticated by the client knowing the server's public key -- something port scanners won't know).
Jason Donenfeld has a few talks[1] that explain why the cryptographic design is the way it is, and it has several very clear improvements over SSH (as a VPN protocol).
There is still a difference. Even if you use SSH for some things (which you could only expose through WireGuard instead of making it internet-accessible), WireGuard protects your VPN traffic in ways that SSH does not. WireGuard renegotiates the session key every 5 minutes (SSHv2 uses one ephemeral key for the entire session), it has identity hiding (you can't tell at any point the public keys of the server or client), it has pre-shared key support to limit post-quantum or ECDH attacks, and so on.
I really can't overstate how awesome WireGuard is. I really would suggest you take a look at it.
How does this work for walled-garden mobile devices (ie, iOS)?
There's a reason VPN providers have exploded in popularity: mobile internet devices have been mainstream for 5-10 years and they are system-locked but you can install apps.
It doesn't. Instead, you install WireGuard for iOS for free and take a photo of the QR code supplied by your sysadmin, which just encodes a simple text configuration file with an ed25519 key. Then your sysadmin can route all your iOS traffic however they want, whether you are connected to the public internet by cellular or wifi.
Can you elaborate? i've found the opposite to be true, but then I am usually restricted by crappy ADSL bandwidth of 6mbit or less so i could be more sensitive to different aspects of "slow".
Note that sshuttle deconstructs the TCP packets before sending them over SSH which already uses TCP, it also performs differently to `ssh -D` and manages the buffer to prevent blocking behaviour over bandwidth limited connections:
--no-latency-control
Sacrifice latency to improve bandwidth benchmarks. ssh uses re‐
ally big socket buffers, which can overload the connection if
you start doing large file transfers, thus making all your other
sessions inside the same tunnel go slowly. Normally, sshuttle
tries to avoid this problem using a “fullness check” that allows
only a certain amount of outstanding data to be buffered at a
time. But on high-bandwidth links, this can leave a lot of your
bandwidth underutilized. It also makes sshuttle seem slow in
bandwidth benchmarks (benchmarks rarely test ping latency, which
is what sshuttle is trying to control). This option disables
the latency control feature, maximizing bandwidth usage. Use at
your own risk.
There is a --daemon option but do not know if it includes this behavior, maybe give it a go. I prefer to keep it in the foreground so I can kill it easily.
If you are using ssh keys you can at least use a bash while loop without incurring any password prompts:
while ! sshuttle -r user@1.2.3.4 0/0; do sleep; done
Reposting the last response I gave when this article came up.
----
> Your IP address is a largely irrelevant metric in modern tracking systems.
I don't believe this for one second.
Your IP address on its own is not sufficient to identify you. That doesn't mean your IP address is not helpful in identifying you.
If you have Javascript disabled, it is a heck of a lot easier to identify you with a combination of an IP address, user agent, and OS than it is to identify you without the IP address cutting down the pool of potential visitors.
On top of that, if you're targeting me and do a geo-location of my IP address, it will get you within 5 miles of my house. That's close enough that you'll know which county I'm in, which with a few other easily-obtained pieces of information will let you pull up my voter registration, which will give you my exact street address.
Of course, you could mitigate this by setting up your own VPN on something like Linode, but unless you're regularly rotating IP addresses, you've just traded a pseudo-identifier that multiple people/devices share for a persistent identifier.
This argument comes up all the time, and I have never heard anyone explain it in a way that passes my sniff test. If you want me to stop using a VPN, you need to do a lot better than just claiming that IP addresses don't matter -- you need to show some kind of evidence to back that up.
----
Broadcasting your IP address to every website you've ever visited is a completely valid concern that gets hand-waved out the wazoo whenever this subject comes up.
I've sent bug reports to sites that publicly tied IP addresses to comments/accounts so anyone could track your movement patterns over time. Yes, that info can be useful to an attacker trying to deanonomyze you. Yes, that info can be used to link users together. Yes, that info can be used to narrow the pool of potential visitors so other fingerprinting techniques are more powerful.
It is blanketly ridiculous to claim that an approximate county-level geolocation isn't a useful data-point to attackers. If IP addresses weren't useful, the Tor project wouldn't be going to such lengths to hide them.
> Of course, you could mitigate this by setting up your own VPN on something like Linode, but unless you're regularly rotating IP addresses, you've just traded a pseudo-identifier that multiple people/devices share for a persistent identifier.
This actually happened to me. I'm using a persistent VPN (50% to access my private infrastructure and 50% because I have a hostile ISP).
I mostly don't use any Google services (maybe one google search a month and the occasional google map search but I avoid when I can) and I was very surprised when once I did a google search and saw my postal code at the end of the page. The IP address was for a VPS (in the same city but with a different post code). I found it unusual but didn't pay too much attention. A few months later I moved places (different post code) and after a while google had my new post code at the end of their search page. That's when I found it troubling and assumed that a family member's iPhone was using Google Maps and based on the 'directions' usage they figured out that that IP address has a home address for those GPS coordinates.
(The iPhone in question is reasonably 'hardened' with background updates off and location services only 'when app opened' and disabled for most system services).
That was the only plausible correlation between IP address and location google could have done automatically - neither I nor the said family member no longer login to old google accounts we had many years back.
That's when I started rotating IP daily (which is trivial in my case as I use lightsail, I issue a shutdown from a different server and then a power on, AWS rotates the IP automatically out of a very large pool - so far I haven't gotten the same IP twice).
The only problem I have with lightsail is that I often get a 'dirty' IP so I rotate 4-5 times before getting a good one (I test this by going a curl on a website that sends google captcha on dirty IPs but lets the 'good' ones straight in).
one thing that was not mentioned- your ISP logging your data. Too much of my data in my ISP's hands is not a good thing. I'd rather tunnel out through a "trusted" 3rd party server then give all my data traffic to Comcast or whatever.
266 comments
[ 4.6 ms ] story [ 346 ms ] threadOne of these markets involves competing on security and privacy. One of them involves colluding on influencing FCC policy.
So even if a particular VPN provider is inept or corrupt, my expected return on the investment is higher than trusting TWC.
one of the points raised in the article is that it's difficult to evaluate whether the VPN actually follows its logging policy. if they say they don't log, you pretty much have to take their word for it until information to the contrary somehow goes public. it's entirely possible that LE could be using a VPN as a honeypot and forcing everyone they catch to stay quiet through a plea deal. you'd never know until someone broke ranks. the VPN company could just as easily log your traffic and sell your usage data. unless they're sloppy about it, how would you find out?
Figure it out.
That is an extremely US-centric view.
Aside from that, physical ISPs have something to lose, as they have a very real infrastructural investment; whereas becoming a "VPN provider" literally does not entail more than "rent a few servers, run OpenVPN, buy a billing system license, hire a marketing guy".
It's entirely viable for a VPN provider to just disappear overnight and set up shop under a different unrelated name at virtually no cost to them, if their old brand gets burned. That significantly changes the trust equation, and not in favour of VPN providers.
Unless they're a (natural or artificial) monopoly, like... pretty much every ISP in North America is. Comcast has the reputation of, well, Comcast, and they're doing just fine.
> Becoming a "VPN provider" literally does not entail more than "rent a few servers, run OpenVPN, buy a billing system license, hire a marketing guy".
Yes, that's a good thing: it means that VPN providers, unlike telcos, are under selection pressure. Which means that for VPN providers, unlike telcos, reputation actually means something; the top VPN provider is striving much harder for your dollar than the top telco is.
Certainly, don't pick a VPN provider at random, but you wouldn't anyway.
Once again, that is an extremely US-centric view.
> Yes, that's a good thing: it means that VPN providers, unlike telcos, are under selection pressure. Which means that for VPN providers, unlike telcos, reputation actually means something; the top VPN provider is striving much harder for your dollar than the top telco is.
Except that isn't how the industry works, at all. Virtually all "reputation" that VPN providers have originates from paid product placements (see: the myriad "VPN reviews" that are chock full of affiliate links, YouTube ads, etc.), and providers are assumed legitimate unless shown otherwise by default.
This means that said "reputation" is 100% reproducible under a new brand without ever having a single long-term customer vouching for you. There's no competition on quality; the competition is on marketing only.
Exactly why the industry has turned out that way and doesn't follow the "competition breeds quality" narrative that people on here love to put forward, is left as an exercise to the reader.
It's a Canada-centric view, for me. :)
But seriously, does anyone care about VPNs outside of North America? Why would you, if your ISPs aren't awful? Do most VPN services even bother to advertise outside of the North American market?
> This means that said "reputation" is 100% reproducible under a new brand without ever having a single long-term customer vouching for you.
Why pay attention to word-of-mouth reputation, when survival under competitive pressure is a much more objective signal of reputation of its own?
If the bad actors need to restart with a new brand every few years, then why not just look for the oldest brands around (who must therefore have done this the least), and then sort those by the number of negative news articles you can find about them (which should exist, given that they haven't laundered their brand-identity much)?
It's the same thing you do to figure out who to order from on AliExpress: look at who's put themselves out there the longest while doing active business, without accruing negative ratings in the process.
Or, as well, it's the same thing you do when deciding whether it's worth it to try out a new restaurant in your neighbourhood: you give it a few months, and if it's still around, then it's probably good.
I can think of a few prominent counter-examples, those being sold by security vendors. I run Freedome because I trust the people behind F-Secure to be doing approximately the right thing.
I'm an Australian citizen living in NYC. If you think Telstra behaves any better than the lot over here you may be in error.
So I guess that makes my view Pacific-centric.
Most people use VPNs to get out region restrictions.
These are getting more and more common due to local governments making laws that affect the whole internet - think GDPR - that individual site owners do not want to abide by so they block IPs. VPNs solve this very real problem for those still wanting access to the content.
They're also used for subverting content region licensing. For example, with Netflix.
But the connection is not very stable to say at least, it sometimes drops to zero (but recovers quickly).
So when should I use a VPN?
3. To watch US Netflix in <insert non-US country>.
Also, it's a terribly constructed article, genuinely terrible. Completely wrongly assumes a specific threat model that isn't accurate for the target audience.
Sure, you're always trusting a VPN at their word that they don't log, the above gives a detailed analysis of which ones you probably shouldn't trust. You can always host your own: https://github.com/n1trux/awesome-sysadmin#vpn
You can also VPN chain (l2iptables), tunnel over TLS, etc. That gist post is pretty dumb imo
Certainly most readers of github are technical, but that doesn't necessarily make it less suitable for non-technical people.
Edit: I must stress I'm not an expert, and would love to hear if the above is wrong.
Incredibly difficult to pinpoint you as the responsible party - but that information could certainly be outputting virtually anywhere, depending on the exit node.
But of course, if you aren't using TLS then your traffic is not encrypted as it leaves the pipe. So obviously you should use TLS over Tor.
If you read the original paper the researchers spell out the weaknesses, many of which were made in the name of performance over security.
https://2019.www.torproject.org/docs/faq.html.en#FileSharing
Also, when I said doesn't work, I only meant that it's not an acceptable alternative to VPNs.
This is a tautology. If you use it as a proxy, then its a proxy. VPNs arent for this, and so are bad at it.
VPN use case is either to securely leave a network (hotel Wi-Fi, airport wifi) or to securely get to a network (home resources, corporate resources). If you want a proxy, find a proxy.
I side with the author on this one, a virtual private network is meant to mean multiple private devices on a single network segment virtualized over some transport. Using it as the place you connect to to shove your internet traffic through a relay definitely fits the secure proxy use case/definition way better.
Would there be any benefit in using a number of VPS round robin style? I've got access to a handful...
Not that it matters - fortunately my traffic isn't all that exciting
Which I consider my ISP.. no, I can't just change ISP, I live under five eyes. I don't get a choice.
This article is rediculous. It's just a clickbait title and a whole bunch of ranting saying the exact opposite.
The article lists several reasons to use VPNs but isn’t the biggest one these days simply to circumvent geographical content limitations for online services such as video streaming? Nearly everyone I know has used a VPN service at some point, and if you asked any of the non-technical ones what it is they might say ”a think that lets me watch the game broadcast when I’m in another country”.
People want proxies and the VPN providers provide VPNs that work like proxies. I can’t really see the downside to using the VPN as a proxy?
Home - US, dynamic IP but unchanged in a year: nothing.
Colo - US, static IP for 5 years: 7 things I haven't downloaded and can't find any history of on my disks or backup software.
Seedbox - EU, static IP for 3 years: nothing.
Home probably has <12 downloads, the other two should have thousands from various sources.
[0] https://en.wikipedia.org/wiki/Carrier-grade_NAT
* Remote Access VPN: Connect to resources on your corporate network. An example of this is you're in a coffee shop on holiday and need to access a corporate resource.
* Site-to-Site VPN: Connect networks on two sites together. An example of this is you're in a branch office and need to connect to a resource in HQ.
Note that VPN providers give you a limited Remote Access VPN to their network, which they control. They can do whatever they want to your now-decrypted traffic before they send it out to the internet. If you want to obfuscate your traffic, Tor is a better candidate.
The article does say it's OK to use VPNs for accessing internal networks, but that wouldn't be a VPN "service".
On-prem VPN deployments with solutions like AlgoVPN[2] from TrailOfBits is still very useful. Let alone mass majority of the the corporate IT's internal VPNs that is required for some workforces to perform their jobs remotely on public Internet.
[1]: https://gist.github.com/joepie91/5a9909939e6ce7d09e29#gistco...
[2]: https://github.com/trailofbits/algo
That's the exactly the misnomer that the title didn't do justice. Of course you MUST trust VPN in order to make sense of using it. The differentiation is whether that VPN is some 3rd party manage it or you manage it on your own. With 3rd Party VPNs you have no idea how they setup it and no transparency how they secure the VPN node. If you manage your VPN node on your own, you have full control what algorithms and configuration you are using and you pick the right node in an "secure" environment, all are risks factored into the big picture.
No, it's the exact same situation. Or do you happen to know exactly how whatever hosting provider manages the server you're using? They can be trusted exactly as much as VPN providers. There is no real security once you're using systems that you don't own, but there are benefits to using a VPN that can't be realized if your name is on the box.
It's not exactly the same. In the case of cloud providers, you know what you are getting into and mostly having the freedom to setup your own VPC, your VM image, your firewall, even secure boot/TPM stuff, etc.
As far as the data security goes, many Cloud vendor provide data encryption at rest with your own keys (Of course data security in transit for a VPN, that goes without saying). This is even MORE true for Corporate ITs since they own and operate their own data centers and hardwares too (even with popular trend cloud computing migration).
Just think about it, if public cloud vendors can get government contracts (DoD/CIA/NSA), then they can ensure security at a high bar. But keep in mind that security is NEVER an absolute term, so your argument to me are moot.
I also feel sharing an IP with many other users adds to the level of anonymity.
You could set up a local resolver to NXDOMAIN specific IP address replies. Dnsmasq has an option for this. Regarding Squid, what makes you sure your VPN services doesn't do the same?
> I also feel sharing an IP with many other users adds to the level of anonymity.
Can you explain how you feel this adds anonymity? There is still potentially a record of you using that shared IP at a certain time to do a certain thing, so what is your threat model in which the VPN helps anonymity?
Hmmm? If you don't have record of it, the courts don't do much, at least in the US. If they subpoena you, and you don't have logs, nothing ever comes out of it. Outside of fines and things of that nature.
> The $10/month that you're paying for your VPN service doesn't even pay for the lawyer's coffee, so expect them to hand you over.
How do you think insurance works, or why airlines habitually overbook? A trivial word problem if you will: If you had 10,000 users, you were subpoena'd and only 100 users did anything worth prosecution, that's what. For one lawyer, drinking a $10 coffee (or two $5 dollar) every week day for a month. that's 20 days, $200 a month. $2,400 annually. Assuming in this example only 1% of your users need defending, that's 99% of your coffee budget you don't have to worry about! For 10,000 users, a yearly subscription pulls in about $1,200,000 (we aren't doing any adjustment for taxes and all that garbage). If 99% of your users are behaving themselves.. or at least not doing something bad enough for the courts to take notice (which in the digital age, things like piracy are white noise) that means you still have $1,188,000 to help you in those, typically blanket cases (i.e. a court case in which 20 of your users were downloading illegal movies, and MGM got really upset). Since if you aren't logging, these infractions are dealt with in aggregate usually, since it can't be quantified. So number of lawsuits < bad users.
That's not bad, if all your lawyers needed was coffee monthly, then you could support, with 99% of your users cash, 495 lawyers coffee for a year! more than enough coffee to defend your business. Don't forget you can still use the "blood money" you got to buy them coffee!
The basic principle behind my oversimplified, and somewhat tongue-in-cheek example was to remind you that insurance is a lucrative business. I wonder how they survive if your monthly cost for liability (up to $500,000) isn't $500,000 per month!?!
Surely you shouldn't depend on that alone. Tor would be a wise additional layer of protection, if applicable. But to suggest that you get no privacy benefit at all from a VPN is like saying your host may be compromised, so you might as well use regular telnet rather than SSH.
https://web.archive.org/web/20180504001844/https://8ch.net/b...
Yes, people would rather give their entire packet to a hacker than five eyes, wouldn’t they?
was logging client connections as recent as 2018 despite claiming they do not log https://nordvpn.com/features/strict-no-logs-policy/
see openssl/server.cfg it should contain special lines to disable logging https://www.lowendtalk.com/discussion/107379/how-to-disable-...
Everyone agreed it was extremely important and some password protected data was very sensitive. But the conversation about authenticator apps always got bogged down with risks about malware on phones. I would get asked "will you stake your career on it never happening?" Of course not. Therefore "for security reasons" we never supported authenticator apps. Of course it was pointed out that people might lose hardware tokens, so they didn't happen either. Because mobile MFA isn't perfect, I had directives to stick with easily phished passwords for years.
"Let's make a bet over whether a customer reports an authenticator app gets hacked before a customer's account without an authenticator is broken into. If the authenticator app is hacked first, I'll resign. If an account with no 2FA is compromised, you resign."
I think you just need to be talking to someone who can understand the risks you convey, has the responsibility for both risks and the authority to effect the necessary change.
IME that's straightforward in most small companies and in large government departments it's rarely one person but multiple committees of people who you'd never be able to explain the risks to and who won't make a decision.
Feel my pain?!
But I'll stand behind the view that when ideas are being shot down with challenges like "would you stake your career on this" then a bull-headed approach is worth a try.
> I don't think offering to gamble away your job would be an effective way to convince others to accept your advice on risk management.
It won't persuade technically minded people, but it tells decision makers that you're confident, and offers them a measure of accountability.
Was anyone being asked to stake their career on all the existing security practices? I've worked on a couple of projects with politics similar to what you described, yet they had encrypted (unsalted, decryptable) passwords in a database, and only about 3 tech people seemed to understand the implications of that.
Who was staking their career on that?
Potentially - everyone who worked there, including you. :/
[0] http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...
[1] http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-ne...
For posterity, here's the second part to his crusade: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...
Your startup probably doesn't need Big Data (TM). Just use a relational database like Postgres and learn a bit of SQL. IIRC, Postgres outperformed Mongo at JSON processing, which was supposed to be one of the stronger points of MongoDB.
Mongo is a document store, not a relational db. Mongo is a good choice if you're looking to replace ElasticSearch, not if you're looking to replace MySQL.
Sure, I went on holiday to Jacksonville - thought I would take in some culture - and the copper was stripped out of my house. But they can only rob you once ;) I go number two in a field a few miles out of town now...total peace of mind.
https://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_soluti...
> they need to compromise your ISP or your VPN
Part of the point of a third-party VPN is that the ISP/router can't tell what you're doing -- you assume that they're untrustworthy. Compromising the ISP would be useless, unless your VPN is for some reason sharing the same info with your router, in which case... install a competent VPN client.
I don't see how you're adding an additional failure point, you're just moving the same failure point somewhere else.
Yes, once the VPN endpoint makes the request, an ISP can still intercept it. But this is one of the few cases where adding an additional network hop very likely does not matter at all for your privacy. Once your request is going over the open Internet there are already so many opportunities for people to spy on it. The benefit is in disassociating that request from you, not in hiding it once it goes public.
[1] A term of art in intelligence & cryptanalysis, https://en.wikipedia.org/wiki/Traffic_analysis
Honestly I think this is the total opposite case. "Full take" collection systems are notoriously money pits due to the nature (hence, full take). Targeted surveillance will ALWAYS be far more cost efficient than blanket mass surveillance.
I doubt this is necessarily true in the US due to the 3rd party doctrine (which I abhor). I think they may refuse and request a subpoena, though. But, nothing stopping a company (generally) from handing over your data if asked for. Maybe T.O.S?
The article is just wrong the way it is. It would be correct if it was titled "Don't use VPN Services as your only means to ensure perfect privacy".
The point of the assertion is that you can be tracked even if your IP address is obscured, mangled, or spindled.
Not to mention the legal trouble for an LEO to be granted a subponea in a different country. By the obstacle of "a different legal system protects this part of my data chain" alone a VPN is worth it.
Say you use a Russian VPN provider. Sure, they can see that you're connecting to whatever site, but the actual data is protected end-to-end by TLS (hopefully). Meanwhile your local ISP can see you're connecting to something in Russia, full stop. For someone to track you down, they'd have to get the compliance of both your ISP and your Russian friends... AFAIK, there are exactly zero cases on record where this has been successfully done.
https://github.com/jedisct1/dsvpn
For routing all your internet it's as simple as this (on the client only, no server setup):
That's it... server requirements are met by almost anything, you don't need root access, but it does need python, which most distros have by default. Now you can use your own little obscure server, yes it's not invulnerable a VPS provider can still look at you if they wish, but it's far less of a target than a purpose built consumer VPN provider.It's also far more powerful for slicing up and mixing subnets or only routing specific targets ... for example unblock a specific site, but don't re-route other traffic:
[edit]Minor issue worth mentioning, not to disappoint people trying this out - it's currently necessary to use the -x option to exclude the server itself from being routed on Linux, I think this is due to a kernel bug? which is a little annoying, hoping this will go away eventually. This is not relevant to BSD or Mac, although on Mac you have other kernel bugs to worry about in XNUs network stack.
[edit]As "icelancer" has pointed out bellow, please note that using your own server ties your activity to your identity more definitively if you are the only one using the server and you pay for the server in your name. Not being a purpose built consumer VPN makes it a less likely target through significant obscurity, however in the event it IS targeted, it's uniqueness will make it easier to associate activity with you via the VPS provider.
> This also ties your identity to a provider definitively. That's fine, as long as you tell people that's what is happening. A good consumer VPN that isn't a garbage one offers plausible deniability.
Any server you have a login to, right? So in some respects wouldn't a commercial VPN be simpler?
It's almost as simple, faster, and importantly, far more obscure... vs consumer VPNs which are almost honey pots.
It's also more powerful, you can selectively route things through different servers simultaneously.
I suppose that negates my point about it's obscurity, since you only care about that if you are evading prying eyes of some sort.
I've updated my original comment to include your point.
For those of you who are thinking "eh, I like my `ssh -D8080 user@1.2.3.4` solution", sshuttle has the following two advantages:
1. no need to configure your SOCKS proxy in your applications
2. it works even when dynamic forwarding is disabled on the host you're connecting to
"Generate a private and public key pair for the WireGuard server:"
"umask 077 wg genkey | tee privatekey | wg pubkey > publickey"
"This will save both the private and public keys to your home directory; they can be viewed with cat privatekey and cat publickey respectively."
"Create the file /etc/wireguard/wg0.conf and add the contents indicated below. You’ll need to enter your server’s private key in the PrivateKey field, and its IP addresses in the Address field."
That's not within reach of your average computer user.
Same for sshutle.
Given that WireGuard is headed for inclusion into Linux mainline soon, it probably would be a good idea for folks to take a few minutes to learn how to use a technology that is going to be part of core Linux.
[1]: https://github.com/cyphar/dotfiles/blob/master/.local/bin/wg...
[1]: https://github.com/jenh/sevenminutevpn
But you're quite right that if you already have a config that you know works, WireGuard has no significant advantage in this area (in terms of ease-of-configuration -- though the keys being quite short is nice for SSH-like key distribution). But if you're starting from scratch then you need to first figure out what is the right configuration to use (or you need to pick from the many dozens of "set up OpenVPN quickly" scripts) and then you need to hope that your configuration is not insecure.
WireGuard can be set up and work just as well as any other configuration without a script in a couple of minutes (or less than a minute with a script). The script that was linked in a sister comment to "set up OpenVPN quickly" also sets up Apache for god's sake...
sshuttle uses ssh, which in turn is not wedded to any one cipher. How does wiregaurd improve on this?
The "agility is bad" crew have a decade or two to wait before they can show anything at all meaningful beyond "my new thing is newer than your old thing".
That doesn't make them wrong, but it makes their position unproven in practice.
By having cipher agility, both clients and servers are incentivised to support the widest possible set of ciphers (because nobody can agree on what cipher to use). This means that it's hard for a known-bad cipher to stop being used (see: the entire history of RC4 usage in TLS) and any downgrade attacks become catastrophic (see: the entire history of SSL/TLS). It also ends up adding complexity to the protocol -- which is always a good thing to have in cryptographic protocols (see again: SSL/TLS)!
Most importantly, if all currently-known ciphers are broken tomorrow, then all servers and clients will have to be upgraded in order to be secure. So cipher agility doesn't help you with the doomsday scenario (everyone needs to upgrade anyway) instead it just ensures that older (completely insecure) clients will still be able to communicate with servers. Why is that seen as a feature? If you really want an insecure fallback mechanism you can implement it with non-agile systems by supporting the two most recent versions of the protocol (I expect this is what WireGuard will do once it's upstreamed). But not everyone wants the "feature" that some clients will silently become insecure.
I don't understand what you're saying with this point:
> The "agility is bad" crew have a decade or two to wait before they can show anything at all meaningful beyond "my new thing is newer than your old thing".
How can the "agility is bad crew" prove their point in a few decades if you're arguing that we shouldn't use such protocols? If they followed your advice, there wouldn't be any zero-agility protocols to compare against in a few decades...
I'm arguing that the case for them is weaker than is often put, but that's not the same as nobody should use them. If a flag day is fine for your use case there's very little reason not to choose this design approach, it is simpler and simpler is good. But you'll notice that the example cited (including by you) for why agility is bad is almost invariably TLS and clearly a flag day isn't practical for TLS because it's far too broadly used.
TLS illustrates my other main thrust of concern on "agility is bad". You describe RC4 as "known bad" and the downgrade attacks as "catastrophic" and this sort of apocalyptic thinking is very popular in the "agility is bad" crowd, but it doesn't truly reflect the ground reality for actual users which is that things went from "It's definitely fine" to "It's probably fine but to be sure we should upgrade". Grey areas are a real thing.
There were protocols that didn't exhibit any cipher agility before by the way. Lots of them. What happened was that they broke, and so agility was added to them retrospectively in new versions that fixed the brokenness. The arguably new thing in the latest round of "no agility" protocols is a supposed determination never to do this. To see how that works out, as I said, you'll have to wait a decade or two.
Among many other things, you cannot do a port scan for WireGuard servers. You can do a port scan for SSH. This is because the WireGuard handshake was designed such that there is no response to unauthenticated packets (the first packet is authenticated by the client knowing the server's public key -- something port scanners won't know).
Jason Donenfeld has a few talks[1] that explain why the cryptographic design is the way it is, and it has several very clear improvements over SSH (as a VPN protocol).
[1]: https://youtu.be/CejbCQ5wS7Q
I really can't overstate how awesome WireGuard is. I really would suggest you take a look at it.
https://www.terminalbytes.com/sshuttle-vpn-over-ssh-vpn-alte...
There's a reason VPN providers have exploded in popularity: mobile internet devices have been mainstream for 5-10 years and they are system-locked but you can install apps.
Note that sshuttle deconstructs the TCP packets before sending them over SSH which already uses TCP, it also performs differently to `ssh -D` and manages the buffer to prevent blocking behaviour over bandwidth limited connections:
If you are using ssh keys you can at least use a bash while loop without incurring any password prompts:
_Hold_ ctrl-c to escape the loop----
> Your IP address is a largely irrelevant metric in modern tracking systems.
I don't believe this for one second.
Your IP address on its own is not sufficient to identify you. That doesn't mean your IP address is not helpful in identifying you.
If you have Javascript disabled, it is a heck of a lot easier to identify you with a combination of an IP address, user agent, and OS than it is to identify you without the IP address cutting down the pool of potential visitors.
On top of that, if you're targeting me and do a geo-location of my IP address, it will get you within 5 miles of my house. That's close enough that you'll know which county I'm in, which with a few other easily-obtained pieces of information will let you pull up my voter registration, which will give you my exact street address.
Of course, you could mitigate this by setting up your own VPN on something like Linode, but unless you're regularly rotating IP addresses, you've just traded a pseudo-identifier that multiple people/devices share for a persistent identifier.
This argument comes up all the time, and I have never heard anyone explain it in a way that passes my sniff test. If you want me to stop using a VPN, you need to do a lot better than just claiming that IP addresses don't matter -- you need to show some kind of evidence to back that up.
----
Broadcasting your IP address to every website you've ever visited is a completely valid concern that gets hand-waved out the wazoo whenever this subject comes up.
I've sent bug reports to sites that publicly tied IP addresses to comments/accounts so anyone could track your movement patterns over time. Yes, that info can be useful to an attacker trying to deanonomyze you. Yes, that info can be used to link users together. Yes, that info can be used to narrow the pool of potential visitors so other fingerprinting techniques are more powerful.
It is blanketly ridiculous to claim that an approximate county-level geolocation isn't a useful data-point to attackers. If IP addresses weren't useful, the Tor project wouldn't be going to such lengths to hide them.
This actually happened to me. I'm using a persistent VPN (50% to access my private infrastructure and 50% because I have a hostile ISP).
I mostly don't use any Google services (maybe one google search a month and the occasional google map search but I avoid when I can) and I was very surprised when once I did a google search and saw my postal code at the end of the page. The IP address was for a VPS (in the same city but with a different post code). I found it unusual but didn't pay too much attention. A few months later I moved places (different post code) and after a while google had my new post code at the end of their search page. That's when I found it troubling and assumed that a family member's iPhone was using Google Maps and based on the 'directions' usage they figured out that that IP address has a home address for those GPS coordinates. (The iPhone in question is reasonably 'hardened' with background updates off and location services only 'when app opened' and disabled for most system services). That was the only plausible correlation between IP address and location google could have done automatically - neither I nor the said family member no longer login to old google accounts we had many years back.
That's when I started rotating IP daily (which is trivial in my case as I use lightsail, I issue a shutdown from a different server and then a power on, AWS rotates the IP automatically out of a very large pool - so far I haven't gotten the same IP twice).
The only problem I have with lightsail is that I often get a 'dirty' IP so I rotate 4-5 times before getting a good one (I test this by going a curl on a website that sends google captcha on dirty IPs but lets the 'good' ones straight in).