🔒 Radar: helping build a more secure Internet

All right. Hello, everyone. My name is Stanley. I am the Radar Product Manager. And we've got a new product for you all on Security Week this year. Hi. And I'm Sofia. I'm one of the backend developers in radar, and I worked a lot in this new product that we're going to cover. All right. Yeah. So the new product is the Radar URL Scanner. We're excited to share it with you all. Um, I'll put it up for you guys to see right now. Right, so this URL Scanner is a product for everybody to enter in a URL and get back a report on all the technical information you might be curious about for a website. So, for example, if you're interested in doing some type of security investigation or you're an engineer and you want to deep dive into the technologies that are used or see what's under the hood of a page, this is a perfect tool for you. So, as you can see, this lives inside Radar. So just visit radar.cloudflare.com and you'll get here by going to slash scan. And when you enter in a URL, you'll get taken to a report that looks something like this. And so here you'll see we've done a scan for blog.jgc.org. FYI, JGC stands for John Graham-Cumming, our venerable CTO. Um, and the first thing that you'll see in the report is a summary page of all the information that we have. So Sofia, do you want to maybe walk us through some of the information in the summary and then we can, let's go through... Yeah, let's go. So here in the in the first section, we have the screenshot, of course, and then we have like the what kind of assets did you see? So how many JavaScript scripts did you load? How many CSS stylesheets did you load, how many fonts, images, links? And then we also have cookies and and how many JavaScript variables, the non-standard JavaScript variables. So that's, that's showing how many, what kind of assets does this site load? And then we have the technology section where we analyze what kind of technology does this site use. And we see that it has some, some advertising, some some blog. We can see in detail in the technology category, but that's the summary of the tech stack that this site uses. And then we have like the small stuff like what's the domain that it visited, what's the categories right now, though this one is not categorized, but some will show technology, others will show whatever, the current Radar category. And we also have the rank, which is a which is the rank buckets right now. It's not... it's basically the rank bucket. And then if you want more details about the rank bucket, just click on that question mark. And then we have the network stats where we see in order to load this page, we made 82 requests and about four megabytes were transferred. And in total it's a bit more because it would include the headers and stuff. And the the security analysis, we didn't find any phishing risk, which is good, it's JGC's blog, and we didn't, there weren't any Content Security Policy header sets and we loaded about 13 certificates when loading all those 80 more or less requests. So yeah, so that's a quick, quick summary of it. Yeah. Okay, so the first tab we have is the Security tab and it looks like we've got three different sections. So we've got phishing, content security policy, certificates. Um, so this is an expansion of that security section that Sofia just walked us through. Um, but it looks like so, yeah, it looks like there's no phishing, like you said, no CSPs but looks like we have a few certificates. Exactly. We see the hostname it was issued for, the issue date and the expiry date. For the phishing, we actually run that. We actually run that on websites when when you do the scan through through an internal phishing detection tool. And so you can see whether a given site is a is a phishing danger or not because we actually run it when you do the scan. And we also show what content security policies are set, especially headers that say that help protect sites against a cross-site scripting attacks where we where the site owner can basically say, Hey, only load the images that come from from the same hostname as my site, for example, or only load scripts that come from, so if the hostname is blog.jgc.org, if they were set and the if they were set to self, for example, the browser would only load images that were hosted on the hostname blog.jgc.org. So that's, that's what those headers can do and can help to protect a website. Very insightful. All right. And then next up is cookies. So I think a lot of people these days are familiar with the idea of cookies. But maybe, you know, let's see, we've got a couple cookies that were loaded in the blog post. How about we run through some of this? Yeah, so basically cookies are a way for a website to store, well like it says there, a small text file. So, for example, if you have like a cookie banner you say yes the first time and then you, when you revisit that site, that cookie banner no longer appears because it has it has stored the cookie saying, Hey, this person has already accepted that, that we can store cookies. And so you don't have to like click the cookie banner every single time. It actually remembers user preferences and tries to offer a more personalized experience, which is basically what it says there. And yeah, we see there the the image just went a bit fuzzy, but we see there the cookie name, the value, the domain it belongs to. This is, this differentiates between search first party cookies set on the domain that we're actually visiting and third party cookies. And we see when it expires, some cookies are for the session. So they, they disappear. They're they're deleted when you close the browser and and other cookies are more persistent and you can see the expires there and also we can see if the cookie is secure. What that basically means is that if you try to load this site, for example, through a through HTTP protocol, if the cookie is secure, it won't be, it simply won't be sent. So no one can look at the value in that cookie. If it if it's secure, false, it can actually be sent over the over the plain text http protocol and the HTTP only tab just says Hey, this cookie can't be seen by JavaScript running in this page. So it's it's a dumb cookie only, scripting languages, client-side scripting languages can't access this cookie, which is good when when normally websites have lots of of of external scripts that they also put on their page, analytics and stuff like that, and they may not want their users' cookies to be available to those third-party scripts and that's one that can be used to let the browser know, Hey, don't show, don't show the, the cookie value, the cookie information to the client-side JavaScript running. Awesome. Yeah, great explanation. Let's move on to technology. So this is a really fun one, I think. Yeah, I agree. I agree. It's it's really cool to see the tech stack that that site used. It's a it's a looking glass that's that's really interesting to see. So we see that we we detected the use of Google AdSense, Blogger of course. JGC does use Cloudflare CDN, which makes sense. Thankfully. And he also uses the third major version of HTTP which is the the newest and greatest, let's put it this way. We also detected Python and we also detected a service Proxy. And we also detected the HTTP Strict Transport Security policy, which basically says, Hey, if you try to visit this site in HTTP, you should be, you can't. You can only, you can only visit it using HTTPS. We actually might see it at the top. Can you, can you go up Stan? And yes, exactly. You see that in the submitted URL it it uses HTTP, but the actual URL that the page visits is HTTPS and that's what that, that https policy does, basically. Very cool. Very cool. And since we're in Radar, I think it'll be really interesting for us once we get a lot of scans going, um, post-launch to be able to aggregate and see what are some of the trends and insights with those like technology stacks across the Internet. Yeah, I agree. It will be really interesting once we show that in Radar. Yeah. Okay. And then the Network tab. So it looks like we've got HTTP transactions. So, yeah. So these are all the requests that the website made when the browser was loading the page. And here we see the first column is the method. Normally when loading JavaScript and stylesheets and stuff like that, it's always GET post is when when you actually submit the form. So you're sending it, sending a message in a comment form. That's not the case here. Here it's mostly assets. Mostly, I do see a post there which is Challenge platform. Anyway, but yeah, that's, that's the message, the actual URL of the requests, what was the status. Normally when when it's, when the page is loaded with success, status will be in the 200 range and the most common is is 200 that we see there. What is the protocol? So HTTP one, http two, etc. And that was the asset type. Was it an image? Was it a a plain text? Was it html ? Was it JavaScript? So that's basically was it a stylesheet, which is the last one. So that's basically what we're showing there. And then how much did it, what was the size of it? How many bytes did you transfer over the Internet? Yeah. And so, so you have the quick summary. So if you go to to some sites, you'll see that they have much more requests than this. And, I don't know, sites like newspapers and stuff like that, you can see that they load many more requests. So, so so you can actually see the differences in in how sites are built. Yeah. Which I think is really cool. Yeah. And I think it's interesting that even for a simple blog like this one, it's already close to 100, you know, requests. And so definitely if you go to more complicated sites, there will be a lot more. A lot more. Yeah. Yeah. I think the web has changed a lot in the last few years. And even simple sites right now, they just do a lot of requests and yeah that's that's just the web nowadays. And yeah, so we also show here the DNS records that we found. So we have, so blog.jgc.or has, it can resolve to three, three different IPs. That's the of IPv4 which is a type A, and also three different IPs quad A, which is IPv6. And that's what we show. And we also show whether DNSSEC is, is enabled. Yeah. And yeah, which is a more secure setting, basically. And John is having it all enabled, which is good. Yeah. Yeah. During some of the testing I remember not every site we looked at had DNSSEC but they really should. No, no, no. Yeah. I mean as time goes by it will become more and more common. For sure. Yeah. Alright. And then, now we're looking at the DOM, Document Object Model. So, yeah, here we look at the actual HTML of the page and we try to find the outgoing links. So what I mean by that is sites that link to another site, links that link to to another site. And then we try to show, okay, what is the link and what was the text. We still have to improve, I think, because we don't always detect the text. But well, in general, we unfortunately we have lots of cool stuff we can do, we can do here and that's one of them. But yeah, we see all the links that that this the site has. And yeah, this, this basically gives us an idea, so newspapers might have a lot of outgoing links or sites like I don't know news.ycombinator.com will have a lot of outgoing links. Other sites are more internal facing and they have more links linking to their internal pages. Shops and stuff like that probably will fit that category. Yeah. Yeah. And here we have the global JavaScript variables here. We only show the ones that aren't part of the default standard variables. And this is interesting just because it gives us a clue on also what kind of tech stack it uses. And so, so does it use React? Does it use other stuff like that? React frameworks. And it's also it's also a view on how the the site is built and it can also in the future serve as as a as a signal to, it will be used in phishing and other and other kinds of security issues, detection, basically, which we which we hope to, to improve a lot, I think. For sure. Yeah, definitely an area we'll want to expand into more. Then looks like we've got the HTML body as well. Exactly. We see that it was done by Awesome Inc. and by the designer Tina Chen. That's cool. Nice. Yeah. And this will all be here in case somebody wants to dive in deep. Yeah, exactly. And the final one is the performance tab. Yeah. Here we, we, we, we basically show how fast the the site loads for us. Um, so this is of course not a, not a lighthouse sort of score or anything like that. We're just showing hey this site in this scan at this time loaded this fast for us. So we see that domain lookup start started at 72 milliseconds and then we see the TCP connect start and then we see the TLS connect start and then we see when when the TCP connect ended and then we see when the actual request started, which right next when the response started coming. This is just for, for the main page, of course, not for all the assets, just for the main page. And when it ended. And then even though we already have all the page, it can sometimes take a while until sites become interactive because they're running all these JavaScripts, all these CSS and and and they're styling the web page. So um, it's sometimes when you are actually loading the site, but you can't actually interact with it. So that's what that, that DOM interactive event shows. And then the DOM is actually complete it's everything been analyzed. And yeah, so that's, that's the processing phase. And then we have the load phase and that's basically it. We want to do a lot more in here as well. So expect news about this somewhere. But you, you can. Yeah, definitely. I think there's a lot of visualizations that we can do for users that will make this information a lot more digestible and familiar to a lot of people. So yeah, um, I think we'll be excited to do a lot of enhancements in the future on, on all these tabs, but also the, the performance one. Yeah. Exactly. So that's all the tabs that we had at launch. Sofia, so now that we've gone through this process of designing and building and everything, I'm curious, um, what to you was the most exciting part about, about building this, this new product? It was really cool to, to see how much we could build on top of Cloudflare's stack because this is all using Cloudflare's products. I mean, classical solution for this would be having a having a set of VMs or containers and then and then running, running Chrome browsers on it and stuff like that. So since we're using all of Cloudflare's products, so we're using Workers, so Workers are on the edge. So the idea for this is that so you're, you're in San Francisco or I'm in Portugal, I don't have to contact a server located in San Francisco. I can, I can contact a Cloudflare Worker that, that that is running in Portugal's data center . So this, the whole experience gets quicker, which is actually really cool. So we're using Cloudflare Workers we also are using Cloudflare Queues which is a beta product built on top of Workers. So this is basically why you see when you start a scan, the initial state you see is queued. Yeah, exactly, because it went in the queue and then we're just waiting for until, until we can start processing it. So that's using Cloudflare's product as well. And then we built it using on top of the Remote Browser Isolation product which is in the, in the Zero Trust product line. And, and that's what we're using. So what this allowed us, instead of having like to manage a set of, a fleet of, of of Chrome browser instances, this is all abstracted away from us. I didn't have to worry about any of it. Basically, I basically just just called out to that and said launch and I don't have to see a as this browser crashed, do I have to kill it? All of that is abstracted away and don't have to worry about it. So that was really cool and that's why we ended up doing this in a in a relatively short time, I think, because, yeah, we're just building on top of just building stuff on top of Cloudflare and it's, and it's been really interesting to see how far we can take this. It is a really cool experience for me actually. Nice. Love it. Building Cloudflare on Cloudflare. Exactly. Awesome. Okay and about you, Stan. What's it like from a product standpoint? What do you think would be, is really interesting right now? Right now, I think. Well, I think the security tab being able to provide people a phishing scan is really cool. Um, I think that the technology stack seeing, being able to peek into other people's websites is also very interesting, especially because it's not something that is very easy to get a sense of, right, when you look at somebody's website. Um, this just kind of pulls it front and center. Um, and then, oftentimes I am kind of a nerd, so seeing stuff like DNS records just pulled up here so that I don't have to like hop around and like Google search or, you know, do all these other steps to like, look up this under the hood information. It's just like all here is really fun for me. Um, and sometimes I get, uh, and this is just like a very simple thing, but the fact that we differentiate between like a submitted URL versus the URL that you actually redirect to. So sometimes I go to a website and I see like one of those short links. Um, but I kind of just like seeing the, the actual link because I want to know where I'm going. So sometimes I just don't click on links because they're short links and I'm annoyed at those. But here it just like unwraps it for you. Um, and so I get that report for free, but I also get to see the, the full full URL and just decide if I want to go there. Um, so yeah, the little things. Um. But yeah. I actually, I actually hadn't thought of that, that someone would, would, would use this. It makes total sense, but it just hadn't occurred to me that that's a short URL-like use case. Yeah, it makes total sense. Yeah. Yeah. A weird user right here. Yeah, probably not. That's cool. Yeah. So in the future, Sofia, you know, we have this unique opportunity where, you know, you're the engineer, I'm a product manager. Like, what do you want to build next, right, for URL Scanner? Like what, what is top of mind for you? Yeah, I would really like us to go deeper in the security aspect of it, so I think we can do a lot more in there. So that's, that's, that's one place where I think we can, we can improve a lot. And also next or, or parallel it doesn't really matter, in the performance tab. I think we can also improve that a lot. So those are the two I really want us to to to improve on. I mean, we can do lots of cool, cool visualizations in the Chrome and the security, I think we can probably run more tests and, and see how safe a URL is for a user to visit. Nice. Nice. Yeah. I think those are really great ideas. I think another thing that we could do is right now when you're doing a scan, everybody, we kind of funnel everybody into this user interface so that we do one scan at a time. And I think for people that really want to run a lot of scans because I think there are a lot of interesting use cases for that, especially when we're talking about security use cases. Um, it'll be really interesting to open up API level access and to help people do even like maybe recurring or you know, right now all the scans are public, right? That's why when you, if you go to the scan, you see recent scans here. Right ? And so all of these are just scans that everybody's been doing. But, you know, I think there's lots of reasonable use cases where you're like, Oh, I want to run my own private set of scans where I can have access to them and and they're not just, you know, floating around on a public URL. So, um, you know, being able to give people more control over the amount of scans that they're doing and all that is really exciting to me because we get to help more people do more scans. Yeah, yeah, I agree. Yeah. And, and once we have private scans, I think there's a whole lot of use cases that open up as well. Um, so yeah, the API release is going to be really, a really interesting next step. Awesome. Awesome. Well, um, thanks everybody for joining. We're super excited, as you can tell, about this new URL Scanner product. Um, you know, again, you can visit it at radar.cloudflare.com/scan. Um, and if you have any feedback, definitely let us know. We're on Twitter at Cloudflare Radar. And if you want to give us like a lengthy email about all of your thoughts about this product or requests and whatnot, feel free to email us at [email protected]. Thanks, everybody. Have a great day. Thanks. Bye. The real privilege of working at Mozilla is that we're a mission driven organization. And what that means is that before we do things, we ask what's good for the users as opposed to what's going to make the most money. Mozilla's values are similar to Cloudflare's. They care about enabling the web for everybody in a way that is secure, in a way that is private and in a way that is trustworthy. We've been collaborating on improving the protocols that help secure connections between browsers and websites. Mozilla and Cloudflare collaborate on a wide range of technologies. The first place we really collaborated was the new TLS 1.3 Protocol, and then we followed that up with QUIC and DNS over HTTPS and most recently the new Firefox Private Network. DNS is core to the way that everything on the internet works. It's a very old protocol and it's also in plain text, meaning that it's not encrypted. And this is something that a lot of people don't realize. You can be using SSL and connecting securely to websites, but your DNS traffic may still be unencrypted. When Mozilla was looking for a partner for providing encrypted DNS, Cloudflare was a natural fit. The idea was that Cloudflare would run the server piece of it and Mozilla would run the client piece of it, and the consequence would be that we'd protect DNS traffic for anybody who used Firefox. Cloudflare was a great partner with this because they were really willing early on to implement the protocol, stand up a trusted recursive resolver and create this experience for users. They were strong supporters of it. One of the great things about working with Cloudflare is their engineers are crazy fast. So the time between we decide to do something and we write down the barest protocol sketch and they have it running in their infrastructure is a matter of days to weeks, not a matter of months to years. There's a difference between standing up a service that one person can use or ten people can use, and a service that everybody on the Internet can use. When we talk about bringing new protocols to the Web, we're talking about bringing it not to millions, not to tens of millions. We're talking about hundreds of millions to billions of people. Cloudflare has been an amazing partner in the privacy front. They've been willing to be extremely transparent about the data that they are collecting and why they're using it. And they've also been willing to throw those logs away. Really, users are getting two classes of benefits out of our partnership with Cloudflare. The first is direct benefits. That is, we're offering services to the user that make them more secure and we're offering them via Cloudflare. So that's like an immediate benefit the users are getting. The indirect benefit the users are getting is that we are developing the next generation of security and privacy technology and Cloudflare is helping us do it and that will ultimately benefit every user, both Firefox users and every user of the Internet. We're really excited to work with an organization like Mozilla that is aligned with the users' interests and in taking the Internet and moving it in a direction that is more private, more secure and is aligned with what we think the Internet should be. My name is Aditya and I'm one of the founders and CTO at Luma Health. We partner with over 500 healthcare systems across the United States to deliver a platform that they use to build their own patient journeys. Starting last winter, we launched our Vaccine Operations Solution, which is a full suite of solutions that let healthcare systems craft, deliver and manage their COVID 19 vaccination strategies. We partnered with Cook County, Illinois, the second largest county in the United States, with a population of over 5 million residents. As demand ramped up, our platform began to see over 500,000 requests per second. Hundreds of thousands of patients were looking to get scheduled for their vaccines, getting checked in at clinics and mass vaccination sites, getting text or email reminders about their upcoming vaccinations and more. At Luma Health, we've been a customer of Cloudflare's for over six years. But to continue to scale further, we partnered with Cloudflare's Project Fair Shot to utilize their Waiting Room. We were able to integrate the Cloudflare Waiting Room within 72 hours. We were able to fine tune the number of concurrent users within the Luma patient experience and provide accurate information about vaccine availability for users who are waiting. Layering the Waiting Room with Cloudflare Workers has allowed us to scale up to virtually unlimited demand. The result: Over 1.5 million vaccines have been scheduled via Luma Health, and we're not done yet. We continue to work closely with our health systems and clinic partners to help address vaccine hesitancy, ensure vaccine access to all Americans, and to help all of us chart a way out of the pandemic.