Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

Catalysing a return to technical accuracy in VPN discussions

Encouraging best practices in the VPN industry via independent, community-certified verification of clean installers and clean basic service operations. Let's reward the good, and make the bad a little bit less tempting 〰 github repo#cleanVPN
User avatar

Topic Author
Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Catalysing a return to technical accuracy in VPN discussions

Postby Pattern_Juggled » Mon Jun 03, 2013 1:00 pm

It's become somewhat of a hallmark of discussions concerning VPN services that technological precision gets routinely cast asunder in favour of mythological explanations. There's plenty of good, accurate resources out there... but for every one of those, there's a random tidbit of misinformation floating around.

As someone who has been working with these VPN gizmos for close to a decade, some of the stuff I read is just... srsly? Mostly, I just shake my head or run it by friends in the industry to see if I'm wrong in seeing these errors. Sometimes I'm wrong - nothing surprising there - and my own knowledge improves a bit as a result. However, distressingly often there's real errors being passed about - they may start from a simple misunderstanding, or they may be fed into the narrative by selfish actors seeking a way to get ahead. Irrespective of how they initiate, those errors seem to feed on themselves, and get repeated, and become a form of parallel reality as they get passed around.

So it's time for some debunking! :thumbup:

To help get the ball rolling, I figured I'd start collecting them into a thread here. And there's a point: for whatever reason, VPNs and VPN technology attracts a kind of hand-waving nonsense nowadays - people say stupid things about them, crazy things sometimes. And it's indicative of a larger problem: the spread of bullshit in the "VPN industry" overall..

Note that my point in this thread isn't to make fun of folks who make mistakes in technological explanations. We all do that - I do it more often than many, less than some. Errors happen. But mostly, the idea is that if we're not sure whether our explanation is correct, we do some research to see if we're understanding things correctly - or we ask genuine experts to fact-check our understanding. That is, we seek out disconfirmation of our views as a way to test them - standard scientific method stuff, eh? So we may be wrong - and occasionally everyone is - but over time we correct at least some of these errors, and we seek out further corrections as we go.

This self-correcting process has gone walkabout in the VPN industry, as it's grown from a niche into a "get rich quick" game of marketing hype and seedy pay-for-play "VPN review" pimp sites that have become prime conduits in spreading nonsense (what Neal Stephenson refers to as "bullshit" a term of art within his Anathem universe).

For folks who make errors highlighted in this thread, our intention is to provide constructive feedback - positive feedback, not negative. And if we make errors in our flagging of errors, of course please let us know and we'll correct those! The idea here is to both improve our understanding, and to perhaps catalyse a more robust commitment to technical accuracy in discussions of VPN technologies.

Procedural note: I've highlighted areas of concern in materials echoed into this thread by putting them in an annoying red colour, so they're easy to pick out in context - later on, I pull them as quotes and discuss what it is in them that's rubbing me wrong.

Cheers,
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Topic Author
Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: Catalysing a return to technical accuracy in VPN discuss

Postby Pattern_Juggled » Mon Jun 03, 2013 1:07 pm

The Blackberry Z-10 Scores Again: VPN
April 23, 2013 01:08 PM


If you're not concerned about mobile security you're not very bright. Carriers can triivally look at what you're doing online, if you care. Encrypted email transport secures your email -- but nothing else.

In addition, there's a little-known secret about mobile data access -- it's slow. No, you won't hear the carriers talk about this much if at all, instead lauding their "LTE" or "HSPA+" data transport speeds. But these are speeds once a connection has been made and for most mobile devices anything beyond 1 or 2Mbps for common uses are utterly immaterial -- even for video (due to the relatively low perceptible screen resolution on said devices.) In addition data quotas make trying to hammer a line with high-speed (e.g. LTE) data problematic for your wallet.

The problem with mobile data performance lies in what carriers do in the back room. They are all doing "deep packet inspection" now to try to detect tethering cheaters, among other things. This means that they have their computers doing both "NAT" (address translation) and also inspecting each packet robotically before passing it on. This takes time -- lots of it -- and in addition they are all doing screwball proxy server inspection and packet thrashing in an attempt to reduce traffic on their backbones (but you get none of the benefit of that, since you are metered by the byte to the phone!)

