Welcome to the inaugural article in the WAN Insiders Experts Series, where we talk with industry-leading networking executives about their insights into the ever-evolving world of connectivity and security. Our goal is to tap into their vast knowledge and experience to shed light on crucial topics that are shaping the future of networking: SD-WAN, SASE, ZTNA, edge networking, 5G, tailored networking solutions for verticals, and more.
In the first blog in this series, Abe Ankumah, VP and GM of the SASE business at VMware, had the opportunity to sit down for a conversation with Mike Chase, SVP of solutions engineering at VMware partner AireSpring. Their wide-ranging dialog covered the finer points of SSL termination, what your firewall vendor isn’t telling you, Chase’s thoughts on the VMware SD-WAN Client as the ideal way to get SASE software onto enterprise endpoints, and why you need IoT devices to do your laundry properly.
In this edited and condensed discussion, we left out the part about the laundry. Instead, we are focusing on Chase’s insights into the true potential of the VMware SD-WAN Client. Chase believes that the Client will play a critical role in making SASE work seamlessly for global endpoints and make adoption a no-brainer for any size enterprise.
Abe Ankumah: You’ve had a long relationship with VMware, right?
Mike Chase: I received my VMware Certified Professional (VCP) certification on the 3.x hypervisor years ago. I’ve been working with and implementing VMware technology for a long time.
Ankumah: Mike, you have made some interesting points about a flaw at the heart of SASE solutions. Explain some of your thoughts on SASE and where it needs to go.
Chase: When SASE started off as a white paper in August of 2019, written by three Gartner analysts, it was perfect timing. Then the pandemic, when SASE was really needed, delayed implementation of actual solutions. So we went through the pandemic and realized, oh geez, it’d be nice to have ZTNA [zero trust network access] because having a wide-open VPN tunnel to corporate leads to sharing viruses. Dodging real viruses and digital ones at the same time was interesting and ironic, to say the least.
For me, SASE comes down to a discussion I had two years ago with a guy I know who tests firewalls. He said that 98% of firewalls don’t see almost any of the traffic that goes through them, because 98% of your traffic is encrypted to the internet. The number one reason to adopt SASE, despite all the security scares and so forth, is that today your firewall is not doing anything.
When users think of a firewall, they think it means that if they go to a bad website, the firewall says, “Oh, you’re not allowed to go there.” What’s really happening is this: Let’s say you take an envelope, fill it with poison, and mail it to Mike Chase. The poison is equivalent to malware in a packet. The firewall is only saying, “Yes, the envelope is addressed correctly. It’s got postage. It’s addressed to Mike Chase.” It’s not looking inside the envelope to say, “If Mike Chase opens this envelope, it’s going to kill him.”
The firewall can’t see inside that encrypted “envelope” and say, there’s malware in there. Companies have ideological arguments about whose firewall is better, but the dirty secret in the industry is that the firewall is not looking inside that envelope.
Ankumah: And your argument is that SSL termination is critical, that decryption is important to see into those packets where the firewall can’t see.
Chase: The funny part of this story is that 10 years ago, everything that everybody told you not to do is now something to do. Ten years ago, your parents said, “Don’t jump into a car with strangers.” Now you have an app to summon cars and jump in there willingly with strangers, we call it Uber, this is a good thing.
Ten years ago, they said a man-in-the-middle attack is a bad thing. Of course, I don’t want somebody spying on my traffic. But now you’re telling the firewall to be that man in the middle, lie to you because it’s going to hand you essentially a forged certificate.
Ankumah: What’s the problem you see with the SSL certificates and how they are distributed?
Chase: When you first get a Windows laptop, for example, there are around 70 providers such as GoDaddy, VeriSign, or Network Solutions who issue SSL certificates. If you click the Windows button on your screen and type the word “certificate,” you’ll see “Manage Computer Certificates” and in there you can view the list of trusted root certification authorities. On your laptop, these certificates are updated through Windows Update. In an enterprise network, you must download SSL certificates to every firewall, because otherwise the firewall (that’s lying to you) is not a trusted host or entity.
The minute you turn on SSL termination—which is the number one reason to do SASE to begin with—and it’s not configured right, stuff starts to break. You try to log in to various applications and they are hung. You can’t web surf anywhere, your Outlook client says it can’t connect to the Exchange server, and all this stuff is not working on your desktop. And at that moment you realize, everything’s using SSL termination. I just didn’t know it.
Ankumah: And you’ve said that you see problems with getting SSL onto IoT devices too?
Chase: SSL termination also breaks many IoT devices, and there are millions of them out there. I noticed, wow, the IoT devices break because you’re never going to get the SASE software in there. You’re never going to be able to import a root CA level certificate so that it’ll believe the firewall who’s basically lying to it, handing it this false certificate that it wants it to use so it can see the traffic. Take the Nest thermostat for example. Is Google ever going to allow you into their appliance to have you put your SASE software on their Nest thermostat? No. But what you may not realize is your Nest thermostat is using SSL and encrypting its communications back to Google.
There’s no way to do SASE on an IOT device yet. The terms cloud web security and cloud access security broker are misnomers. People think these terms only refer to web browsers and they don’t think about IoT devices and many other apps/devices using SSL termination in your security infrastructure today into which there is zero visibility.
Ankumah: Getting SASE onto endpoints—laptops, phones, IoT devices—is a problem that enterprises need to solve if SASE adoption is going to catch on like they want it to, because they do need that extra security layer. It’s not getting SASE into data centers or the cloud, we know how to do that. How can we solve this problem?
Chase: There are really only three ways to get SASE onto your device today. Option one, install endpoint software on your PC/laptop, smart phone, etc. that tunnels traffic using SD-WAN or a VPN tunnel to a SASE gateway. Option two, point your web browser on your endpoint device to a SASE gateway using proxy settings. Option three is to enable your onsite firewall/SD-WAN edge to tunnel to a SASE gateway.
In my opinion, VMware needs to build all of this via option one: build certificate distribution and other features into the new SD-WAN Client, because it’s so easy to install. It’s SASE for dummies.
The problem with option two is that it will only cover your web browser for SASE, not the many other apps you have on the endpoint already using SSL. The problem with option three is that when you force the entire site into the SASE architecture and they’re not ready, everything breaks. My recommendation to VMware for enhancing option three is to use VMware’s existing SD-WAN Deep Application Recognition [DAR] engine in the VMware SD-WAN Edges to discover and weed out non-compliant devices and whitelist them automatically.
In the VMware SASE orchestrator portal, you’ll see a VMware certificate in the SSL termination list. I think mine expires in 2031. Here’s another danger: what happens in 2031? I mean, sure it’s eight years from now, but what happens when the music stops? And the music’s going to stop if all your SSL terminations from tens or hundreds of applications in your environment stop working in 2031 because you didn’t renew the certificate. And that’s not something you want to do with potentially thousands or tens of thousands of devices across a worldwide enterprise.
So a couple of things must happen. You must warn customers from the Orchestrator: “Hey, your renewal date is coming up, you need to redeploy this certificate or refresh it.” The second thing is that today it’s a very manual process for the customer or their MSP. They must manually segment their LAN into VLANs at layer two, VRFs at layer three, different subnets, etc., to put all this IoT stuff over on that subnet.
Even if I don’t intend to use the SD-WAN Client remotely, I could have a laptop that I bring to the office every day. The reality is that on that laptop, the Client software upon installation did all the heavy lifting when it was installed. It’s going to download that pre-made VMware certificate, it’s going to import it into the right certificate store, and then it’s going to update it when it’s time so that the music doesn’t stop in 2031 or whatever your expiration date is to refresh the root certificate.
I don’t think most people are going to find all the IoT devices. You’re going to end up playing a game where they break and then you must ask, “Oh, what IP address and MAC address is that?” It becomes a real burden. As I mentioned, IoT devices can’t be “fixed” because their vendors are never going to let you install your security endpoint software onto their device or appliance. You have to segment or whitelist these devices until their vendors become SASE aware, SASE compliant. That means protecting them with traditional security methods like firewalls, etc.
VMware should work with large IoT vendors like Amazon and Google to include and/or auto-update the VMware CA root certificate used with SASE to make the next generation of IoT devices much more secure and compliant. It’s a lot of heavy lifting, even though you’re rewarded with top shelf security thereafter—but at least we’ve got choices!
Ankumah: You became familiar with the SD-WAN Client software back when it was developed by Ananda Networks. What do you see as the main reason to use the Client, the benefits of it?
Chase: Ananda as a global SD-WAN client ignores BGP [border gateway protocol], which is the routing protocol of the internet. It’s full mesh. It cuts its own path across the internet using its Nitro gateways. Back around 2009, 2010, we discovered that was the only method to really accelerate internet traffic. Because when you follow BGP, any upstream carrier can put you on cheaper or less optimal bandwidth. And BGP as a protocol works on a vector basis. It’s looking at traffic from an administrative path, not really whether the network is the best way to travel.
The reality is that IPsec has been around now for almost 30 years. People were thirsty for something new. I mean, we get new cars, we get faster internet every year. We haven’t had a new remote access client in eons. So it’s very easy to tell people, “Hey, you need to update, how about something new?” They just instinctively want to sign up. The old access methods are like a junk car you’ve had for years. Of course, I need a new car for the faster internet. And that’s what this is.
Ankumah: You have made some good points in our conversations over the years about how software just needs to work, it has to be as simple as possible, or people won’t use it. And if people are not using their security software, it’s a problem.
Chase: With the VMware SD-WAN Client, you must approach it like you did with VMware Edge Network Intelligence. It was an add-on, you had to install the software crawler separately. Now it’s part of the VMware SD-WAN Edge box. I love that approach because it really does need to be a holistic all in one, not these separate products where you buy them and then you install software separately. The important point is when you roll out the software, it’s going to deal with the updating, with the endpoint. The problem is nobody’s an endpoint expert anymore. They just want it to work. Even if the customer never uses it, the software is in there. The updater that will run every once in a while will update that certificate and do what it needs to do.
Ankumah: You’ve founded a cloud company, you’ve run networking companies, you know the market pretty well. What or who do you see as the market for the SD-WAN Client?
Chase: They always ask you this question when you go into venture capital meetings: who’s your customer base? I say, for the VMware SD-WAN Client, pretty much everybody with a pulse. The answer is, you make it a product where everybody benefits from it. Never get hung up on the concept of “it’s only for this group.” Too many people do that. It’s got to be for everybody. Solve the real problem.
IPSEC VPN has been around for over 30 years creating encrypted point-to-point tunnels over the Internet without any improvement in the quality of service or enhancing a better path. VMware’s global SD-WAN client is a fully meshed, truly global platform that leverages AI/ML quality of experience [QoE] algorithms to deal with lost packets, jitter (variability of latency/delay) and other negative network conditions while virtually ignoring BGP—the routing protocol of the Internet—to plot its hop-by-hop passage across the Internet via its own packet slinging gateways, where its own metrics pick the most enhanced path from A to B. All of this while integrating ZTNA, 2MFA, SSO/SAML, and yielding a 10x better remote access experience truly worthy of its global name and inherent scale.