1️⃣ HTTP/3 Inspection on Cloudflare Gateway

Hello and welcome back to Cloudflare TV. I'm your host today, Corey Mahan. I'm the product manager on our Zero Trust suite. And I'm excited today to be joined by two awesome colleagues as we announce new innovations, products and partnerships at Cloudflare. Those two folks that you may see above to my right or below me is Ankur Aggarwal, PM for Secure Web Gateway, it's our product manager. And also Joshua Nelson, who is an engineer working on our Secure Web Gateway and HTTP 3 inspection in particular. So today you may have seen that we announced HTTP 3 inspection for Cloudflare Gateway, which is our Secure Web Gateway. And we want to talk more about that, go into the details of what it means for our larger Cloudflare 1 platform, turn it over to Josh to go into the weeds a little bit on how we thought about building it and some advantages there. But before we go too far into all of that, I'd love to level set firstly on Cloudflare 1 and Zero Trust and in particular, how the Secure Web Gateway fits into that. So to kind of just jump right into it, Ankur, what does that mean to you? What is Cloudflare 1? Kind of an overview, if you will. For sure. Yeah. So Cloudflare 1 really is our suite of products that enable our customers and administrators to protect their users. And it's really whatever that means to them and however that they want to execute that. So for some customers, that means like, hey, I want to add in robust security controls for my network. I want to do it at layer 3. Or it's for customers that want to embrace Zero Trust and they want to specifically start deploying security policies and filtering based on identity. So Cloudflare 1 really is the combination of those two concepts delivered through Cloudflare's global network. So we're able to provide this kind of robust security control at a network scale. And yeah, so it's that we have this large suite of products for and Cloudflare Gateway is just one of the pieces. So as we kind of go through it, I'm just going to go through a little bit of what Cloudflare Gateway is and then we'll dive deeper into it. So Cloudflare Gateway is a part of our Zero Trust products. It is basically the kind of robust policy engine for Zero Trust. So it has three major components. You have DNS filtering, you have network and HTTP filtering, and both of those are part of that secure web gateway industry term, really. And so essentially, customers are able to add in DNS filtering. Basically, they're able to filter out security categories, content, applications, however they like to deploy that filtering. And they're able to also get as granular deploying it to each individual user within their network or company. So something that's really neat about that is all of this is also tied into any sort of IDP they may be using. So they can use their identity provider of choice that they use today. And all of this is underpinned by our one.DNS service. So it's the fastest DNS resolver out there. It's delivered from all of our edge locations. And simply, this is just that filter on top of that already fast service. The other pieces of this now are our network policies and our HTTP policies. So with those, what we're able to do is we're able to replace on-premise VPN appliances by essentially proxying all of your traffic up to Cloudflare. So once all that traffic is proxied up to Cloudflare, we're able to apply all those kind of rich network policies in terms of, hey, I want to block usage, certain, again, content, applications, security categories. But now you're also able to apply things like, I want to use a Cloudflare tunnel to route towards internal services. So I want to be able to access an internal wiki, or I want to be able to even audit your SSH sessions. So what you're able to do is you're able to collect logs on everything that occurs with the SSH. Oh, I think we lost Ankur there. We'll kind of pick up where I think he was going with that around HTTP filtering, which is kind of the topic of the day that we're talking about, and what's new within Gateway around that. Before we go to... Oh, he's back. Sorry. There he is. Ankur, you cut out just for a second, or it could have been Josh, and I may have just been talking. Totally okay either way. Maybe jump back to, you've talked a little bit about on-ramp, so you're talking about proxy endpoints as well as tunneling out. Can you maybe pick back up there so everyone can understand? We have all this amazing filtering. We'll jump ahead back to HTTP filtering, but more of how do people get started? What's the on-ramp look like with this? Sure. Yeah. Because Cloudflare Gateway is a part of Cloudflare 1 and Zero Trust, we're able to offer one, the very well-known One.app, our work client as an on-ramp. So that's something you can deploy to any one of your major OSs out there and send us traffic. You can also deploy proxy endpoints. So these are typically deployed within, say, pack files to end-user machines. So we can apply those robust filtering policies to that. And two other things we have here are GRE and IPsec tunnels. So you can add these to the edge of your network, send us your traffic, and then we can, again, apply those same policies to that traffic. And lastly, because we have those DNS policies, something we're able to do is we're able to apply those in really any form that you send us DNS queries in. So you can send it IPv4, IPv6, DoH, and DoT. And the great thing about that is you're able to spin these up all on your own through the dashboard, through our API, through Terraform. None of this is, you don't have to get us on a call, send us an email. You can configure this all on your own. Awesome. Well, and all of those on-ramps kind of ways to connect kind of leads us back to the topic of the day. Firstly, I guess, before we go into H3, HTTP3, let's talk about the inspection of HTTP traffic to begin with, right? Like maybe jumping into why is that important? Why do we do that? I'll start kind of with you. Why does this matter? Why is an HTTP inspection important? Sure. Yeah. HTTP inspection is actually really interesting. So say if you were to just not even look at HTTP inspection, what are the tools you have available to you to apply filtering? Really, what you have is, say, SNI header for when the connection gets initiated, or you have a source and destination ports and source and destination IPs. That's it. That's all you got. Everything else is encrypted within that kind of TLS or encryption. So essentially, when we're able to decrypt that and look inside of those packets, we're able to start applying things like URL filtering. We're able to add tenant control. So something you can do is you can add a custom header through gateway, and you can make sure your users are only able to access your version of Slack or your version of kind of the G Suite, which is kind of something that's really important to our enterprise users. A few other things we have are download control. You can prevent users from, say, uploading files or downloading files from certain domains, websites, or kind of blanket apply those policies. And other kind of products that we have are also enabled through that inspection capability. So you have things like remote browser isolation. So a lot of customers tend to deploy this in kind of two fashions. They want to, one, go to, say, specific domains and say, I want to always have these behind RBI because I want to make sure none of the information is able to be, say, copied or downloaded or printed off that page. Or we've seen customers deployed in scenarios where they don't have enough information to say, I want to for sure block this. And it's more so, I just want to make sure my user is safe. I want to make sure their machine is safe. I just want to make sure it's in a remote browsing isolation. Again, it's a browser that's rendered on our edge. And then we just send the draw commands down to the user. So nothing, no JavaScript, nothing is executed actually on the end user machine. The last two things I want to touch on here are just DLP. That's something we announced this week. So we'll have robust kind of DLP profiles and support there to essentially prevent and apply them essentially within those HTTP policies. And then for inline CASI, I'm actually going to throw that to you, Corey, to kind of talk us through a little bit about CASI. Yeah, I think, awesome. No, totally. Thank you. I think that it's a super cool aspect of being able right when we can inspect HTTP traffic, we can apply policies, access control, various means to that traffic. We can shape it if you want to call it that to a degree. So allowing certain actions and blocking certain actions, uploads, downloads, et cetera, all from that idea of blocking it on the wire, that treating the inline nature of stopping it before it happens. And then as we talked about in other segments around the API version of that, but with Gateway, we're able to solve those inline CASB use cases because we are just that on the wire in line to a degree, although that term is moving around as we kind of go. So that is super exciting. Thank you for the overview of kind of like the HTTP inspection. We do some inspection today, right? There is inspection of like, we'll call it H1 and H2. What kind of traffic are we capable of inspecting? What does that mean? And then let's jump to what we're doing today with H3. Sure. Yeah. So with the way kind of just the Internet protocols were built, like, of course, you started with H1 and then years down the line, they introduced H2. H2 gave you the ability to have like concurrent connections being built. So essentially it could just load pages a little faster, a little bit more efficiently. But of course, those were still kind of built on TCP, still built on kind of these ideals of the Internet that maybe weren't the most cutting edge. And so we essentially talk about a little like how H3 improves on H2 and H1. Sure. Yeah, actually, this is perfect. So with HTTP3 inspection, we can kind of just dive straight into why the Internet is moving. So just a quick note of like, HTTP3 is starting to quickly become kind of the major thing that's being used out there by web pages and domains. It's actually up to just 25% of the Internet already. It's something that cloud for customers today can even just enable out of the box on their reverse proxy zones. So there's a lot of gains to be had here. And yeah, I would love for you to kind of take us through the underpinnings of it, Josh. Yeah, absolutely. So the way HTTP1 works is you have like one connection that goes out to a server, it sends you back a response. But when you visit a website, you usually load many different files, they have JavaScript, CSS, all sorts of things. And so you end up making like a bunch of requests in a row, right? And because they're all serialized, it takes a long time to load the web page. So the improvement HTTP2 makes is it'll send multiple requests at once. First, it needs like the first page to know which files to load, and then we'll send out five or 10 or 20 requests at once and get those all back in parallel. And that works pretty well. The problem is if you have like a slow or an intermittent connection, or sometimes the Internet goes out for a few seconds, then if you lose like even a single packet from any one of those responses, it'll delay every single other response to get back. And so very small interruptions in your connection have a really big impact on how slow you load the web page. The improvement that HTTP3 makes is rather than blocking the response of all those files on any packet, you can block just the single file that you had the interruption in and send all the other files back in parallel while waiting for that one single file to load. And so that's the reason that HTTP3 is built on UDP instead of TCP, because the different underlying mechanisms are what we're doing. Yeah, and that definitely helps with the resilience of those connections too, because you're able to drop that single packet, you only send that single packet over again. It's not having to rebuild the entire thing. So with that kind of, like, say structure with HTTP3, there are a couple things also of how different protocols are used to kind of enable that. Could you walk us through how some of that is kind of implemented for HTTP3? Yeah, so like I said before, H1 and H2 are built on TCP. And TCP is like at the kernel level, the kernel will ensure that you get data reliably from the network, and it'll ask the other client to retry if it doesn't get the data. With UDP, you're responsible for making sure that you get the data reliably. And so we actually had to help standardize a new protocol at Cloudflare and for the whole Internet called QUIC. QUIC is built on top of UDP. It gets you that reliable transmission, but in parallel. So you can have multiple what are called streams that are on the same connection, that are all getting you data reliably, but in parallel without blocking on one another. And we're pioneering QUIC here at Cloudflare. Yeah, and with that kind of QUIC support, what's really neat about one working at Cloudflare is not only are we just kind of, say, picking it up and adding it to gateway, we've done it in other areas, in other venues. Can you talk a little bit more about other uses we had for QUIC? Sure, absolutely. So one of the other things Cloudflare does is we're one of the backbones for Apple Private Relay. And so Apple customers can send traffic through their phones, through Cloudflare and Apple, and it will hide their IP address from Cloudflare, and it will hide the website they're going to from Apple to get additional privacy. And the technology for doing that is built on the same technology we use for H3. It's built on top of QUIC, and it gets you that reliable transmission while still being faster than if we'd just done TCP. That's awesome. Super cool. Well, just talking about QUIC quickly, Josh, as you've got to work on this, what would you say is the coolest thing you've discovered through building out QUIC, right? We're talking about helping shape the Internet and build a better Internet. This is doing that. For you as an engineer doing this every day, what would you say is either the coolest or most exciting thing working in and around QUIC? Oh, man. I think the coolest thing is I get to work really closely with the people who are helping build the standard, like Lucas Fardew and other engineers at Cloudflare. And they get to tell me about how the standard works, and I'm helping improve libraries for other people to use QUIC, and that's really fun. Awesome. And then just to what was the coolest bit, what about future work or jobs? Curious on what this looks like going forward or things that come up using QUIC or building upon what we've already established and continue to grow here? Sorry, what's the question? How does this build on our existing stuff? Yeah, so I can take this one. So basically, what's neat is once we have a lot of these concepts within Gateway, we can actually then pivot these towards other components that are within Gateway itself. Because one, we have a little bit more experience on the team directly with working on it, and two, once you kind of have it within some of the close components, it's kind of easier to start porting over to the other ones. So some of the things we're looking at in the future is kind of doing DNS over QUIC, and then also integrating this in with kind of our Connect proxies. So enabling it for all those sets of customers, so you no longer have to or are just limited to doing it on, say, H2. So those are some things we'd be looking to in the future, and we're really excited to actually get H3 Inspection out there. We know it's not available right today, but it's actually just around the corner, and we'll email out all of our customers once it's available. Also, it's available for all customers, all plan types, free, pay-to -go, enterprise, everyone. This is something like we don't want to limit to just, say, a specific set of customers either. This is truly a part of offering a true secure web gateway. This shouldn't be limited to just a certain subset of customers. Awesome. Super exciting to hear it'll be available to everyone. I think that's super exciting, whether you're a team of five or a fortune five. It's out there and available for everyone to pick up and use, which is super cool. Awesome. So I know we've talked about HTTP, which I've got traffic and inspection. Thank you, Josh, for the history on H1 and H2, and now we're at H3 with QUIC and all the exciting things there. Getting started with Gateway, we'll talk about where teams can go with the wider Cloudflare One platform and suite, but specifically for our secure web gateway. Maybe, Ankur, over to you, just how do teams get started today? I know we've talked about this before, but teams of 50 or less free to sign up. Go look at it yourself. What would you suggest after they've signed up? What's the first thing in gateway land you should do? For sure. Yeah. So we've actually put together some robust getting started guides within our dev docs, and it depends really on how you want to deploy this. We always suggest you just onboard onto gateway and start sending your traffic through us. So that starts with DNS. So as soon as you configure the clients on your end machines, you can start seeing the analytics pour in for all the sites and domains that are being accessed, and you can start applying those robust security policies as well as any sort of content building policies. And then on the secure web gateway side of things, you can, of course, do the exact same thing. Make sure you add in those do not inspect policies to get impacted by cert pinning. It's kind of a nature of being a secure web gateway. And then add in those security policies to say block malware, block DNS tunneling. Geez, all these things. I just like hitting me all at once here. And then also what's really neat is you can also just flip on EV scanning too. So all of these getting started guides are available in our dev docs. Go sign up for a plan, get started, and we would love to start having customers utilizing these robust security features. Awesome. Super cool to hear. Easy ways to get started. And then as mentioned prior, once they get started with gateway just around the corner, this is available to them as well, regardless of the plan they've set up and where they're at in their journey. Super, super exciting. Josh, Ankur, thank you very, very much for all of the conversation today, the details on H3 and where we're going from here. Thank you to everyone watching and tuning in. We'll return to our regular schedule of programming as we wind down the week for Cloudflare One Week. And thank you for everyone out there watching today. All the best. Everybody should have access to a credit history that they can use to improve their situation. Hi guys. I'm Tiffany Fong. I'm head of growth marketing here at Kiva. Hi, I'm Anthony Brutus and I am a senior engineer on the Kiva protocol team. Great. Tiffany, what is Kiva and how does it work and how does it help people who are unbanked? Micro-lending was developed to give unbanked people across the world access to capital to help better their lives. They have very limited or no access to traditional financial banking services. And this is particularly the case in developing countries. Kiva.org is a crowdfunding platform that allows people like you and me to lend as little as $25 to these entrepreneurs and small businesses around the world. So anyone can lend money to people who are unbanked. How many people is that? So there are 1.7 billion people considered unbanked by the financial system. Anthony, what is Kiva protocol and how does it work? Kiva protocol is a mechanism for providing credit history to people who are unbanked or underbanked in the developing world. What Kiva protocol does is it enables a consistent identifier within a financial system so that the credit bureau can develop and produce complete credit reports for the citizens of that country. That sounds pretty cutting edge. You're allowing individuals who never before had the ability to access credit to develop a credit history. Yes. A lot of our security models in the West are reliant on this idea that everybody has their own personal device. That doesn't work in developing countries. In these environments, even if you're at a bank, you might not have a reliable Internet connection. The devices in the bank are typically shared by multiple people. They're probably even used for personal use. And also on top of that, the devices themselves are probably on the cheaper side. So all of this put together means that we're working with the bare minimum of resources in terms of technology, in terms of a reliable Internet. What is Kiva's solution to these challenges? We want to intervene at every possible network hop that we can to make sure that the performance and reliability of our application is as in control as it possibly can be. Now, it's not going to be in total control because we have that last hop on the network. But with Cloudflare, we're able to really optimize the network hops that are between our services and the local ISPs in the countries that we're serving. What do you hope to achieve with Kiva? Ultimately, I think our collective goal is to allow anyone in the world to have access to the capital they need to improve their lives and to achieve their dreams. If people are in poverty and we give them a way to improve their communities, the lives of the people around them, to become more mobile and contribute to making their world a better place, I think that's definitely a good thing. My name is Justin Hennessy. I'm the VP of Engineering at Neto. Okay, so I understand Neto is an e-commerce platform based in Australia. Tell us a little bit more about it. Neto is a omni-channel sales platform for retailers and wholesalers. So essentially what it allows us to is enable the retailers and wholesalers to sell their products in multitudes of sales channels. Tell us about the importance of automation in your business. I came on board as the lead automation engineer. So I think automation is key to anything in this day and age. Like if you're not looking at ways to automate the low value work and then put your people in the high value areas or high leverage areas, I think you're just going to get left behind. So as a technology company, obviously it's critical for us to make sure that automation is at the core of what we do. When did Neto begin working with Cloudflare? So in the beginning, when Neto was looking to migrate from an old cloud provider, we also wanted to improve what we call our go-live flow, or our onboarding flow for merchants. And a big part of that was obviously provisioning a website, a custom domain name and a custom SSL certificate. Requesting and getting granted that certificate in the old process took two domain experts full-time. It was a very lengthy and technical process which took, you know, could sometimes took up to two, three weeks. So you can imagine, you know, a customer who's itching to get online, that kind of barrier, you know, presents a pretty big problem. So what Cloudflare enabled us to do was to literally automate that onboarding or go-live process to almost a one-click process. And it also allowed us to diversify the people that could actually do that process. So now anybody in the business can make that, you know, set a customer live with a very simple process and it's very rapid. So that's where we started. What are some of the security challenges you face in your business and how are you managing them? Any online service has to take security very seriously and at Neto, security is job zero. So we always bake in thinking and process and tooling around security. So what Cloudflare does for us is literally gives us a really good protective layer on the very edge of our platform. So things like DDoS mitigation, web application firewall protection, all of that obviously is then translated into a really solid base of security for all of our merchants as well. Security is obviously front of mind for Neto as a business and online e-commerce presents a lot of security challenges. So denial of service attacks, cross-app scripting, we have automated attacks that are trying to find exploits in our forms and our platform generally. So prior to having Cloudflare, obviously we had measures in place, but what we've gained from Cloudflare is a consolidation of that strategy. So we are able to look through a single lens and we can look at all of the aspects of our security for the platforms. And I think it's probably safe to say that now more than ever, a good online strategy is crucial to success.