SSL VPN

SSL VPNs had their time. But that time has clearly passed. Connecting to corporate network to connect to a cloud application doesn’t make sense.

From the “Top 10 Signs Your Network and Security Design Might Be Far Behind” Series

I believe most out there would consider me to be an expert on remote access. After all, way back in 2003, Nortel, having found a paper I had written that was published by the SANS Institute on the topic of building a secure healthcare extranet, sought out my assistance with helping them as they were looking to build an appliance that could meet my needs. After a bit of work, their very first SSL VPN was shipped to me for testing and validation. That was just a black box with no real markings on it, not yet beta quality.

Not too long after I had managed to find an even more capable product, which was the Neoteris SSL VPN. This eventually became the Netscreen, then the Juniper, and now the Pulse SSL VPN. After forming a great partnership between Neoteris and the very large company I was working for at the time, I made my move over to Juniper Networks. And for the first two years I covered the America’s as a product specialist for this great emerging technology of the time, after which I was recruited to the position of Sr. Product Manager. So for my last 5 years at Juniper I was flying from Atlanta to San Fransisco pretty much every week, doing all I could to help keep that product in the lead position. Mission accomplished!

The end of the SSL VPN party was approaching…and we could all see it

By 2012, change was in the air. Gartner had long since stopped with their SSL VPN Magic Quadrant, mobile was the new buzzword, and I could see the decline in general interest from my SSL VPN Insider blog analytics.

As what was really my last blog entry for that site, I wrote about how SSL VPNs would soon die off. Not as an obituary, but rather as a celebration of all that had been achieved. From my vantage point I had witnessed story after story of how millions of workers were now open to delivering value from virtually anywhere. It was exciting. It was historic. But it was also clearly coming to an end.

And the use case / persona that came drove this was essentially this one:

Mike is a millennial (2012, so we weren’t talking about Gen Z just yet) and can pull out his phone to access e-mail whenever he wants. Push e-mail works just fine, so there is no need to VPN in to make that work. In fact, no one can really imagine the pain if they had to virtually connect to a network in order to access something so commonplace as e-mail. Because if Mike had to do that, his battery would drain much faster, and the overall user experience would suffer.

Which one would you prefer, after all? Option 1 or Option 2?

  1. Open VPN App —> Connect –> Authenticate –> Open e-Mail App –> Hit Sync –> Watch Battery Drain –> Receive e-Mail –> Quickly Disconnect (to save battery life)
  2. Just check email App

If we can solve security for one application, like e-mail, then why can’t we solve it for all of them?

Solving the Identity Problem…the Right Way

Remote access is really just an identity problem, where we just need to positively address 3 key questions:

  • Can I trust the user?
  • Can I trust the device they are on?
  • Can I trust the resource they are connecting to?

Pretty simple, right? It actually is…now. That wasn’t necessarily the case a decade ago, which is largely why the SSL VPN space was oh-so-hot. That’s also what I blogged about back in 2012, noting that while nothing on the market existed at the time, it would surely come.

Trusting the user is now handled quite well by SAML 2.0, while the device they are on is largely handled by device fingerprinting – thanks to an app that just needs to get loaded on their devices, while the resource they are connecting to can be isolated so much that it is completely dark both on the Internet as well as our intranet?

The bottom line is that the vision my colleagues and I had even before 2012 has now become a reality. Specifically, Zscaler’s Private Access does pretty much exactly what that prior blog piece had prescribed (though I do recall saying something about using IPSec in conjunction with IPv6 as a possible transport rather than TLS/SSL).

Please, no buyer’s remorse!

So, if you are even thinking about renewing that SSL VPN…please think twice. They are worth less with each passing day and may not meet your needs even now. It’s even quite likely that a year or two from now you would have buyer’s remorse. Hang something to memorialize it on the wall if you must (I did), but now is the time to look at the new way of connecting users to their applications. The chapter on SSL VPNs is now closed, relegated to history.

Kevin Peterson - Junos Pulse SSL VPN

Kevin Peterson is a co-author of the leading SSL VPN technology, as well as serving 7 years at Juniper Networks leading the SSL VPN product line.

 

%d bloggers like this: