Live data from Hacker News

How to build your own VPN if you're wary of commercial options

arstechnica.com

71–80 of 117 posts

Re: How to build your own VPN if you're wary of commercial options

#71

The problem with a home-grown VPN is that you lose some of the plausible deniability that's gained from a shared VPN. If you have a VPN connected to a privately-owned AWS instance, the IP coming from that AWS instance is easily traced back to you. Whereas if your external IP is coming from a cluster that is shared by thousands of other people using that VPN, it is more difficult for someone to tie that specifically b…

There are use cases that make sense. My home linux router intercepts and sends all DNS and NTP requests, then routes all DNS requests to multiple VPS nodes that in turn, use multiple DNS recursors at each VPS datacenter. I intentionally avoid google and opendns. I override the min-ttl of all requests to avoid some shenanigans and I am well aware of the issues this can cause. At a minimum, my ISP can not see or tamper…

"At a minimum, my ISP can not see or tamper with DNS requests."

Are you encrypting each DNS packet at the source (e.g. your home recursor/DNS-forwwarder)?

If yes, when are your sent packets decrypted? At the authoritative nameserver, or at some intermediary recursor?

If no, how do you believe that your DNS packets are opaque and tamper resistant?

There are very few authoritative nameservers on the internet that accept and return encrypted DNS packets. Thus third party recursors must send out unencypted DNS packets. Nothing protects these unencrypted packets from being captured, viewed or tampered with.

It sounds more like you are creating a chain of recursors (that you control?) to make tracing the requests more difficult.

If you are using any third party recursors are you concerned about applications you use that implement support for ends-client-subnet extensions?

Re: How to build your own VPN if you're wary of commercial options

#72

Too bad IPv6 is again ignored completely; not even a mention in the article.

From my perspective in datacenter infrastructure, ipv6 interest has actually declined in recent years.

I think the emergence of a functioning IPv4 market has actually tipped the scales backwards towards v4 unfortunately. I frequently hear from operators that v4 technology (and expertise managing it) for sharing addresses (NAT) is so mature and stable that there isn't much gain for them in the riskier bet on v6.

You would also be shocked at how many also consider the unsolicited ingress connection blocking caused by NAT to be a bonus security feature that v6 doesn't have.

I'm starting to become convinced I will be dead long before v6 dominates the world. :(

Re: How to build your own VPN if you're wary of commercial options

#74
post #65

Earlier quoted context omitted.

Vultr ( http://www.vultr.com/?ref=6979836 ) allows you to pay with bitcoin, making it more difficult to trace you

>allows you to pay with bitcoin, making it more difficult to trace you ...but they require a valid credit card/paypal deposit beforehand, which kills the whole point.

I had no idea of that requirement, kills the whole point indeed :(

edit: there's a list of providers allowing only bitcoin as payment method: http://cryto.net/~joepie91/bitcoinvps.html

Re: How to build your own VPN if you're wary of commercial options

#75
post #46

Earlier quoted context omitted.

That's really cool. Do you have links to share about that setup?

Sorry, I do not. I set it up manually. While I do have some scripts, they are custom tailored to my network setup. That said, it's really easy to do. You could use the other github scripts that folks have linked for setting up the VPN. Then you would want to set up recursive DNS servers on your home router and VPS nodes. Then look into iptables mangle to intercept DNS, NTP, etc. HAProxy L4 vip on the router is an eas…

Really easy indeed. At least that explains your username!

Re: How to build your own VPN if you're wary of commercial options

#76

Earlier quoted context omitted.

Vultr ( http://www.vultr.com/?ref=6979836 ) allows you to pay with bitcoin, making it more difficult to trace you

But they are likely to provide IP addresses used to connect to your server. So now you're facing the same problem, if you wanted to hide your IP address.

Are they so likely? Do you mean they keep logs of every attempted connection to every vps? Even in countries like Netherlands? I'd bet that's less likely than keeping a log of their paying customers' names

Re: How to build your own VPN if you're wary of commercial options

#77
"First your website uses SNI..."

s/uses/may use/

Not every website uses SNI.

For example, the majority of sites linked to from HN do not use SNI.

Also, there are workarounds when SNI is not supported. Workarounds have been published by one major corporation who authors a popular web server software and runs a cloud hosting service.

Is SNI "the only way to do it"? No. There is another way to do stream encryption for mlutiple websites from one IP. It predates HTTPS. This idea goes back to one of the original authors of the world's first web server at CERN. The legacy of this idea survives today as the Websocket "Upgrade" header. Links to further reading below.

Because of groupthink dynamics among today's standards committee people and website owners who follow along, it appears that any online discussion of alternative options to SNI is met with swift dismissal.

http://www.ietf.org/rfc/rfc2817.txt

http://www.ietf.org/rfc/rfc2818.txt

The draft below refers to proxies but further searching will find papers he wrote about how to start an encrypted stream upon connecting to an HTTP server. Any service could sit behind one simple HTTP interface. This idea was revived in "Upgrade" header referred to above. Then forgotten as HTTPS became popular. Then revived again for "Websockets".

http://www.ietf.org/archive/id/draft-luotonen-web-proxy-tunn...

SNI is not the only solution, it is just one approach, and I suspect the next-generation encryption (a TLS alternative that will be readily adaptable to PQ) will not need to send domain names in the clear.

Re: How to build your own VPN if you're wary of commercial options

#78
"... but what about when your ISP literally edits your web traffic, inserting more ads, and possibly breaking webpages."

It is possible the ISP not only injects ads but injects unique identifiers that the user never sees. These could be used to track the user across different devices and networks. This possibilty was suggested a few years ago by a well-known cryptographer in a presentation titled "How to manipulate standards".

Re: How to build your own VPN if you're wary of commercial options

#79

I operate my own VPN endpoint for a couple reasons: 1. I frequently need to connect via open, untrusted local networks, such as those at hotels. 2. Many commercial VPNs (e.g., PIA) end up having some portion of their endpoint IPs end up on blacklists and break a lot of sites. Anonymity from the government is a lower priority than both of the above, and I acknowledge the lack of it in my risk model. Initially I starte…

I can help clvx.easy-rsa, clvx.openvpn ansible role in galaxy.. there's a bug starting the service due to systemd, but it works if it's started manually. I'm working on it though.

Re: How to build your own VPN if you're wary of commercial options

#80

Earlier quoted context omitted.

> AWS instance is easily traced back to you. Define "easily" as used in this context. Easy is a product of whom your enemy is. Is your enemy your ISP? If that's the case, I don't think it's "easy" for them; they would have to pay Digital Ocean or Amazon to get your data, and probably isn't really that valuable to them. Is your enemy the MPAA? If that's the case, I still don't think it's particularly "easy" for them.…

The MPAA will serve an automated DMCA notice to your VPS provider, who will terminate your account at the very least.

This doesn't mesh with reality; The sea of torrent seedboxes in existence would be dropping like flies and not growing.
Post reply on HN