I'm sure there will be many screams about "privacy!" that echo around over this, but the real problem doesn't lie there. It lies in performance. In short, a web transaction is quite slow to start moving data as a direct consequence of what the carriers do with your packets. This has always sucked and as the networks have gotten more-congested it has sucked more and more.

For those who care about privacy using a VPN has been one traditional way around the security issue. VPNs encapsulate your traffic in an encrypted container, then strip that on the other end. Traditional VPN "user friendly" technology uses a protocol called PPTP and sometimes LT2P. But these protocols are somewhat insecure and more importantly they're historically slow imposing anywhere from a moderate to very severe performance penalty over non-VPNed connections.

Enter IKE. V1 was faster that LT2P and PPTP but still had security issues in many circumstances. IKEv2, on the other hand, is fast, uses IPSEC (a formal IP extension for encapsulating packets securely) and a wide variety of authentication options including shared secrets ("passwords"), secure certificates (public-key) or both. It also internally implements a tunneling mode that (with appropriate kernel support in the gateway host) can take advantage of hardware encryption acceleration and reduces overhead dramatically, leading to gross user experience improvement, and knows about potentially-changing user endpoint addresses (e.g. a phone moving around that gets handed difference IP numbers as it goes from one location to another.)

I have not bothered implementing the VPN connection capability on my Android devices, mostly because they're clunky and offer performance impairment rather than enhancement. Using the older protocols they suffer from performance issues exactly as do the same protocols on a Windows machine, and in addition must be manually turned on and off as they don't know about address-hopping. This is ok when you're sitting in a cafe and want to make sure your traffic doesn't get intercepted and I put up with it when I need to access something on my local network that I am unwilling to leave facing the Internet as a whole.

It's not so good with a phone in your pocket that is hopping from one cell -- and IP Address -- to another.

IKEv2 solves this with an extension known as "MOBIKE", making such transitions mostly seamless.

Ok, so why am I spilling all this ink?

Because I have managed to integrate the Blackberry Z-10 with FreeBSD's StrongSwan IKEv2/IPSEC VPN capability, and all of those objections have disappeared, making full-time No-BS VPN not only transparent it actually improves the user experience compared to a bare internet connection as opposed to impairing it!

Tickerforum displays, at the bottom of each page, a statistical piece of data on load times. This is not just the time required by the system to process your request internally; it also includes transmission time of all the elements of the page. In other words it's an "end-to-end" view of the transaction from the time the system starts processing your request until it finishes it. The only missing piece is that buffer drain time is not measured as the application cannot determine it.

Here's a fairly common view of that time for a "New Posts" command when running through a 4G cellular data connection that allows the carrier to "do it's thing" by using an unencrypted carrier-based packet channel:

Note the "Elapsed:" line -- 5.445 seconds. This is pretty typical, and most of it is round-trip waiting -- that is, it's not transmission time, it's the time for the gateway to do both its NAT and "deep packet inspection" in both directions. This is on a HSPA+ connection that is capable of and does reach 10Mbps+!

Now let's look at what happens when I enable IPSEC/IKEv2 on the same connection, adding two hops to the transaction as well.

The same command now takes 162 milliseconds to complete -- it's 33 times faster!

