 Hi, everyone. My name is Emily Stark. I'm a software engineer on the Chrome security team. And today, I would like to take you on a myth-busting journey about the protocol that we use to send and receive data on the web over a secure connection. And that's HTTPS. And I think this is one of the most important topics for a web developer today. So our journey begins in 2010, or thereabouts. Imagine you're sitting at your computer surfing the web, watching the hamster dance, or whatever people did in 2010. And you fall into a deep sleep, so deep that you don't wake up until today in 2016. And you look around at the web today, and it's pretty different from when you fell asleep in 2010. Today we have things like add to home screen, which lets websites behave more like apps, push notifications, keeping your users engaged, coming back to new content, and cool new APIs, like device orientation, geolocation, all these things you've been hearing about at IO today that let you build progressive web apps, and let websites do things they never could have done before in the past, things they really couldn't have done in 2010 when you fell into your deep sleep. So these are all very powerful features for websites to have, but they're also a lot of responsibility. Take geolocation, for example, the geolocation API. If a website can access my location, then the website knows where I live, where I work, when I'm home, when I'm away, where I shop, where my friends live, where my doctor is. It's a lot of information for a website to know about me, right? So if you woke up to this web in 2016, this very powerful web, you might be surprised to find that there are still websites where you can make a purchase with your credit card or send a private message to a friend or research a personal health condition in such a way that an attacker eavesdropping on the network can see all the data that you're sending back and forth. Or you might be surprised to find that there are still websites that spend tons of money and time and energy crafting the perfect user experience only to deliver that experience to the user and have an ISP or a Wi-Fi provider or some other intermediary on the network injecting obnoxious ads like this. And this isn't hypothetical. We see major ISPs injecting ads or other content all the time. And if this was your website, you'd be pretty upset, right? Because this interferes with that perfect user experience. It might mess with your revenue streams by covering up your own legitimate ads. And at worst, it might even trick your users into downloading and installing malware onto their computers. So if you woke up in 2016, you might hope to wake up to a web where data is protected from this kind of snooping and tampering from the very beginning. And that's what we get from HTTPS. That's what this green lock signifies. And in 2016, we're hoping to move towards a web where this green lock is so ubiquitous that we might not even need to show it at all, because it's just the default that users have come to expect as the bare minimum in terms of security for any site on the web today. This green lock signifies three main security properties. Identity. When you type HTTPS Google.com into your browser, your browser receives a cryptographic proof of identity called a certificate from the server. And the browser uses that certificate to prove that it's talking to the real Google.com, not some other server who's pretending to be Google.com. So when you type a URL in your address bar, the browser gets a proof that that's the real domain that you're talking to. Confidentiality. Once your browser knows that you're talking to the real Google.com, both those parties, the browser and the server, have a guarantee that only they can read the data that's being passed between them, not any attacker eavesdropping on the network. And finally, integrity. The browser and the server have a guarantee under HTTPS that when they send data from one to the other, the data they send is what the other party receives. So an intermediary on the network can't modify or tamper with the data that's being sent. Only the browser and the server can. So these are the three security properties that we get from HTTPS. In your mind, you might have some other associations. When you see this green lock, you might think that it represents a financial burden or a performance or maintenance cost. And many of these associations were true five or 10 or 15 years ago. But many of them are no longer true today. So in this talk, what I'm going to do is tell you five stories about HTTPS and try to separate facts from fiction, show you what might have been true in the past that is now becoming a bit of a myth, to try to convince you that HTTPS is possible and important for every site on the web today. My first story is about a web developer named Alice. Alice runs an online travel guide. And it's a very cool travel guide, but it doesn't have any privacy or security-sensitive content. It doesn't have any login forms or credit card forms or anything like that. So Alice doesn't really think of her site as something that needs HTTPS. But one day, Alice is talking to her friend and her friend says that on her computer, Alice's travel guide is really slow and sluggish. And Alice is like, OK, that's weird, because on my computer, it's really fast and snappy and responsive. That's the way I built it to be. So she goes over to her friend's house and checks out what's going on. And you can probably guess that what's going on is that on Alice's friend's computer, a whole bunch of ugly sluggish ads are being injected into Alice's site. So it ruins the user experience that Alice has built, covers up her own lightweight unobtrusive ads, and I just want to drive this point home. Alice's friend trusts Alice's site. So when she clicked on one of these ads, she didn't expect to download the malware that infected her computer. And that's natural, right? If you're an average user, you click an ad on someone's site, you get malware on your computer, you're going to blame that site. So Alice is bummed out about this, as you would be, I'm sure. So to console herself, she goes off and starts working on a new feature. And this new feature, say it uses the geolocation API to figure out where the user is and then give them localized travel tips. But as she's working on this feature, she goes to try it out in Chrome and she sees that it doesn't work. The reason it doesn't work, as you can see in this error message in the developer console, is that Chrome and other browsers are starting to remove access to powerful APIs and other web platform features when they can't be safely used over non-secure HTTP. So in order to use the geolocation API, your site needs to use HTTPS. And there's a good reason for this, right? If I'm going to trust Alice's site with my location, I need to know that I'm talking to the actual Alice's travel guide, not to some other site pretending to be Alice's travel guide. So we need that identity property of HTTPS to be sure that when I as a user grant a site access to my location, I'm actually talking to the site that I trust with my location. Chrome and other browsers, as I said, are not limiting this to geolocation. There's a list of features that have already been removed when accessed over plain HTTP, which is non-secure. And there are a few more that are coming down the pipeline. Alice realizes, after all this, that in order to build a progressive web app with the user experience that she wants, and in order to do it safely and guarantee that the user experience that she builds is the one that her users receive, she needs to use HTTPS. And that's why we think that HTTPS is important for every site on the web today, even if on the face of it, it doesn't look privacy or security sensitive. My next story is about a data-driven guy named Bob. Bob has an e-commerce site, let's say. And Bob has done some testing and some optimizing and some A-B tests. And he's found that reducing latency, reducing the time that it takes a user to load a page on his site, is crucial for optimizing conversions. So the faster his page loads, the more sales he makes. And Bob has heard some not-so-nice things about HTTPS and performance. Yell.com is an online business directory that recently made the switch to HTTPS. And they admirably documented their experience, some of it positive and some of it negative. And what was really interesting to see is that they saw a performance impact from moving to HTTPS. Whereas Google, way back in 2010, was able to migrate to HTTPS, migrate all of Gmail to HTTPS, with a pretty negligible performance impact. So Bob is seeing these two things in doing his research, and he's wondering what's going on. Where does this discrepancy come from? So let's dig into what happens when the browser sends an HTTPS request to see what's going on here and what Bob can do and what you can do to minimize the performance impact. So I'm focusing here on the network latency introduced by adding HTTPS. There are some other performance costs associated with HTTPS, but this is far in a way what people tend to run into problems with, the network latency, the extra round trips. So once Bob turns on HTTPS on his site, the first thing that's going to happen is that a whole bunch of his users are going to start having to take redirects to get to his site. So for example, if a user has a bookmark to the HTTP version of Bob's site, or if a user follows a link to the HTTP version of Bob's site, Bob is going to have to redirect them to the HTTPS version. So right off the bat, that's a little bit of an overhead that we wouldn't have had if we were just sticking to HTTP. Next, the browser has to go and actually speak HTTPS. And what's involved here is setting up a TLS connection. TLS is the underlying protocol used to set up a secure connection for HTTPS. These two round trips here are the two round trips that are part of the TLS handshake, what the browser and the server do to set up a TLS connection. And this is a bit of a simplified version, but the overall idea is that the client says, hi, I want to speak TLS. And the server says, hi, I can speak TLS, and then sends its certificate, which is that cryptographic proof of identity. The client validates the certificate, makes sure everything looks OK. They agree on some cryptographic parameters. And then the client says, OK, I'm done. I'm ready to start speaking TLS. And the server says, yeah, me too. Let's speak TLS. And then the browser can actually go ahead and send the HTTPS request. So these are the two round trips that are needed to set up a TLS connection before the browser can actually send the HTTPS request over this secure connection. So let's take this one by one and see what we can do to optimize here. First, this HTTP to HTTPS redirect. The web platform has a feature called strict transport security that you can use to remove this redirect for many of your users in most cases. So strict transport security is an HTTP header that you can set on responses that tells browsers, I always want my site to be accessed over HTTPS. Whenever the browser sees this header on your site, it'll remember for the period of time that you configure that your site should be accessed over HTTPS. And that means whenever the browser is about to follow a link to the HTTP version of your site, it'll automatically internally rewrite this link to HTTPS and go straight there. So after the user has seen this header once, they're not going to have to take that HTTP to HTTPS redirect until the header expires. But an important caveat is that when you set this header, you're committing to supporting HTTPS for that period of time. So this is not something you want to do while you're testing HTTPS. It might not even be something you want to do until you're comfortable running and maintaining HTTPS. But once you're there, you can set this header to remove that HTTP to HTTPS redirect for many of your users. Next, let's look at the TLS handshake, these two round trips. There are two TLS configuration options that you can set if your server supports them to remove a round trip here in many cases. The first optimization arises from the fact that, by default, the client waits until this entire handshake is finished in order to send the HTTPS request. But it turns out that in many cases, it's actually just fine for the client to send this HTTPS request alongside the end of the handshake. So instead of waiting for the whole two round trip handshake to complete, the client can kind of stuff the HTTPS request in there before everything is all done. And that means the server can start processing it without waiting for these two round trips to complete. And this is called TLS false start. And it's something you can turn on in your server configuration if your server supports it. And when the client supports it also, that removes a round trip from the handshake latency. The next optimization that you can turn on is pretty straightforward conceptually. If the browser and the server have spoken TLS to each other in the past, the browser can remember a session identifier. And the next time it goes and sets up a TLS connection with the server, it can say, hey, I have a session identifier. We don't need to do this whole handshake dance again. Let's do the bare minimum work we can to set up a TLS connection. And it turns out that the bare minimum work involves shaving off a round trip. And this is called TLS session resumption, as you might imagine. And if your server supports it, you should turn it on. Just to illustrate the effect here a little bit, if you go and load google.com and look at all the requests that are sent to google.com in Chrome's developer tools, in a common case, only the first one of these would impose that full two round trip TLS handshake. And subsequent requests would be able to reuse the session identifier to avoid a round trip. All right, that was a lot of work. We're finally ready to send the HTTPS request. And this is where things get cool, because this is where using HTTPS unlocks some pretty dramatic performance improvements, primarily in the form of HTTP2. The next version of HTTP, which is now supported in many browsers, including Chrome and Firefox. So I'm going to describe some of the performance wins that you get from HTTP2. And then I'll come back and talk a little bit more about its connection to HTTPS and why the two are linked together. In HTTP1, traditional HTTP, requests and response are sent in order. In the common case, the browser sends a request, waits for a response, sends another request, waits for the response, and so on. This means that if the server takes a while to produce that first response, the client is going to be waiting a while before it even sends the second request. And the second response is going to be delayed by that much also. In HTTP2, multiple requests and responses can be multiplexed over the same connection. What this means is that the browser can, for example, send a request. Before even waiting for the response, the browser can send a second request that it knows it's going to have to send. The server can start processing the first request, maybe even send part of the first response, but then it has to, say, wait on a slow remote API call or a database call. So while it's waiting for that to happen, it can start processing the second request, send the second response. Then when that database call returns, it can finish the first response. So this means multiple requests and response can be interleaved on the same connection, which has much improved network performance properties. Another cool HTTP2 feature is pretty intuitive. Normally, in traditional HTTP, the browser requests the home page, then parses the HTML, and says, oh, now I need the style sheet and the scripts and the images, all that stuff that's referenced from the HTML. But in HTTP2, the server can say, oh, you just fetched the home page. I know that as soon as you get around to parsing that HTML, you're going to need a bunch of scripts and style sheets and other stuff also. So I'm going to proactively push those resources to you. And the client can keep them in its cache so that it doesn't have to go over the network to fetch them when it actually needs them. Now, I said that HTTPS unlocks the massive performance wins of HTTP2. What I mean by that is that browsers have said they are only going to support HTTP2 over HTTPS. If you want to use HTTP2, you have to use HTTPS. And there's two reasons for this. One is that it provides an incentive to move to HTTPS because we, cruel browser vendors, think that HTTPS is the best thing for the ecosystem and everyone should be using it. So we want to provide incentives to make the switch. There's also a practical reason of compatibility. And what that means is that there are proxies and intermediaries out there that get kind of confused when they see HTTP2 traffic because HTTP2 looks pretty different from normal HTTP1 traffic. And those proxies and intermediaries get confused and in some case even break things. So we need that confidentiality and integrity guarantee of HTTPS to be able to support HTTP2 without breaking things. If we go back to yell.com, that online business directory that Bob read about and was unhappy to see that they had some performance impacts from moving to HTTPS, it turns out that their negative performance impacts were mostly due to their use of some outdated load balancing software, that they weren't in a position where they could update before making the switch to HTTPS. But what they have on their future roadmap is updating that software so that they can turn on more of these optimizations and especially so they can enable HTTP2. And we have hope for yell.com because of stories like weather.com, who saw a small performance impact from moving to HTTPS. But then it was blown out of the water by the performance wins that they got by subsequently turning on HTTP2. In the end, since Bob is in a position where he can update his server software and where he can turn on some of these optimizations and technologies, he shouldn't see any negative performance impact from moving to HTTPS. And if he does, he should be able to outweigh it by turning on HTTP2. All right, how about a slightly different kind of story now? This is a story about not a web developer, but an evil person named Eve. And Eve is a little short on cash and also pretty tech savvy. So when Eve needs some fast money, she goes online and she searches around for the latest HTTPS vulnerabilities. And she picks the one with the fanciest logo. And she runs an automated tool to find vulnerable sites on the internet. And then she carries out one of these attacks against that site to harvest sensitive information like passwords or credit card numbers that she can turn into cold hard cash. This is pretty true. HTTPS research is really hot these days. There are hot new techniques like formal verification that mean bugs are coming out at a pretty fast clip. And it's increasingly common for security researchers to make their attacks more practical than theoretical by writing tools that scan for vulnerable hosts on the internet and by building proof of concepts that demonstrate that the attacks are practical in some cases. So I want to emphasize here, after I've shown you all these scary attacks, that the existence of these attacks makes HTTPS kind of like a life jacket with some minor defects that come into play in certain cases under certain conditions. But using HTTP is like no life jacket at all. So in most cases, when you look at most of these attacks, it's far better to use HTTPS despite the existence of these attacks because if Eve wants to attack an HTTP site, she doesn't even need to try its trivial. That said, I'm not telling you that you shouldn't worry about these. You should use the tools and support that are out there to keep your server and configuration up to date. SSL Labs is a scanning tool where you can type in the address of your site and it'll scan your server, give you a grade, and tell you what configuration tweaks you should make to avoid becoming vulnerable to new attacks. Similarly, the Mozilla SSL Configuration Generator takes a few parameters about your server and then it spits out the configuration that you should be using that adheres to best practices so that you don't have to worry about picking cryptographic algorithms or key strings or anything like that. It'll tell you what best practices are to keep your server and your users safe. Attacks always get better. And I'm betting that there will be many more HTTPS attacks in the next few years. But it's still better to wear your life jacket even with a few minor defects. And there are great tools out there, some of which didn't exist five or 10 years ago, to help you keep your site safe from Evil Eve. How many of you work at startups? All right, Charlie, in my next story, two years ago, he had a great idea for a startup. He decided that he wanted to build a site where you can send chat messages to your friends on the internet. And he raised $20 million of venture capital funding for it. But these days, Charlie is kind of running out of money. And the VC market has gotten a little tighter. So he needs to make sure that every dollar that he's spending before he needs to raise his next round is going to a good cause. And he's heard that HTTPS costs money, maybe money that he can't afford. Now, money is sort of a part of all of these stories in one way or another. I talked about performance, which ultimately kind of boils down to money. In my last story, I'm going to talk about ads, which is also very closely tied to money. So in this story, I'm just going to talk about two aspects of the financial parts of HTTPS that Charlie is especially worried about. First, these cryptographic proofs of identity that I keep talking about, certificates. When you need to go get a certificate, traditionally, you buy it from an organization called Certificate Authority. You prove your identity to the Certificate Authority, and it gives you a certificate that you can use to prove your identity to browsers. You might wonder how much these certificate things cost. And while it's certainly possible to pay a lot of money for certificates, you don't have to. A project called SSLMate has, for many years now, been offering certificates starting at $15 a pop. So even if you need multiple certificates, even if you need one of their fancier options, it shouldn't break the bank. A newer project called Let's Encrypt offers free certificates. And both of these projects, SSLMate and Let's Encrypt, in addition to having freer or very affordable certificates, they also offer automated command line tools that help you buy and manage your certificates automatically so that they don't expire or other certificate management tasks like that. So certificates are not going to be the reason that Charlie's startup runs out of money. The other thing that Charlie is worried about is search ranking. So you can imagine that if you move your site over to HTTPS, search engines might get confused. And you might lose search ranking, because a traditional nugget of wisdom is that having two different versions of your site can have a negative impact on search ranking. Google, in particular, has a few best practices that you should follow when moving your site. And here I'm showing the basics. When Charlie turns on HTTPS for his site, the first thing he wants to do is serve 301 redirects to tell search engines that his site is over at the HTTPS version now. And once the search engine crawler gets to the HTTPS version of his site, it's important to serve a canonical link element, reinforcing the idea that HTTPS is the canonical version of Charlie's site. There are a few other best practices that you should follow to avoid losing search ranking. And rather than repeat them all here, they're all pretty straightforward, so I encourage you to go check out these resources after the talk. If you do your research and follow these best practices, you can expect a minor fluctuation in search ranking, which happens anytime you make large changes to your site. But you'll then recover back to the normal levels that you had before the transition. In fact, Google even has a small search ranking boost for HTTPS, so it's actually considered a positive signal. At present, you probably won't notice any noticeable improvement due to this boost, but that's possible that might change in the future, and it is a small positive signal now. In other words, if you follow the best practices and take a little time to do research before moving your site over, these financial costs, certificates, and search ranking should be negligible. My final story about HTTPS is the story of Francisco and his adventures with third-party content. I'm sure many of you have lots of third-party dependencies in your site. So let's say that Francisco runs the website of a major news organization. And that means he has a large site with a lot of legacy content, hundreds of thousands of articles, and many different types of third-party content to worry about. And he's heard that if you move to HTTPS, all your third-party content must be available over HTTPS also. So it's easy to see why this might freak Francisco out a little bit, because it's true that when you move to HTTPS, you're going to have to start thinking about whether all your third-party content is also available over HTTPS. First and foremost, Francisco is a little worried about ads, which is what he gets his money from. So Francisco is wondering if his ads will be available over HTTPS, if he'll be able to serve them on his site once he's made the switch. Maybe a little-known fact, for Google AdSense requests, they're always served over HTTPS for most users. So even before Francisco has moved his site to HTTPS, his AdSense ad requests are already being served over HTTPS for most users, and so he shouldn't have to worry too much about this. And the exception here is users who are in countries that actually block HTTPS traffic. This isn't just a Google thing. This is an industry-wide trend. In 2015, the Interactive Advertising Bureau published a blog post in which they quantified the number of their member ad systems, which support HTTPS. 80%, that's pretty good. And they underscored their commitment to getting all the way there and getting to 100%. In this day and age, it's unlikely that getting your ads to be served over HTTPS will be a blocker for moving. If your ad systems don't support HTTPS, I encourage you to ask them about it. You might find that it's already on their roadmap in the very near future. And if it isn't, you should ask them why not and tell them I said why not. The next type of third-party content that Francisco is worried about is the partnerships that he has with external sites that rely on the HTTP refer header. What this means is that when a user clicks a link on Francisco's site and that link points to an external partner, that external partner will look at the HTTP refer header to see that the traffic came from Francisco's site and attribute it appropriately. Now, this might be something that's used for analytics purposes, or it could be something that's used for revenue purposes, but either way, this refer header is important to a lot of sites on the web today. The problem, which may not be obvious, is that when you move your site to HTTPS, if a user follows a link to an HTTP partner, browsers will strip the refer header for privacy reasons. And that's because if you're doing something sensitive on an HTTPS site, the URL that you are on might be sensitive information. And the browser shouldn't just leak that in plain text over the network as you follow HTTP links. So it's important for privacy purposes that these refer headers are stripped. But that's a problem for Francisco when his HTTPS site links to HTTP partners. He needs that refer header to be there. Refer policy to the rescue. This is a web platform feature. And there are a few different ways you can set it. But it basically allows you to make a compromise between privacy and functionality, where you can say, in some cases, there is an amount of information that is OK to send in the refer header. So in this example, Francisco has a link on his site to an external partner that's only available over HTTP. And Francisco is setting a refer policy on that link, saying that when the user follows that link, it's OK to send the origin. That is not privacy invasive to send the origin. And the origin in this context, you can think of it sort of like the domain. So when Francisco sets this refer policy on his links to external partners, the refer header will contain the domain of Francisco's site so this external partner can attribute the traffic correctly, but they don't need to see the full URL. And Francisco is telling the browser, it's OK to relax this restriction because this is not going to leak any sensitive information. There are a variety of different refer policies that you can set, so you can choose a setting that works for your site here. Finally, Francisco is losing sleep over a kind of general problem called mixed content. Mixed content is the general phenomenon where an HTTPS site loads a sub-resource over HTTP. And this is an important case because when an HTTPS site loads a non-secure sub-resource, that non-secure sub-resource can actually compromise the security of that HTTPS site, which is loading it. So if you try to load a non-secure script or iframe or other active content like that on an HTTPS site, browsers will actually block it because that content is too powerful and would completely wipe out all the security of that HTTPS site. In the cases of images, and these are what tend to be more common in cases like Francisco, Francisco's site might have lots of old news articles that link to third-party images that aren't available over HTTPS, or maybe they're loaded dynamically and it's not so easy to find which strings he needs to change to load all these third-party images over HTTPS. In the case of content like this, what we call passive content like images, browsers will allow it to load so the site won't be completely broken, but the green lock goes away. So Francisco loses his green lock to alert the user that there is something going wrong, something's not quite right with this site. And Francisco's not happy with this. He wants his green lock that he worked hard for to tell the user that the security on his site is properly configured. A web platform feature called Content Security Policy is what we usually recommend developers to help them find and fix instances of mixed content on their site. Content Security Policy is a rather general mechanism. It can be used for many different things, but in this case, what I'm showing is an HTTP response header. And when the browser sees this header on Francisco's site, the browser interprets this as follows. Francisco's site is saying all of my content should be loaded over HTTPS, with the exception that dynamically generated and inline scripts are OK. Let's just ignore those. Otherwise, all content, all scripts, all images should be loaded over HTTPS. And if the browser ever sees content that violates the policy, this policy that all content should be loaded over HTTPS, then the browser should send a report to this URL that Francisco has configured. So this header is basically a way for Francisco to assert to the browser that all content should be loaded over HTTPS. And he wants to receive reports about any content that isn't. And that allows him to go find and fix instances of mixed content on all his gazillions of pages. And this header name is report only, meaning that all of this happens invisibly to the user. It doesn't change the behavior of Francisco's site. Merely serving this header will not cause anything to happen that's visible to the user, won't block any content from loading, it'll just send reports so that Francisco can find out what's being loaded over a non-secure HTTP and fix it. If you don't want to run your own infrastructure to collect these reports, there's a great service called reportURI.io where you can go sign up and you'll get a URL and you can use that URL as your report collection endpoint in your content security policy. And this service will collect these reports for you and even give you some cool data visualization and analytics tools to help you make sense of what you're getting. For all of these problems, Chrome recently launched the DevTools security panel. So if you go into DevTools and Chrome and you open up the security panel, you'll see a whole bunch of information that is designed to help you find and fix HTTPS configuration problems, such as these problems of loading third-party content over a non-secure HTTP. So we would love for you to check it out and give us feedback because our sole goal here is to help you set up HTTPS as painlessly as possible. The story of Francisco is true in that third-party providers must support HTTPS in order for you to move your site over. But what's new, what's changed in the past few years, is all these new tools and support in the ecosystem and in the web platform to help you upgrade all your third-party content. When I look back at these five stories about HTTPS that I've told you today, I think there's one kind of moral that emerges. And the moral is that five, 10, 15 years ago, HTTPS was kind of slow, kind of expensive, kind of a pain to set up. But these days, in 2016, browser vendors, web developers like yourselves, server software developers, security researchers, all of these parties have come together to make HTTPS a lot faster and easier and cheaper and all-around better than it was in the past. And that's why we think it's both possible and really important for every site on the web today, this very powerful web that we have. Every site should be using HTTPS. Thank you so much for listening. I really appreciate you coming. I will be in the mobile web sandbox area if you have any questions, and I'd love to chat. Thanks.