 Fun fact, I recently actually changed my name, so I was hoping I would not get any more Game of Thrones references. So thanks, guys. Just kidding, it's fine. So I'm here from the Chrome security team. And I'm here to talk to you about HTTPS and why we think HTTPS should be everywhere and what we're doing to help you migrate your application. I want to start with a scary story. So imagine that you are a developer working on the Google search home page. Cool job. And Google is famous for being such a perfectionist about the search home page. Down to every pixel, down to the shade of blue for the best user experience, maximizing conversions, maximizing the number of eyes on ads. So if you were a developer working on this project, imagine how horrible it would feel if this is what your users saw. So what we're looking at here is some iteration of the Google home page with this really ugly third party ad injected. And this might be injected by some unwanted software on the user's machine, or it might be someone on the network like a Wi-Fi provider or an ISP injecting ads. And how horrible would it feel if this was your site that this was happening to? I mean, this is terrible. It's bad for your business, because fewer users are going to search. They're going to get distracted by this ugly ad. They may not have as many impressions on the legitimate Google ads. And it's a terrible user experience. It's distracting. It's ugly. And it can actually cause direct harm to the user because they're going to click on this ad, maybe even thinking that it's from Google. And as a result, they might end up with unwanted software on their machine, for example. So this is pretty bad. And I can imagine that if you put all this time into your user experience, this is not what you want to happen. But maybe you're thinking, OK, it's just like an ad. It's maybe it doesn't matter that much. There's this ridiculous disclaimer that I'm sure two people in the universe have read and actually made sense to them. So the question is, what other harm can come from a lack of security and privacy guarantees on your site? Let's look at another example here. This is a famous demo from a security conference called DefCon. What you're seeing here is an attacker eavesdropping on a Wi-Fi network and displaying for all the world to see all the sensitive user data that goes across the network in the clear. In this case, it's passwords. You can also imagine it might be credit card numbers. Or even the content that a user is reading can be sensitive and something they wouldn't want broadcast. If you're reading about a sensitive medical condition, you don't necessarily want anyone on the network to see that that's what you're doing. So today, what I'm going to be telling you about is a protocol called HTTPS, which can help you guarantee the security and privacy of your users and also the integrity of your content. And I'm sure you all have seen HTTPS before. When you go to Google and you see HTTPSGoogle.com in the address bar and you see that green lock, I'm going to be talking a lot about the green lock today. What we're doing on Chrome is trying to make it as easy as possible for you to migrate your site to HTTPS because we think it's important that every site today uses HTTPS. Let me tell you first about the properties that HTTPS gives you to help motivate why you want this on your site. First, an attacker should not be able to read the data that goes between the browser and the server. This is a pretty straightforward property that hopefully all of you want for your users. If your user enters a password into your site, an attacker shouldn't be able to see it, a credit card number. An attacker shouldn't be able to see the content that a user is reading on your site. In other words, no snooping. Everything should be private between the browser and the server. The second property that HTTPS gives you goes back to that ad injection I showed. And it's about tampering with content. When you use HTTPS, an attacker can't modify the content, such as injecting ads that goes between a browser and a server without that being detected and the connection being closed. And the third property that HTTPS gives you is that you know who you're talking to. So if you type HTTPSgoogle.com into your address bar, the server presents a cryptographic proof of identity saying, this is who I am. I'm Google. And it proves that you're talking to Google rather than some attacker who's trying to impersonate Google. So these are the three properties that HTTPS gives you. And hopefully, I've convinced you that these are properties you want on your site, whatever type of site you may be running. It's good for your user's privacy and security to protect their private information. It's good for ensuring that the content that you deliver is what they actually see, not some modified or tampered with content by someone on the network. And increasingly, as Alex alluded to, it's what you're going to need to do to use the increasingly powerful web platform. So what I mean by this is new powerful web platform features. Within the next year or so, Chrome is going to start requiring HTTPS to use those features. And this makes sense if you think about it, because using these features can compromise users' privacy and security, which is why we do prompts like this to make sure that the site that you're talking to is the site that can have access to your camera, not just anyone on the network. So in order for questions like this to be meaningful, we need to require HTTPS for using these powerful web platform features. Now, you're all web developers. You may have even set up HTTPS before. I hope some of you have. And these days, it's actually not too hard. The first step you do is you buy a certificate, which is that cryptographic proof of identity. And you configure your server to use that. And there are a number of tools out there today to help you with this. So I'm showing you one here called SSLmate. That is a really easy command line tool to help you buy a certificate and configure your server with it. And this is not what I'm going to be talking about today, because there are these great tools out there. And it's hopefully not too complicated to get HTTPS set up out of the box. What I'm going to be talking about today is the next step. Because it turns out there are a number of things that you actually have to think about after you get that out of the box HTTPS deployment. It's easy to look at this list and just feel totally depressed. It's easy to think, why should I do this? I have no hope of actually getting a solid HTTPS configuration that's going to give my users the privacy and security benefits that they need. That's what we're working on in Chrome. We're working on projects from developer tools, web platform features, reporting mechanisms to help you discover problems that your users are hitting in the wild. All of these projects are designed to make it easy to migrate to HTTPS, because we want every site to do that. So this is what I'm going to be talking about today. The projects that we're doing to help you get set up with HTTPS with a solid configuration. And I'm going to divide this into three sections. First, I want to talk about that lock icon, the overall indicator of the security status of your page. Because if we want developers to migrate to HTTPS, they have to understand what they're shooting for. And I'm going to tell you about browser tools we're building to help you understand that. Next, I'm going to talk about some web platform features that help you migrate your application in a way that you get the green lock. Because especially for large scale sites, it's not just a matter of turning on HTTPS. It's very much a matter of migrating your application. And the web platform can help you with that. Finally, I wish I could tell you that the green lock is all you need to think about. But it turns out there are a set of best practices that we recommend you follow even after you get to the green lock. And so I'm going to tell you about some of those and what we're doing to make it easy to roll those out. So let's start here with understanding the lock icon. And first, I want to show you that it's hard to understand. Because you might think, oh, it's just a lock. It's green, or it's red, or it's there, or it's not there. But it's actually really complicated. And I get confused about it all the time, and I work on it for my full-time job. So first of all, we have the neutral state. So this is what you see when you visit an insecure HTTP site. It's this kind of neutral page indicator icon. And there's really no indicator of security or lack thereof at all. So right off the bat, I hope this is a little confusing to you. Because why is it neutral? There's no security here. Why should this be neutral? It's saying to the user, everything's fine. Don't really need to think about it. But in fact, it's not fine. There's no security or privacy whatsoever. So what we're doing, and you may have heard about, is that over the next year or so, we are going to be gradually introducing a negative security indicator for this state. So that when you don't have HTTPS, your site will be marked as kind of a negative state rather than a neutral state. Because we want users to expect HTTPS as the norm and see insecure HTTP as an exception. So that's a little bit of a tangent. I'm showing you the neutral state as it is right now. Then there's the green lock state. This is what you're shooting for. This means you have HTTPS set up. Everything is good. From Chrome's perspective, we can mark this as a secure connection. All right, then there's this kind of intermediate state. And this is when you have HTTPS. So the page was retrieved over HTTPS. But Chrome noticed some problems with it that is stopping us from marking it as fully secure. And there are a number of conditions that can lead to this state. You might also be used to seeing this as a lock icon with a yellow badge. That was how it was shown until recently. But we recently started marking this as neutral instead of that yellow badge because we thought it was less confusing. So this is this kind of intermediate compromise security state, a number of things that can cause you to fall into this state. And then a similarly confusing one is what we call the red slashy lock icon of doom. And this means that something is really wrong. So in this case, your certificate might be expired, or you might have the wrong certificate, or there might be some really insecure content on the page. There are a large number of things that can cause this to happen. So understandably, when developers see these lock icons, they get confused. They might not know what the lock icon means, and they might not know why that's showing up on their page when they expect to have a nice shiny green lock. That's why we are introducing a whole new panel in developer tools whose sole purpose is to help developers find and fix problems with their HTTPS configuration, understand what's going wrong, and get to a shiny green lock. So this is on Canary now and on Dev Channel. And I'm going to show you a little sneak peek here. This is what it looks like. You can see it's its own panel in developer tools. And let me just walk through a few of the things on here. First, we have the overall security status of the page, kind of lining up with the lock icon. In this case, we're looking at a page that's in that kind of intermediate state where the page was loaded over HTTPS. But there are some problems that Chrome noticed that prevent us from marking it as secure. Now, another thing that we're really excited about, that we can use the security panel for, is helping you keep up to date. Because as much as we wish that HTTPS were something you set up and then you kind of forget about it and you're good for the rest of the time, that's not the reality. You have to keep up to date because there are constantly new crypto systems being broken, new algorithms being standardized. And the security panel is where we're going to help developers keep up to date so that their configuration stays modern. Another thing we see here is information about the security properties of sub-resources. And this is really important because if an HTTPS page loads sub-resources over insecure HTTP, that can compromise the security of the whole site. So we're going to use the security panel to show you information about sub-resources that might have been loaded with different security properties than the main resource of the page load. And you can see there's that link there at the bottom to click into the network panel so that you can see more details with the network panel that you're familiar with. So as I said, this is on Canary now. And also, as I said, its whole job is to help you figure out this landscape and make sense of it. We really hope that you try it. And if you do, feel free to shoot me an email or a file bug if you have any feedback at all because you're the audience for this feature. So the security panel is what we're doing to help make HTTPS more comprehensible to developers, help them understand what the green lock icon means and how they can get there. But especially for large sites, the security panel is not going to be the whole answer. So imagine that you have a site with hundreds of thousands of pages of content. Many of you probably do. And there may be problems on some of those pages, maybe just a few of them. And it's really hard to track those down when you migrate your whole site to HTTPS. You're not going to open every single page and look at it in the security panel for problems. So I want to tell you about some web platform tools that can help you here. What we hear from developers, especially on large sites, is that a problem called mixed content is one of their main challenges when migrating to HTTPS. Mixed content is this problem I was just talking about, where you have a main page loaded over HTTPS, but you have sub-resources loaded over insecure HTTP, which can affect the security of the whole site. So those insecure sub-resources are called mixed content. What you're seeing here is the Chrome UI when the page is loading, say, an image or other what we call passive content over insecure HTTP. So you can see you're in this intermediate state. You don't get a lock icon. We don't give a lock icon when you have passive mixed content on the page. And we have these strings to help tell the user that there's something wrong. Maybe they shouldn't trust this site fully because there's a problem with its security. So this is what happens for passive mixed content. And you can imagine if you have hundreds of thousands of pages with a bunch of images on them, it can be hard to track down any image that's loaded over insecure HTTP. Here's another type of mixed content, active mixed content. So if your page tries to load a script over insecure HTTP, Chrome and other modern browsers will just block it outright because it's just too dangerous to run an insecure script on the page. So you'll still get the green lock icon. And you might not even notice that anything is wrong here. But a user might run into some subtle way that your page is broken. And they might click on this shield icon because users are curious and they click on things. And if they click on this shield icon, they'll get an option to load the insecure script. And if they do that, then they're going to end up in the red slashy lock icon of doom. And this is what you don't ever want on your site because it means something is really broken. And Chrome can't make any security or privacy claims to the user. This is the case of active mixed content. And again, it can be hard to find this on your site if you have a huge site. So the web platform offers you a way to get notified of mixed content whenever it runs on your site. And this is handy because if your user runs into any of these situations, you want to get notified about it so that you can find it and fix it. The mechanism for this is called content security policy. And content security policy is actually a much more general mechanism. But I'm just going to talk about a few specific uses of it here. So content security policy. It's a header that you send on an HTTP response from the server to the browser. And what the header says is that you want to receive reports whenever content is loaded from not HTTPS. So you can see it has this report only in the header name. That means it's not going to actually affect how the page is loaded or runs in the browser. It's only going to mean that when non-HTPS content is loaded, you'll receive a report about it. In other words, if a user lands on mixed content on your site, you will find out and you can fix it. I want to give a shout out to this cool service called reporturri.io. And this is a service that can collect and help you analyze your mixed content reports. So you can sign up, and then you get a URL. And you can put that URL in your content security policy header. And then your reports will go to this site, which will help you analyze and collect them. So you don't have to run your own server infrastructure yourself to handle these reports. OK, cool. So we have a way to find out when a user runs mixed content on our site. There's one step further that you can go. Suppose that you actually don't want any mixed content to ever run on your site. You want it to be blocked entirely. But if that content is loadable over HTTPS, even if the URL itself in your HTML is HTTP, wouldn't it be great if the browser just loaded it over HTTPS and didn't wait for you to go find and fix and update that link to HTTPS yourself? It turns out you can use content security policy for this, too. So in the same way, you can send a header from the server to the browser. And this header says that you want to upgrade insecure requests. So you notice it doesn't say report only anymore, because this is going to actually affect the behavior of the page as the browser loads it. What this is going to cause the browser to do is, any time it sees a sub-resource with an insecure HTTP link, it'll automatically rewrite that to HTTPS. And you can imagine this can be really helpful. So for example, you have a huge site, and you don't want any mixed content to run on your site. But you load a lot of your sub-resources from a CDN. And if you know that a CDN supports HTTPS, you can just send this header to make sure that those sub- resources automatically get upgraded to HTTPS, because it can be a massive engineering effort to go actually find and update all your links. So these are some web platform tools that can help you get to that green lock. And we want to make it as easy as possible for you to get there, because the green lock is kind of the bare minimum, saying that you have the security and privacy guarantees of HTTPS for your users. But as I warned you, at the beginning, it doesn't end there. There are a number of best practices that you can use to get even stronger security and privacy guarantees or to avoid kind of loopholes in your application that allow an attacker to get in. So I'm going to give you a little grab bag of these tools and tell you how Chrome is making it easier for you to use them. The first tool in my grab bag is super simple. Protect your cookies. If you run a site where users log in, the session cookie that you set on login is among the most sensitive data that goes between the browser and your server. Because if an attacker steals that cookie as it goes over an insecure connection, they've basically stolen your user's entire identity on your site. So it's really important to protect your cookies and prevent them from being sent across insecure connections. And this secure attribute on cookies basically does exactly that. It says to the browser, this is a sensitive cookie. Don't ever send it except over. And it's a secure HTTPS connection. So once you set up HTTPS, you should add this secure attribute to all your cookies. It's super simple. Trick from grab bag number two. Also really simple. I call it always HTTPS. Imagine that your user lands on a site. And that site links to your site. But the link is over insecure HTTP. If the user follows that link, it's kind of game over. Because an attacker can intercept the response and do whatever they want. And at that point, basically, all bets are off. What you want is for that link to always go over HTTPS. So any time a user visits your site, it's HTTPS only. And this header called strict transport security is exactly how you guarantee that. So you tell the browser, I want to be always HTTPS. And the browser will remember that. And any time a request goes to your site, it'll be over HTTPS, even if the user is following a link that says insecure HTTP in the HTML. Also pretty simple, right? There's one more problem that I want to tell you about instead of best practices to address it. But it's a little more complicated. So let me explain the problem here. Way back in HTTPS 101, I talked about buying a certificate, that cryptographic proof of identity, that your site is who you say it is. What is a certificate? It's a cryptographic key pair, which has been signed by another cryptographic key pair, which has been signed by another and so on, chaining up to what's called a root certificate authority. And this chain is a certificate chain. That's what we call it. The problem that we're trying to address here is that there are actually hundreds of root certificate authorities that are trusted by every single laptop and phone and browser and OS and so on. So if any single one of those hundreds of trusted root certificate authorities is compromised, goes rogue, has an evil employee, that rogue CA can actually issue a certificate for your site. And by default, it'll look just as legitimate as the real certificate for your site. So basically what I'm saying is that there's a large attack surface here. If any trusted root certificate authority is compromised, that can start issuing certificates for any site. And we call that a mis-issued certificate. What we want is for the browser to be able to recognize a mis-issued certificate from a legitimate certificate. It should see this certificate, which has been issued by an evil CA. And it should somehow be able to know that this is not the legitimate example.com certificate. This would be great. This is a real win for security. And Google has two efforts underway to address this problem. I'm going to tell you briefly about the first, because it's a whole talk in itself, and then a little bit more about the second. The first project is called Certificate Transparency. Really cool, ambitious, exciting project. And the goal is to log all certificates publicly. In a way that can't be modified or tampered with or removed later. So the end goal here is not necessarily that a browser would be able to recognize in real time a mis-issued certificate from a legitimate certificate. But if you're a site owner, if you're the owner of example.com, you can monitor these logs. They're public. Anyone can monitor them. So you can monitor them and watch for certificates that have been mis-issued for your site. And then you can take action on that, like revoking, asking the CA to revoke the certificate. So this is a really big project. If you want to kind of take matters into your own hands now, there's another tool that we have called public key pinning, which we tend to recommend for more security sensitive sites, sites that have a little bit more operations experience with HTTPS. And it'll become clear why that's who we recommend it for in just a minute. So let me explain what this is. And again, the goal here is to get a stronger form of HTTPS by allowing the browser to recognize a mis-issued certificate from a legitimate certificate. Public key pinning is a way for a site to describe to the browser, this is what my certificate change should look like. And if you ever see a certificate change for my site that doesn't match this description, then that's bad. Close the connection, don't allow it. Something fishy is going on. It's pretty cool. It's like many of the things I've talked about today. It's an HTTP header that the server sends in a response to the browser. And it contains this kind of syntax that describes the certificate change, what the certificate change should look like. Now, the problem is that, unfortunately, this is a little bit hard to do right. And it's quite easy to make a mistake. So this way that you describe a certificate chain, it's hard to do it in a way that all clients will reliably match your certificate chain to that description. And what happens if you get it wrong? If you get this description wrong, it's sort of like performing a denial-of-service attack against yourself. Because users are going to see these pins. They're going to say, oh, this is what the certificate change should look like. And then this actual chain is not going to match that description as they see it. And then they're not going to be able to access your site. So that is a sad situation. And that's why we tend to recommend public key pinning for sites that have more experience operating HTTPS and are particularly security sensitive. So they will really benefit from the added security that public key pinning provides. However, recently in Chrome, we rolled out a new feature that helps make this more accessible to sites that don't have giant operations teams, for example. So this new feature is called violation reporting for public key pinning. It's sort of like a practice mode. So instead of rolling out with this public key pins header, you roll out with the report-only version of it. And you specify, like with mixed content reporting, you specify a URL. What this means is you're not saying this is what my certificate change should look like and close any connections that don't match this description. Instead, you're saying, hey, I'm in practice mode. This is what my certificate change should look like. But if I've messed up and there are clients who can't actually validate my certificate chain in a way that matches that description, then don't close the connection. Just send me a report about it so that I'll know that there's something wrong and I need to make an adjustment before I roll out for real. So this makes it easier to deploy public key pins without fear of dosing your site. And even after you go into enforcement mode, so you can see I've dropped the report only here, this is a real pin that will be enforced and cause connections to be closed, you can leave the report URI in there. So if something is going wrong, you'll get a report about it even after you've gone live with real public key pins. All right, I've talked to you about a lot of things today, about developer tools to help you understand the HTTPS landscape, about web platform features to help you get to a green lock, and about a set of best practices to make sure that your users are really getting the best of HTTPS. I want to pop back up a level, because even though we're trying really hard to make this easy for you, it is going to take time and energy on your part. So I want to remind you why it's important. So I showed this scary story about some injected ad just totally messing up your user experience. And this is terrible for your business, it's bad for your site, bad for your user's experience, and it can directly harm your user, because they might think that this content is coming from you, and take actions or make decisions that they wouldn't otherwise. Moreover, it's the way the web is going. Chrome is going to start requiring HTTPS for powerful web platform features, because it's the only way for your site to use these features without exposing your users to harm. So that's why we think HTTPS is the future. We want to see it deployed on every site, and we want to make it as easy as possible for you to migrate. All right, thanks so much for listening. If you have any questions, feel free to contact me on email or Twitter. Thanks.