Now granted, the amount of data involved in this command is small (it's a "new posts" list request.) But the user perception of performance over the 4g link is now effectively identical to that over WiFi sitting on my local network, although I'm actually on a mobile data connection!

There is a price for this, in that the IPSEC server must have a fast connection to the Internet itself, and for bulk file transfers this will slow things down, because the data flows over that link twice in getting to you on the phone -- once in and once out. If you run a "Speedtest" over the VPN it'll be about half the speed of the raw connection but few actual uses, other than video streaming, are reasonable analogues of a speed test. Rather, most user experiences are more-akin to the web-page model where you ask for a piece of data and then get it, and the actual amount of data you receive is relatively small.

So how hard was this to set up? Quite a bit, but not due to really being hard, but rather due to the piss-poor set of documentation that comes with these protocols. IPSEC offers a framework of capabilities and unfortunately the existing projects are mostly concerned with the idea of linking a remote office or LAN rather than the "mobile warrior" sort of single host. In fact I banged my head on the wall over the StrongSwan configuration for a couple of days before I figured out what was going on (packets appeared to be literally disappearing for quite some time!) mostly because PPTP and LT2P are radically different in how they work internally (and that's where my previous VPN experience has come from.)

Nonetheless, BlackBerry's Z-10 offers a quite-easy to set up option with "Generic IKEv2" in its VPN screens and that option offers both the greatly enhanced security and performance of IKEv2 along with the performance improvements, while using either certificate authentication or pre-shared keys (passwords.) Not only do you get secure access to your home or office you also get security against prying eyes of the cell carrier and improved performance.

Finally, the Z-10 can be told to bring up a VPN connection automatically whenever on a cellular connection or on individual saved Wifi networks. This means that you can roam around and have the phone automatically secure and performance-enhance your connection without having to click the "enable" button all the time -- reducing your risk and making use both seamless and easy.

The only "gotcha" is that if you tether the tethered device does not go through the VPN. However, you can have the tethered device access the same VPN server if you wish as well.

I have one objection -- the Z-10 does not display an icon in the notification bar if VPN is enabled and in use. Blackberry needs to fix that so you can tell "at a glance" if the VPN connection is up or not.

As I've noted Android devices and IOS (iPhones/iPADs) support LT2P and other VPN options, but as far as I know IKEv2 is not supported, at least not out of the box. To those who think it is not a big deal, you're wrong -- IKEv1 using clear-text passwords is subject to offline attack and LT2P, which is the common transport, is quite-inefficient compared to bare IPSEC/IKEv2. For those who are in a corporate environment the use of certificates can (and does) overcome the security problem but you're still not going to see the performance levels you can achieve with native tunneling on an IPSEC/IKEv2 connection.

Blackberry wins big in this regard with the Z-10 -- they have both a security and performance advantage, and the latter, on mobile networks, is not small.

Disclaimer: You can pry my Z-10 out of my cold, dead fingers. (Oh yeah, I own BBRY stock too)
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Topic Author
Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: Catalysing a return to technical accuracy in VPN discuss

Postby Pattern_Juggled » Mon Jun 03, 2013 2:10 pm

They are all doing "deep packet inspection" now to try to detect tethering cheaters, among other things. This means that they have their computers doing both "NAT" (address translation) and also inspecting each packet robotically before passing it on.


I don't know of any data confirming the claim that wireless carriers are routinely running full DPI on every packet transiting their networks. That's both computationally expensive, and would need extensive bureaucratic configuration to even know what sort of things are being tagged/flagged/filtered. Plus, at least in the USA, utilizing DPI at such a massive scale would - in theory, at least - run afoul of wiretapping statutes (as to whether they'd ever be enforced or not, a different and more complex question). That level of reading of electronic communications is supposed to require a judicial warrant (although the NSA doesn't think so, nor quite often the FBI, and so on...).

Wireless carriers aren't really using NAT, not that I've ever heard of. Indeed, NAT is really not even close to suited for wholesale-class network traffic levels. NAT is a hack, basically, designed for small stuff like routers and mostly used in "edge of network" scenarios ("Network Address Translation allows a single device, such as a router, to act as an agent between the Internet (or "public network") and a local (or "private") network. This means that only a single, unique IP address is required to represent an entire group of computers."). It's finicky, not terribly reliable, and certainly not something that is used in wholesale backhaul scenarios. They certainly engage in network management practices that are somewhat equivalent, in functional terms, to "NATting" - ensuring ports are mapped through network topology, basically.

VPNs encapsulate your traffic in an encrypted container, then strip that on the other end.


Most everyone - myself included - talks about "encapsulation" as something that's done by VPNs. But they don't encapsulate anything. Encapsulation is actually one of the four attributes of object oriented programming (those four being: Data Abstraction, Encapsulation, Polymorphism, Inheritance... and sometimes fifth ones are tacked on, or not). It's summarized as follows: "In object-oriented programming, objects interact with each other by messages. The only thing that an object knows about another object is the object's interface. Each object's data and logic is hidden from other objects. In other words, the interface encapsulates the object's code and data."

But VPNs don't do anything like this. Indeed, the entire idea of a "tunnel" - which we all use when discussing VPNs - is something of a misnomer. There's no "tunnel," and nothing is "inside" of anything else in tactical terms. We're using the words in a conceptual sense - something akin to the distinction between the logical topology of a network and the physical topology. They are quite different.

VPNs generally re-packetize data. There is no "wrapper" - there's just packet headers, and packet payload. Nothing is "encapsulated" inside anything else. True, there's cryptographic hanky-panky going on... but it's not inside anything, nor outside anything. It's just encryption.

The problem is, when we start taking concepts like encapsulation and tunnels seriously as descriptions of what's happening with VPN connections, we make all sorts of goofy assumptions about how things are operating - and these assumptions breed further errors. That's not to say that we need to banish these words from our vocabulary - only that we need to be aware they are being used in a purely metaphorical sense. Not as descriptors of actual reality.

Enter IKE. V1 was faster that LT2P and PPTP but still had security issues in many circumstances. IKEv2, on the other hand, is fast, uses IPSEC (a formal IP extension for encapsulating packets securely) and a wide variety of authentication options including shared secrets ("passwords"), secure certificates (public-key) or both.


Alas, IKEv2 is also subject to the same sorts of well-documented MiTM attacks that are found in the wild when dealing with other flavours of VPN connections - preying on the need for Diffie Hellman-enabled crypto handshake procedures to exchange authentication data within the same channel as communications travels (shared certificates obviate this by making use of parallel channel authentication, without usually stating that in those terms).

And IPsec really doesn't have anything to do with "encapsulating packets securely." It can do that, or enable that to be done... but it also doesn't necessarily do that. Basically, it's a big crypto toolset: "IPsec is a suite of protocols for securing network connections." Which is not the same thing as "encapsulating packets" (which, as we we discussed above, isn't really encapsulation nor anything like it), not at all.

There is a price for this, in that the IPSEC server must have a fast connection to the Internet itself, and for bulk file transfers this will slow things down, because the data flows over that link twice in getting to you on the phone -- once in and once out. If you run a "Speedtest" over the VPN it'll be about half the speed of the raw connection


No, this isn't right at all.

Yes, if you're pulling data through a VPN "gateway" then those data go into and then out of the server - definitionally so, if you think about it for a minute. Where else would those data go? The data can't just magically jump from the server to someplace else - it goes across the NIC.

But this doesn't have anything to do with slowing down data, in any formal sense. Most servers have at least a 100 megabit link to the colo where they live, and nowadays gigabit is all but baseline (that's gigabit not gigabyte - sometimes referred to as "small b (bit) versus big B (btye)" - with one byte being composed of 8 bits, so a gigabit connection is going to be 1/8th the capacity of a gigabyte connection). So if you're pulling a file through a VPN network gateway with a gigabit connection, even if you've got a 100 megabit connection (that actually works at that speed) from your ISP, you're not going to hit that gigabit capacity limit or anything close to it (unless the VPN company has badly oversold the network, or whatever).

