Mythbusting HTTPS: Squashing security’s urban legends - Google I/O 2016

Key Takeaways

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 mythbusting 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 begins in 2010 or thereabouts imagine you're sitting at your computer surfing the web watching the hamster dance or whatever 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 right 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 uh 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 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 there also a lot of responsibility right like um take uh 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 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 EES dropping 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 h 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 htps 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 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 being passed between them not any attack or eases dropping 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 fact 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 Alex 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 is travel guide is really slow and sluggish and Alice is like okay 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 the user experience that Alice has built covers up her own lightweight unobtrusive ads and I just want to drive this home point this point home Alice's friend trust Alice's site so when she clicked on one of these 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 malare 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 uh 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 if if I'm going to 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 over when when accessed over plain HTTP which is non-secure and there are a few more that 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 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 AB 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 perfor 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 these two things in doing his research and he's wondering what's going on where is 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 assoc associated with https but this is far uh uh far in way what people tend to run into problems with the network latency the extra round trips so once Bob turns on htps 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 a link a bookmark to the HTTP version of Bob site or if a user follows a link to the HTT P 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 okay they agree on some cryptographic parameters and then the client says okay 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 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 HT DP 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 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 that 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 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 presumption as you might imagine and if your server supports it you should turn it on just to 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 roundtrip TLS handshake and subsequent requests would be able to reuse the session identifier to avoid a roundtrip 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 HTTP 2 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 kind of linked together in HTTP 1 traditional HTTP requests and response are kind of 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 the second response is going to be delayed by that much also in HTTP 2 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 it when it when that database call returns it can finish the 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 htttp the browser requests the homepage then parses the HTML and says oh now I need the stylesheet 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 homepage I know that as soon as you get around to parsing that HTML you're going to need a bunch of scripts and stylesheets and other stuff also so I'm going to proactively push those resources to you and the client can keep them in its cash 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 HTTP 1 traffic and those proxies and intermediaries get confused and in some case even break things uh 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 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 road map is updating that software so that they can turn on more of these optimizations and especially so they can enable http2 and we have hoped 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 HTTP to 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 HTTP to 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 techsavvy 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 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 uh under certain conditions but using htdp is like no life jacket at all so it's 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 it's trivial that said I'm not telling you that you shouldn't worry at all 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 cryptograph cryptographic algorithms or keystrings or anything like that it'll tell you what best practices are to keep your server and your user 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 cool all right Charlie in my in 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 but these days Charlie's kind of running out of money and the VC Market has gotten a little tighter um 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 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's 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 a 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 SSL mate has for many years now been offering certificates starting at 15 bucks 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 SSL made and lets encrypt in addition to having free or 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 uh a traditional negative 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 htps version of his site it's important to s 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 uh large changes to your site but you'll then recover back to your normal the 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 uh noticeable Improvement due to this boost but uh that's possible that might change in the future and it is a small 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 thirdparty 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 you know hundreds of thousands of Articles and many different types of thirdparty 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 um because it's true that when you move to https you're going to have to start thinking about whether all your thirdparty 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 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 industrywide 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 uh 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 it 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 road map in the very near future and if it isn't you should ask them why not and tell them I said why not um 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 hjp referrer 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 referral 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 that leak that in plain text over the network as you follow HTTP links so it's important for privacy purposes that these referal 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 okay to send in the referrer 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 okay to send the origin that is not privacy invasive to send the origin and the origin in this 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 okay to relax this restriction because this is not going to leak any sensitive information there are a variety of different referral policies that you can set so you can you can uh 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 uh 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 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 htps 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 these are what tend to be uh more common in cases like Francisco uh 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 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 is not happy with this he wants his green lock that he worked hard for uh to tell the user that the security on his site is uh is properly configured a web platform feature called content security policy is what but 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 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 content should be loaded over https with the exception that dynamically generated and inline scripts are okay 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 reporton 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 that's visible to the user won't block any content from loading it'll just send reports so that Francis Francisco can find out what's being loaded over non-secure HTTP and fix it if you don't want to run your own infostructure to collect these reports there's a great service called report u.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 uh to help you make sense of what you're getting for all of these problems Chrome recently launched the dev tools security panel so if you go into Dev Tools in 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 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 thirdparty 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 5 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 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 to chat [Applause] [Music] thanks [Music]