Silk Road forums
Discussion => Security => Topic started by: railroadbill on September 28, 2013, 08:30 pm
-
In light of recent events many are realizing that our biggest fears have come true, a global adversary has formed and is actively monitoring most of the internet. Tor was designed to protect us from those with access to only small parts of the internet but with a birds eye view intelligence agencies can correlate the unique patterns of our communications without ever having to join the network. This attack in some way affects everyone but in particular only affects two groups: Anyone accessing the clearnet and those who wish to stay off the map.
Accessing the Clearnet:
As it stands hidden services have not been deanonymized through this attack and remain safely hidden within the network. As the endpoint is unknown to the attacker they cannot correlate information through packetflow signatures alone (though user-based information leaks and weak correlation through forum timestamps and writing analysis may help provide insight into the source of a event within onionland). When it comes to accessing the clearnet this is where they have a definite advantage. Linked below is a test that was performed to demonstrate the nature of internet routing, and how the quickest point between A and C can sometimes (for some reason) be X Y and Z.
http://i59.fastpic.ru/big/2013/0927/7c/3a6141d19fb003bd9c5442f07381d17c.jpg
It is inevitable that at some point your connection will cross a tapped internet cable and end up into an attackers hands. This does not mean all is lost; if your country is not part of the following list: USA, Canada, UK, Australia, New Zealand, Singapore, Israel, Denmark, Germany, France, Netherlands, and Sweden, then the only surveillance they have on you is their own. When using Tor, if your exit node, the service you are connecting to, or any connection in between passes along the cables connected to any of these hostile nations then they have your endpoint packet flow. This is the inevitability of using Tor to access the clearnet, you cannot assume that they do not possess the contents of your connection. Nothing short of manual PGP message or AES file encryption will prevent them from seeing what you sent, though they may still be able to deanonymize you if they can see at any point between you and your entry guard. This is where we make our Hail Mary pass.
Accessing Tor Anonymously:
For those who wish to use Hidden Services anonymously they just need to connect, and unless their country is known to come after Tor users there is no risk of correlation short of user error. Those who want to access the clearnet and those who want to hide their connection to the network must take special care of the geopolitical path their connection takes to enter the network. Tor is by default configured to connect to a set of automatically chosen entry guards which the user has no control over, this presents an incredible risk as it is not possible to set where you enter into the network, leaving your connection open to interception along the way. Thankfully Tor implemented a concept called bridges which are user selected entry guards and added a feature called pluggable transports which allow for custom protocol obfuscation modules to be created to help hide Tor usage. The only transport to date is called obfsproxy which removes some identifying details of the Tor connection and may help in our attempts. Other protocol obfuscation techniques may actually serve to make more obvious your attempt at hiding so it is advised until release and subsequent review that they not be used.
First download the latest pluggable transport bundle at
https://www.torproject.org/docs/pluggable-transports.html.en
You can find bridges by going to
https://bridges.torproject.org/bridges
And following the instructions on the various ways to obtain bridges. If you want to use Obfsproxy bridges then they will be prefaced with the lines "bridge obfs3". China is known to detect obfs2, so it is better to run obfs3. Once you have collected a list of bridges you want to use enter them into a geoiplocator such as i2plocation.com (from a public wifi spot if you are concerned for your safety) and carefully document the country of each one, removing ones located in known hostile countries (and unless you trust your government, yours as well).
Next you will acquire the services of an encrypted VPN that utilizes OpenVPN who is neither incorporated in a hostile country or one that is under their control. What you will do is first connect to your VPN and start your bittorrent client (while downloading+seeding) which will be set to 'Force Encryption', this will provide uniform cover traffic, and if you trust your VPN, will prevent attackers from being able to detect your Tor packet flow signature on its way to the VPN server. It is not important to remain anonymous to your VPN, they have logs (even if they say they dont), and the attacker will see that you are connecting to the VPN.
The trick here will be to use a VPN server and a bridge both located in the same non hostile country. This will ensure your connection doesnt mysteriously route itself back through NSA headquarters as is the tendency with international connections. Notice that all of the internet backbones dont run THROUGH the countries, they run around them, if your connection must cross the border there is a high chance it will end up on one of these tapped cables. Once your Tor connection leaves your VPN it is in the clear for packet flow analysis, if it makes the trip across untapped cables then the global surveillance machine only has a jumbled mix of encrypted packets across an encrypted stream heading to a VPN in a country they do not control and exiting onto a line they are not monitoring.
However if for any reason your connection does traverse a hostile/tapped cable as it leaves the VPN, it will be possible for them to correlate the flow of that jumbled mix of encrypted packets you sent through your VPN, to you and the Entry node which they are watching (and yes, they are watching all nodes, as they are all connected to eachother and inevitably cross a tapped cable at some point many times per second).
Once you find a set of bridge nodes that are in the same country as your VPN server connect to your VPN and perform an ip trace on the bridge address (leave Tor off for now), if you see your connection make jumps to ips outside of the country then try another bridge. This shouldnt happen but if all else fails try another VPN/bridge country. When you've found a reliable path its time to test your bridges.
Enter the bridge address (test them one at a time):
TOR TASKBAR ICON -> SETTINGS -> NETWORK -> ADD A BRIDGE field, click the '+' sign.
And restart Tor. It will now attempt to connect to your bridge, if it fails then the bridge is dead, try some others from the same country. When you've found a working bridge clap your hands, you've just evaded the combined might of nations.
-
What's the difference between the "Pluggable Transport Bundle" and "Tor Browser Bundle"?
-
interesting read thanks,am now going to have to check my bridges to see where they come from.
how would you implement vpn in tails? i've read that it isnt advised and best done in router, but mine doesnt support it.
so in effect although i use tails my isp can see that i am using it until my bridges boot in.as there is usually a couple of second delay. :o
looks like imo that whonix and qubes are going to be the neccessary setups to have any hope against these twats.
-
You don't just have to hope a bridge or entry point is 'good' you could make sure it is in a few ways:
1) Run a local relay on your home Internet connection 24/7 - limit bandwidth down as appropriate - perhaps to 30kb/sec but be aware than the more you throttle it down the less cover it provides for your own tor traffic.
- You use this relay as your entry point SOCKS proxy - your TOR traffic is then to some extent 'hidden' in the relay and directory traffic that is moving in and out of your relay constantly. Traffic volume and or stream analysis alone will be less effective for an attacker who is able to monitor your internet connection. However arguably you are holding up a big red flag saying I RUN A TOR RELAY RIGHT HERE - hardly under the radar. Doesn't really help you for clearnet access much (other than generally making correlation harder)
2) Rent a VPS which is adjacent or very close to your own home network. Turn it into a TOR relay. Then you use this as your entry point (you can configure TOR client to always use your relay as the TOR entry point). If you configure your relay as an exit node then you can also hardcode your TOR client to exit there too. That way you end up with known good entry/exit points and it is unlikely that your traffic will pass through an Internet Exchange where it will be snarfed by passive taps. HOWEVER IF YOUR LINE IS WARRANTED THEN THAT IS IRRELEVANT AS YOUR TRAFFIC WILL BE SNIFFED BY YOUR ISP (or your ISP's ISP) before it gets to the Internet. You could just VPN directly to the VPS if you wanted and use it directly as a proxy; that way you only run TOR from the VPS rather than from your endpoint - although I think at the loss of some deniability. What I like about the hosted relay is that it also gives you exit node cover for clearnet stuff (your browsing traffic is mixed in with loads of other users) that you know is a 'good' node. Again though - you are holding up a bit of a flag. You could run a bridge instead if the relay is a little too "I'm here!" for your liking.
3) Ditch TOR and just use IPv6 as most LI platforms still doesn't parse it properly making ip6 traffic largely unmonitored :) yet.... I'm sure that is changing as we speak.... would be nice if TOR worked over ipv6 but it isn't there yet
-
Subbing, this seems important and I need to learn more about it.
-
(edited my snarky post. I misunderstood railroadbill's concept of tunneling the torrent over the VPN but not over the Tor traffic. Was still sorta pissed about him accusing me of secretly being kmfkewm in the Dissent thread).
Will post less-snarky response below.
-
+1 to OP for this post!
-
What you will do is first connect to your VPN and start your bittorrent client (while downloading+seeding) which will be set to 'Force Encryption', this will provide uniform cover traffic...
Because bittorrent + Tor is a great combination. You can tell, because when you search google for "tor torrent", then first link you get is this one:
https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea
He didn't suggest to run Bittorrent through Tor. He suggested running it through the VPN, with Tor running through the VPN at the same time. This is an efficient method of providing cover traffic. There are speed fluctuations in the traffic which make it at least a lot harder to do traffic correlation, if it's still possible at all anyway.
More efficient would be an additional traffic shaper which reduces the Bittorrent download speed every time you look at a webpage through Tor. I think that would make traffic correlation pretty much impossible, assuming the route between VPN and all Bittorrent seeds is not monitored by the adversary.
-
He didn't suggest to run Bittorrent through Tor. He suggested running it through the VPN, with Tor running through the VPN at the same time. This is an efficient method of providing cover traffic. There are speed fluctuations in the traffic which make it at least a lot harder to do traffic correlation, if it's still possible at all anyway.
More efficient would be an additional traffic shaper which reduces the Bittorrent download speed every time you look at a webpage through Tor. I think that would make traffic correlation pretty much impossible, assuming the route between VPN and all Bittorrent seeds is not monitored by the adversary.
I edited my previous (too-dickish) response. I completely misunderstood that torrent traffic was being tunneled over the VPN but not Tor.
Sorry, railroadbill, I was still a little wound up at you accusing me of secretly being kmfkewm in the Dissent thread. Still think that was retarded, BTW. But neither this idea, nor this thread is retarded.
This idea helps to make tracing the VPN connection itself more difficult. At the end of the day, you end up with the same basic security model as just using a VPN, except it's much, much more difficult to correlate the traffic flowing through it with the Tor traffic.
If you can dump your VPN off somewhere far from NSA visibility, and you have significant cover traffic running through it, you're definitely in better shape from a correlation perspective.
All the other usual VPN risks still remain, of course.
So you just need to find a VPN endpoint that can talk to a bridge/guard without being intercepted. And probably need to make sure that none of those networks you're traversing in the foreign country are operated by a Five Eyes-based telecom company to be on the safe side. The Verizons of the world have clearly proven that they're happy to give any access to NSA with just a NSL. Ditto with any carriers operated by countries that you believe would trade NSA the access in exchange for access to something they wanted.
To re-frame a point I made in my shitty post earlier in a more polite tone, the Internet "backbone" doesn't just run around and between countries. IX/NAP points exist in (and I mean *inside of*, not at the national boundaries of) most first-world countries, and those exchange points are high-value targets for NSA surveillance. So you need to dodge those points if you're worried about monitoring at them. And your routes between any two points may shift drastically based on Internet routing changes.
I don't know enough about the subtle nuances of torrent to know if you pick up risk there, but whatever you get, it still has to be correlatable to your Tor traffic before it matters from a Tor perspective.
Anyway, now that I actually understand it, it's an improvement, assuming the right combination of VPNExit->UnmonitoredNetwork->Bridge exists. It doesn't fix the core Tor problem, but it at least makes NSA go chase down the VPN Exit->Tor traffic in a faraway place if they want to find you, which is a pain in the ass if you find the right combination. And if they're having to work harder, I'm happier.
-
More efficient would be an additional traffic shaper which reduces the Bittorrent download speed every time you look at a webpage through Tor. I think that would make traffic correlation pretty much impossible, assuming the route between VPN and all Bittorrent seeds is not monitored by the adversary.
That part should be doable to significant degree with something as simple as OpenWRT on an AP establishing the OpenVPN connection and doing traffic shaping on it. Something with more trustable RNG than little access points might be smarter though.
Actually, heading down that path farther.. make a gateway that just directed all traffic behind it through the OpenVPN. Have your cover traffic flowing through it, prioritize traffic destined for the Tor bridge as highest priority. Freenet traffic as mid-tier priority, and the torrent/cover traffic as lowest priority.
Traffic shaping may end up putting some hard edges in the encrypted VPN stream (it's hard to reliably shape traffic into anything perfectly even), but the risk you're dodging with this is that you fall into a broad net.. if you're individually targeted, you have different problems.
As long as you *always* have cover traffic when you're sending requests, I like it. It's going to give a slower Tor experience, but you can't have it both ways.
The missing ingredient in this whole equation is finding that magic combination of (Torrent-Friendly)VPNExit+Bridge without running it yourself. And if you find it, you should think long and hard before you share it with anybody else. Like all obfuscation technologies, the more people that use a specific one, the less useful it is.
This is exactly the point in the conversation where somebody suggests we combine the two (Torrent-friendly VPN+Bridge) into a for-pay anonymity service. You pay with Bitcoin, and all they have are your real source IP and a possibly compromised guard node. They still need the other end to correlate traffic. That idea exchanges the risk of VPNExit->Bridge interception with the risk that since those two pieces are obviously related (part of the same for-pay service), you can make the assumption that the bridge traffic is coming from the VPN destination. Probably can't prove it, though. I'll have to think on that one.
-
when I sober up I will give this a detail read but from glance this is a interesting post and has very valid points
-
Interesting topic.
Could running the VPN exit & entry guard on the same server be interesting? If the entry guard is used by more than 1 person, of course...
-
I have talked about using a private bridge as an entry guard before. That is a good idea.
However, a private exit node isn't such a good idea. There are a few problems here
- all traffic goes through the same IP therefore an adversary could link a certain user back to that IP. Not so anonymous, particularly if you somehow purchased the VPS in some way that can link back to you.
- When combined with the bridge, you now own and trust 2 of 3 hops. But it only takes the other hop to realise the connection and monitor all your traffic. Encryption helps here but as the paranoia increases, this is thought not to be safe. NB: You could set tor to use more hops to help here for compromise in speed.
- Other users (presumably) may cause your exit node to be banned by certain websites. *Could* make it particularly useless for clearnet browsing.
-
would be nice if TOR worked over ipv6 but it isn't there yet
The closest thing to that is Onioncat. It creates an IPv6 VPN tunnel that goes through the Tor network. This allows IP and UDP based applications to be tunneled through Tor.
-
I have talked about using a private bridge as an entry guard before. That is a good idea.
However, a private exit node isn't such a good idea. There are a few problems here
- all traffic goes through the same IP therefore an adversary could link a certain user back to that IP. Not so anonymous, particularly if you somehow purchased the VPS in some way that can link back to you.
- When combined with the bridge, you now own and trust 2 of 3 hops. But it only takes the other hop to realise the connection and monitor all your traffic. Encryption helps here but as the paranoia increases, this is thought not to be safe. NB: You could set tor to use more hops to help here for compromise in speed.
- Other users (presumably) may cause your exit node to be banned by certain websites. *Could* make it particularly useless for clearnet browsing.
The idea was just a bridge, and the server would also be used as a VPN. That way you would connect internally to the bridge - and you can add a few more TOR hops if you feel like it's needed. Not sure it helps though, but it would hide your TOR traffic from your ISP, and you'd be connecting to a bridge you can trust (if you trust the server's hardware and software, of course).
The goal is to get your network connection outside of your hostile country and its collaborators without it being identified as carrying Tor circuits. A VPN with cover traffic is the best way to do that. From there, I think you can use any entry guards as long as they are not in other hostile countries (you can manually set them with EntryNodes country/relay name/fingerprint in your torrc). You get better anonymity when you mix in with more people at public entry guards. There are 30K bridge users and 2000 bridges. That's 15 users per bridge per day. At any one time, you are likely to be the only person using that bridge, making your connection completely nonanonymous.
Well, if you consider that cryptography might be totally broken (either by the way it's implemented or the underlying math) then the VPN isn't useful anymore... ;)
-
Well, if you consider that cryptography might be totally broken (either by the way it's implemented or the underlying math) then the VPN isn't useful anymore... ;)
That may be the case if they are targeting you, but it's unlikely they are breaking every VPN connection in the world on the fly.
-
Well, if you consider that cryptography might be totally broken (either by the way it's implemented or the underlying math) then the VPN isn't useful anymore... ;)
That may be the case if they are targeting you, but it's unlikely they are breaking every VPN connection in the world on the fly.
I would imagine that, for a well resourced attacker able to eavesdrop the VPN initiation traffic, nearly all PPTP VPNs can be cracked on the fly as near as dammit assuming they are MS-CHAP/v2 derived which nearly all are. I assume that the same is true for L2TP where MS-CHAP/v2 is used.
We trust this is not the case with a 'properly' configured IPSec VPN or TLS/SSL VPN. Quite what 'properly' means is open to debate at the moment but potentially excludes SSL/TLS authenticated with mainstream CA issued certificates if recent disclosures are accurate. (Depending on how the certs was configured and installed, the CA may retain a copy of the private key)
I do not attribute this ability to LEO - just the agencies for the time being.
I am afraid I am too lazy to post links, dyor. The vulnerability is reasonably well documented, the recent XKEYSCORE slide disclosure indicates that agencies may exploit (some) VPN vulnerabilities en mass or at least on demand and we know it is technically achievable.
-
I would imagine that, for a well resourced attacker able to eavesdrop the VPN initiation traffic, nearly all PPTP VPNs can be cracked on the fly as near as dammit assuming they are MS-CHAP/v2 derived which nearly all are. I assume that the same is true for L2TP where MS-CHAP/v2 is used.
We trust this is not the case with a 'properly' configured IPSec VPN or TLS/SSL VPN. Quite what 'properly' means is open to debate at the moment but potentially excludes SSL/TLS authenticated with mainstream CA issued certificates if recent disclosures are accurate. (Depending on how the certs was configured and installed, the CA may retain a copy of the private key)
Do OpenVPN servers use CA certificates? I know they usually give you a cert called ca.pem, but I thought that was a self-signed cert. Every guide I've seen for setting up OpenVPN servers includes instructions on generating these certs, with no mention of buying them from certificate authorities. Most of these are 2048 bits, so not trivial to brute force, unless there are other weaknesses, or they steal the root certificates of major VPN providers. Perhaps it's a good idea not to use popular providers that everyone talks about, like HideMyAss and Private Internet Access, since these will be big targets for certificate theft.
-
As a side note, certificates from vpngate.net are most likely not stolen by the NSA, as the free VPN's are provided by private users and every VPN has a different certificate. You could cycle the VPN daily etc. Though you have to be careful anyway when connecting to it, because they person who runs it may be a hacker. And they probably won't appreciate it when you run cover traffic through it.
-
Do OpenVPN servers use CA certificates? I know they usually give you a cert called ca.pem, but I thought that was a self-signed cert. Every guide I've seen for setting up OpenVPN servers includes instructions on generating these certs, with no mention of buying them from certificate authorities. Most of these are 2048 bits, so not trivial to brute force, unless there are other weaknesses, or they steal the root certificates of major VPN providers. Perhaps it's a good idea not to use popular providers that everyone talks about, like HideMyAss and Private Internet Access, since these will be big targets for certificate theft.
OpenVPN, as with any other SSL server can use certificates issued by a public CA (e.g. Comodo, Verisign etc) or they can use certs from an internal or private CA.
95% of the time I see OpenVPN configured with internal CA certificates and that internal CA certificate is probably what you have in your PEM file given its name.
You can check the contents of your cert/pem files using openssl as follows:
openssl x509 -text -in CERT_FILENAME
Where CERT_FILENAME is the name of your CRT or PEM file. This returns a whole bunch of output and you are looking at the 'Issuer' section to see who the CA is and 'Subject' section to see what the certificate is issued to. You will see from the issuer who the CA is and whether it is internal or one of the public CAs. Here is some output from the above command run against my own client certificate (some lines have been removed for brevity) - you can see the 'Issuer' is my own made up CA, not one of the public/commercial CAs.
Certificate:
Data:
Issuer: C=US, ST=CA, L=SanFrancisco, O=My Private CA, OU=changeme, CN=My Name/name=My Name/emailAddress=mail@host.domain
Subject: C=US, ST=CA, L=SanFrancisco, O=My Client Organization, OU=changeme, CN=some-client-name/name=My Client Nam/emailAddress=me@client.onion
There is nothing inherently wrong with public CAs but the two main issues in my opinion are:
1) Anyone who can convince/coerce the CA into generating a certificate and has access to your network traffic at any point between source and destination can undertake a man-in-the-middle attack on your encrypted traffic. This would allow them to eavesdrop and potentially modify your cleartext traffic. This attack must be performed actively and only affects traffic transmitted during the attack. It can be detected but requires that you check that the SSL certificate fingerprint is the same as when originally issued.
2) Certain certificate products from certain vendors can be purchased and set up in such a way that the CA generate your server public/private key for you and (presumably) retain it - this is bad as it means the CA can give away or loose your private key leading to the possibility of compromise for any traffic secured using that key. This means that the CA or whoever they give the private key to can, assuming they can access your encrypted traffic, decrypt anything that has been transmitted. This means that if they have several months of encrypted traffic and then for some reason end up in possession of the private key, they can decrypt any of it. Note most of the time the end-device generates the public/private key pair - not the public CA. This is of course highly desirable and stops this problem (but not the 1st issue above). It would be a useful exercise for someone to research which public CAs offer this less secure method of certificate generation - I really have no idea how widespread the practice is.
I'm not a fan of commercial VPN offerings and as I have mentioned elsewhere, I know for a fact some commercial VPN providers have been subverted by LEO in the past (even run by them!). They ARE great for getting round geographic content restrictions but I don't fancy them for providing much in the way of security.
-
I guess we are using the term CA differently. A certificate authority to me is one of the 650 countries or companies that get their root certificates installed in various products like browsers. So if the NSA can get any one of those root certificates, they can sign a client certificate to MITM you (unless the certificate is pinned). With OpenVPN you are given one root certificate by your provider. It's a lot harder to MITM because the client certificate has to be signed by that one root certificate, not any one of 650. Unless there are other weaknesses in the protocol, OpenVPN is a lot safer than HTTPS, which can be broken by stealing, hacking, or brute forcing any of the root certs in your browser.
The CA system is shit precisely because it relies on the security of 650 independent entities, and is only as secure as the most insecure one, and we know some of them have been hacked. We can also be 99.9% certain many of them have turned their root certs over to the NSA.
Meanwhile, a random person or organization that signs their own cert is not a certificate "authority" by my definition. I can sign cert for my web server and your browser will act like your computer is going to explode when you encounter it. Although if you accept my certificate, you can't be MITMed there after.
-
Most moderate and large companies run internal CAs which are not linked (trust wise) to the 600+ public CAs you refer to. I agree the public CA's are a liability but they do fill a trust void - how else do we get a browser to trust a certificate issued by a server for the masses?
I like the TOFU (Trust On First Use) method that we see with SSH for instance - so the first time we ever connect to a remote server we are prompted to accept or reject the presented certificate after which it is remembered. This I guess works OK and is my own preference. But I can also understand that if you have 2 billion browser users, most of whom do not know what SSL is and a few million SSL servers out there there would be much more scope for MITM shenanigans without some sort of 'built in' trust provided by the public CAs, however open to subversion it may be.
Regarding somebody with access to stolen or illicit CA certs, there is something called the SSL observatory which is basically a firefox plugin that validates all SSL certs when you visit a site against the SSL observatories own database of fingerprints. It is designed to spot MITM attacks but personally I have anonymity concerns with my browser essentially notifying SSL Observatory of all of the SSL sites I'm visiting. I like the concept though and extending it one could see how CA's could become redundant.
-
I don't see the value in using bridges against an adversary that can almost certainly enumerate all of them. We're not talking about the Iranian government here. We're talking about a collaboration of western intel agencies that function as a near-global passive adversary.
The goal is to get your network connection outside of your hostile country and its collaborators without it being identified as carrying Tor circuits. A VPN with cover traffic is the best way to do that. From there, I think you can use any entry guards as long as they are not in other hostile countries (you can manually set them with EntryNodes country/relay name/fingerprint in your torrc). You get better anonymity when you mix in with more people at public entry guards. There are 30K bridge users and 2000 bridges. That's 15 users per bridge per day. At any one time, you are likely to be the only person using that bridge, making your connection completely nonanonymous.
The goal is to get your connection outside of your hostile country and pass it to an entry guard in a non-hostile country without passing it over a tapped line. From what we are seeing the internet backbones running between countries are being tapped by five-eyes and their cohorts. That means if your connection leaves the entry guard's country then its probably going to go onto one of those tapped lines. Simply excluding certain countries does not protect from this.
-
interesting read thanks,am now going to have to check my bridges to see where they come from.
how would you implement vpn in tails? i've read that it isnt advised and best done in router, but mine doesnt support it.
so in effect although i use tails my isp can see that i am using it until my bridges boot in.as there is usually a couple of second delay. :o
looks like imo that whonix and qubes are going to be the neccessary setups to have any hope against these twats.
Tails is not a very good OS imo as it contains a clearnet browser that can easily deanonymize you, on top of the fact its persistence feature is heavily locked down making it impossible to customize. You can get a dd-wrt capable router that will work with any VPN that advertises that compatibility. I have not used one yet personally but this would simplify things if you have multiple computers or are concerned with programmes working around your VPN.
-
I am no expert on VPNs, i suggested OpenVPN because of its popularity and no known vulnerabilities, though if it depends on a trust model then perhaps there is a better alternative, is there?