And besides, when we talk about a "gigabit connection" for a server hosted at a colo someplace, we're taking about a gigabit uplink and downlink - they're measured differently, and the NIC handles each differently. (don't ask me about the physical layer explanation - I have no idea, although I'd love to learn if someone wants to post up such information). So, in theory anyway, the server can be sending a gigabit "up" through the NIC simultaneously as a gig is coming "down" via the NIC into the server. All pretty routine, right?

It only goes weird when that gets conflated into an explanation for slow VPN connections - which have nothing to do with servers seeing traffic coming and going during routine VPN network topologies. Slow VPN performance is a more complex issue, and is far more often due to crappy configuration and poor network/server administration than with any hocus-pocus about server network interconnections.

Hand-waving mis-explanations of poor VPN performance have two bad consequences:

    First, it makes it seem like the word "VPN" magically makes stuff slow - which is utter nonsense in technical terms.

    Second, it takes the focus away from the real reason most VPN networks and services are slow: bad management, bad configurations, and bad decisions about how to run things. That's a far cry from some kind of profound technological limitations.


Now, the author of the article I've nitpicked here is not a technologist - he's (afaik) some sort of equities analyst. He's simply picked up these misunderstandings from elsewhere, and indeed they're all over the place once you start looking. Thus I want to re-emphasize that I don't want to be perceived as picking on him - overall he does a rather good job of making sense of some bits and pieces of VPN technology - far better than I'd do trying to explain his line of work!

As we continue this thread, we'll look to dig deeper and find examples of VPN misinformation that emanate from people who really should know better. That's where the problems really start, and it's where we need to look as we work towards putting discussions of VPN technology back on a sound footing.

Cheers,
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f


Return to “#cleanVPN ∴ encouraging transparency & clean code in network privacy service”

Who is online

Users browsing this forum: No registered users and 3 guests

cron

Login