Mythbusting HTTPS (Progressive Web App Summit 2016)


[MUSIC PLAYING] Hi everyone. My name is Emily Schechter I’m
a product manager on the Chrome security team, and
today I would like to take you on a mythbusting
journey about the protocol 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 story begins on a
dark creepy night in 2010. Imagine that in 2010, you’re
sitting at your computer, you’re surfing the web, you’re
getting sucked into a YouTube hole, you’re watching the
Twilight saga trailer, or maybe that double rainbow
video, or one of the other popular
YouTube videos in 2010. And you fall into a deep sleep. So deep that you don’t wake
up until today, until 2016. And you look around
at the web today, and it looks pretty
different from the way things were in 2010, right? Today we have things like add
to home screen, which lets sites behave more like apps. And we have push
notifications, which help you keep engaged with your
users, keep them coming back. And we have cool new APIs
like device orientation, and geolocation. All these cool
things around today that let you build progressive
web applications, that let sites do all of
the cool things today that they really couldn’t
have done in the past. So these things are
very powerful features, but they’re also a
lot of responsibility. Take geolocation as an example. If a site knows
where I am, it also knows where I work, where I
live, where my friends live, maybe where my children go to
school, where my doctor is. That’s a lot of stuff for a
site to know about me, right? So if you woke up in 2010 to
find this very powerful web, you might be surprised to
learn that there are still websites out there
where you can make a purchase with your
credit card or send a private message to
a friend or research a sensitive medical
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
learn that there are still websites out there that
spend tons of money and time and energy crafting the
perfect user experience only to deliver that
perfect user experience and have some ISP
or Wi-Fi provider or some other
intermediary inject really ugly obnoxious ads like this. And this isn’t a hypothetical. We actually see major ISPs doing
this ad injection all the time. And if this was your site
you’d probably be pretty upset because this interferes with
that perfect user experience. It might be disrupting
your revenue streams by blocking your own nice ads. And worse, it might
actually trick your users into downloading and installing
malware on 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 with 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 bare minimum security
that we’ve come to expect from any site on the web today. So this green lock signifies
three main security properties. First, 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 fake site who’s
pretending to be google.com. When you type an URL
into your address bar, the browser gets a proof
that that’s the real domain you’re talking to. Next, 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, and
not any other friendly person 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 see is what
the other party receives. So an intermediary
in the network can’t modify or tamper with
the data that’s being sent. Only the browser
and the server can. And that’s what
we get from HTTPS. But you might also have some
other associations in your mind with HTTPS. When you see this
green lock, you may think that it represents
a financial burden or a performance cost
or a lot of maintenance or it’s really
difficult to set up. And many of these
associations actually were true 10 or 15 years
ago, but many of them are no longer true today. And that’s because people
all over the world and all throughout the
web ecosystem have been interested in promoting
a safe future for the web where HTTPS is everywhere. So in this talk,
what I’m going to do is tell you four
stories about HTTPS try to separate
fact from fiction, show you what might used to
have been true in the past, but is now becoming a
bit of an HTTPS myth, and try to convince
you that HTTPS is both possible and important
for every site on the web today. So my first story is about
a web developer named Alice. And Alice runs an
online travel guide. You can see it here. It’s a very cool
awesome travel guide. But it doesn’t have any privacy
or security sensitive content like it doesn’t
have a log-in page, you can’t make any
payment transactions. And so Alice doesn’t
think of her site as something that
would require 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, because that’s the
way I built it to be. So she goes to her
friend’s house, and she checks out
what’s going on. And you can probably
guess what’s happening. She sees a bunch of
terrible slow ads plastered all over her site. So this is ruining
the experience that Alice has
built. It covers up her own lightweight,
unobtrusive ads. And Alice’s friend
trusts Alice’s site, so she clicked on these
ads, and when she did, she didn’t expect to get the
malware that she downloaded onto her computer. And this is natural, right? A user who sees
terrible ads on a site blames the site for that
terrible experience. So Alice is pretty sad about
this as you would be I’m sure. And to console
herself she starts working on a new feature. And let’s say this new feature
is using the HTML geolocation API to suggest fun
travel stuff to do based on this user’s location. But as she goes to
implement this feature, she goes to try
it out in Chrome, and she sees that
it doesn’t work. And the reason that
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
support for powerful features like geolocation 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. If I’m going to trust Alice’s
site with my location, I need to know that I’m talking
to the real Alice’s site not some other site
pretending to be Alice’s site. So we need that identity
property of HTTPS to be sure that when I grant
a site access to my location I’m actually talking to the site
that I trust with my location. So 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 non-secure HTTP, and there are a few more that
are coming down the pipeline. I want to call out
AppCache specifically which is coming up next,
and longer term EME. We actually don’t have specific
public timelines for these yet, but they are coming up next. And we’ll be sure
to be responsible when announcing timelines. We’ll add a notification
in Chrome dev console. But if you are relying
on AppCache or EME over non-secure
HTTP, we encourage you to start
thinking about HTTPS now before it
becomes an emergency. So what about service workers? Service workers are amazing
as you’ve been hearing today. My love for them
is represented here by these sort of bizarre blobby
Android heart eyes emoji. They’re the secret superheroes
behind progressive web apps that enable performance in
the face of sketchy network conditions. Service workers sit between
the browser and the network, so they actually manage every
request that comes through. And as you can imagine,
Alice as a site owner needs confidence that she is
the one managing those requests. They’re not being controlled
by some other super friendly person on the network trying
to enhance your browsing experience. And this is why service
workers require HTTPS. So Alice realizes
after all that that in order to build a progressive
web app with the features that she wants, and
in order to guarantee that the user
experience she builds is the one her users receive
she needs to use HTTPS. And this is why
we think that it’s important for every site on
the web today to use HTTPS even if the site
doesn’t seem immediately privacy or security sensitive. So this story is fiction. Our next story is
about performance, and a data driven
guy named Bob who’s done some careful
testing, some A/B tests, and he has found that
reducing latency, reducing the time it takes for
a user to load a site is crucial for optimizing
conversions on his site. So the faster his page loads,
the more money 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’ve recently published a
blog post describing their move to HTTPS, and what’s
interesting is that they did experience some
negative performance results. And on the other hand,
Google moved Gmail to HTTPS way back in 2010
with basically a negligible performance impact. So Bob is wondering
what’s going on here. What’s the discrepancy
between these two stories? So let’s dig into some of the
reasons for this discrepancy, and try to figure out how you
can move your site to HTTPS without a performance hit. First, let’s look
at a simplified view of what it might take to
send an HTTPS request. And here, I’m highlighting some
of the network latency imposed by the extra round trips
between the browser and the server created by
using HTTPS on your site. So first, there’s
an HTTPS redirect. If you follow a link
to an HTTP page, the Siri says, actually, that’s
moved to the HTTPS version. Next, the browser
and the server do what’s called a TLS handshake
where the server presents that cryptographic
proof of identity which is called a
certificate, and that sets up the HTTPS connection. And finally, the
HTTPS request is made. So it turns out that
if you dig into what it takes to
communicate over HTTPS there are some technical
optimizations that you can do to reduce latency. So let’s step
through this again, and see what we can do
to optimize at each step. So first, there’s that
initial HTTP redirect to the HTTPS site. Strict transport
security, or HSTS, is an HTTP header that
helps you avoid redirects from inbound HTTP
links to your site by telling the browser only
access my site over HTTPS for some period of time. And you can set this
period of time yourself, and you’re committing
to supporting HTTPS for that period of time. And so HSTS helps
improve performance by avoiding that
redirect round trip. So the next two
round trips are used to set up the secure connection
over which the browser will send the HTTPS requests. And this is known
as a TLS handshake. So let me interject
here for a moment to tell you that as
a product manager and an all-around
friendly person I shake a lot of people’s
hands, and there are some really terrible handshakes out there. First, there’s that
bonecrusher handshake, which just cuts off all
circulation to your fingers. And then there’s the sweaty
palm which is just brutal. There’s kind of the dead fish,
which honestly just makes me depressed. But the worst kind of
handshake is the person who grasps your hand, and
kind of shakes it, and then just looks at you,
and continues shaking, and keeps looking at you, and
keeps shaking and shaking. Because it’s just
incredibly awkward, and it just takes
such a long time. So the moral of
this story is you have to make your handshake
as short as possible to get on to the
really interesting part of the conversation. So normally, the
browser and the server are doing one of these
long terrible handshakes. And the browser is waiting
for this TLS handshake to be completed before it
sends the HTTP requests. But this is actually
not necessary. You can actually remove
handshake latency by sending the HTTP request
in the middle of the TLS handshake. So after the certificate is
received from the server, but before the TLS
handshake is completed. So it will look like this, and
this is called TLS False Start. And you can turn it on
in your server software and it removes a round trip
from the handshake latency. And if the browser and the
server have spoken TLS spoken, the browser can
remember a session ID. And the next time it goes
to make a TLS connection, it sends that session ID which
allows the browser to shave off part of the TLS handshake. And this is called TLS
session resumption, and it also allows you to
shave off a round trip. And if your server supports
it, you should turn it on. So now that we’ve talked about
optimizing that first redirect and optimizing some of the
round trips in the handshake, let’s talk about sending
the actual HTTP request. And this is where
things really get cool, because this is
where HTTPS unlocks some pretty dramatic
performance improvements in the form of HTTP/2. This is the next
version of HTTP which is now supported in
many browsers including Chrome and Firefox. And using HTTP/2, you
can do really cool things like multiplexing and server
pushing which majorly optimize performance for HTTP requests. And [? Serma ?]
is actually going to give an awesome
talk on HTTP/2 that dives into these details
right after this talk. So please stick around
for it if you’re interested in more details. So I mentioned that HTTPS
unlocks the massive browser performance wins
of HTTP/2 and what I mean by that is that browsers
have said they are only going to support HTTP/2 over HTTPS. So if you want to use HTTP/2
you have to use HTTPS. There’s a practical reason for
this, and it’s compatibility. There are some
intermediaries like proxies that are likely to get
confused or in some cases actually
break things if they see HTTP/2 traffic
because it just looks so different from
normal HTTP/1 traffic. So we need the confidentiality
guarantees of HTTPS to be able to support
HTTP/2 without actually breaking anything. If we go back to yell.com,
online business directory that Bob wrote about, and was
unhappy to see that they had negative performance
impacts from moving HTTPS, it turns out that most of
their performance impacts were mostly due to
outdated load balancers that they couldn’t
update at the time, and they couldn’t
actually turn on HTTP/2. But they’re planning to upgrade
to HTTP/2 in the future. And we have hope for
yell.com because of stories like weather.com saw
small performance impact from moving to HTTPS. But it was then majorly
blown out of the water by the subsequent performance
wins of moving to HTTP/2. In the end, since Bob
is in a position where he can update his
server software and turn on some of
these optimizations, he shouldn’t see any
performance impact from HTTPS. And if he does, he should
be able to far outweigh it by moving to HTTP/2. So we have to update
the way that we talk about HTTPS and performance. HTTPS is now necessary
for achieving the best the web can offer
and HTTP is underperforming. So how many of you
work at startups? All right. A few? Awesome. So my next story is
about a startup that might be something like yours. So Charlie has an idea. It’s about messaging
with friends on the web, and she raises a bunch of
venture capital funding for it. But these days,
Charlie’s startup is kind of running out of
money, and the VC market has gotten a little bit tighter. So she needs to make sure that
every dollar she’s spending is going to a good cause. And she’s heard that
HTTPS costs money, maybe money that she can’t afford. Now, money is sort
of part of all of these stories in
some way or another. I talked about performance,
which kind of boils down to money. And next, I’ll talk about ad
networks, which is about money. But in this story, I’m going
to focus on two aspects that Charlie is particularly
concerned about. Those are certificates
and search ranking. So first, these
cryptographic proofs of identity– certificates. When you need to
get a certificate, traditionally you buy
it from an organization called a certificate authority. You prove your identification
to the certificate authority, and it gives you a
certificate that you use to prove your
identity to browsers. And you might wonder how
much these certificates cost. While it’s certainly possible
to pay a lot of money for certificates, you
certainly don’t have to. A project called SSLMate
has for many years now been offering standard SSL
certificates at 16 bucks a pop. And you can also get one of
their more advanced options, multi host SSL or
multiple certificates. And even if you
need one of these, it really shouldn’t
break the bank. And there’s a newer
project called the Let’s Encrypt,
which actually offers free certificates. And both of these projects–
SSLMate and Let’s Encrypt– offer automated
command line tools that help you buy and
manage your certificates automatically. So they don’t expire, you
can set up configurations, other 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’s worried about is search ranking. You can imagine that if you
move your site to HTTPS, search engines might
get kind of 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. So Google, in particular,
has a few best practices that you should follow
when moving your site, and here I’m going to
talk about the basics. So the first thing you should
do is serve 301 redirects to show search engines that your
site is at the HTTPS version. And once a search crawler
gets to the HTTPS site, it’s important to serve
these canonical link elements to reinforce the idea that
this is the canonical version of your site. And there are a few
other best practices that you should follow. Three are up here, and I
encourage you to go check out these resources after the talk. So if you do your research and
follow these best practices, you can expect a
minor fluctuation in search ranking which
happens any time you make large changes to your site. But you’ll then recover
back to your normal levels that you had before
the transition. In fact, Google even does
have a search ranking boost for HTTPS sites, so
it’s actually considered a positive ranking signal. At present it is pretty
small so you probably won’t notice a large
boost, but it’s possible. We’re hoping that might
change in the future, and it is a small
positive signal now. So in other words, if you
follow best practices, take a little time to do research
before moving your site over, the financial cost for
certificates and search rankings should be negligible. My final story about HTTPS
is the story of Francisco and his adventures with
third party content. I’m sure that many of you
have lots of third party dependencies on your site. So let’s say that Francisco runs
the website for a major news corporation, and
that means he has a large site with a lot of
articles, a lot of legacy content, many different
types of third party content to worry
about like old images. And he’s heard that
if you move to HTTPS, all of your content including
the third party content also has to be served over HTTPS. 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 also have to
start to think about whether all your
third party content is available over HTTPS. First and foremost, Francisco
is worried about ads because he runs a
publisher’s site and ads is how he
makes all of his money. So Francisco is
wondering whether his ads will be available over HTTPS. Well, something that has
changed in the last year or so is that for Google AdSense
and Ad Exchange requests, they’re always served
over HTTPS for most users. So even before Francisco has
served his site over HTTPS, his Ad Exchange or
AdSense ads are already being served over
HTTPS for most users, so he shouldn’t have
to worry about this. And the exception here,
why I’m saying most users, is actually only
for users located in countries that actually
block or degrade HTTPS traffic. And this isn’t just
a Google thing. It’s actually an
industry wide trend. In 2013, the IAB, the
Interactive Advertising Bureau, published this blog post
saying that nearly 80% of their member advertising
systems support HTTPS. And they underscored
their commitment to getting all the
way there to 100%. So this is one of
those things that I talked about where 5,
or 10, or 15 years ago, pretty much no ads were
being served over HTTPS so this was a major issue. But now the entire
industry is changing, and in this day and age,
serving ads over HTTPS really shouldn’t be a blocker. And if you’re using an ad system
that doesn’t support HTTPS yet it’s probably on the
roadmap, and if it isn’t you should ask them why not. And you should tell
them I said why not? So the next type of
third party content that Francisco is worried
about is the partnerships that he has with other sites
that depend on the HTTP refer header. And what this means
is that other sites can tell that the traffic
came from Francisco’s site. In other words, Francisco’s
site has referred the traffic to those other
sites so Francisco might get some money for this. And the problem here is
that if a user follows a link from an HTTPS site
to an HTTP partner site, browsers will strip their refer
header for privacy reasons. And that makes sense,
because if you’re doing something sensitive
on an HTTPS site, the URL that you’re on might
be sensitive information and the browser shouldn’t
just leak that in plaintext over the network
to an HTTP site. Fortunately, there’s
a web platform feature called Referrer Policy
that helps with this. And Francisco can
set a referrer policy to allow his partners to
see that traffic is coming from his site, but they
won’t see the full year URL that the user was visiting
so user privacy is still somewhat protected. Finally, Francisco
is losing sleep over a kind of general
problem called mixed content. And mixed content is the problem
of loading non-secure HTTP content on an HTTPS. And this is important because
non-secure sub resources can actually compromise the
security of a secure HTTPS site. So if you try to load
insecure scripts or iframes or other active content
like that on an HTTPS site, browsers will actually block
it because that content is just too powerful and
would completely wipe out all the security
of that HTTPS site. So Francisco’s site,
it’s a news publisher so it has lots of
old news articles that link to third
party images that aren’t available over HTTPS. And we call these images passive
content and browsers will still allow them to load. So the site won’t be
completely broken, but that green
lock does go away. And Francisco’s really
not happy with this because he wants his green
lock that he worked hard for. Fortunately, Francisco
can serve what’s called a content security
policy to receive reports about mixed content. 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 mixed content on all of his millions of pages. Which means that he doesn’t
have to rely on users to report broken behavior. He’ll be able to find and fix
problems as soon as they arise. So in this case, the
CSP says, all content should be loaded with
the HTTPS scheme, but in-line and dynamically
generated scripts are OK. And send a report
to this URL whenever content violates this policy. But don’t block
content, only report it. And if you don’t want to build
infrastructure to collect reports yourself I suggest
this awesome service called report-uri.io which gives you
some cool data visualizations. And for all of these
issues, in Chrome we recently launched the
DevTools security panel to make it as easy as possible
to find and fix problems with HTTPS configurations
such as these mixed content problems. So Francisco’s story 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 of these new tools
and support in the ecosystem and in the web platform to help
you upgrade your third party content. So when I look back at these
four stories about HTTPS that I’ve told you
today I think there’s one kind of moral that emerges. And that moral is that
five, 10, or 15 years ago, HTTPS used to be 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,
the whole wild, wild west of the online advertising
ecosystem, all these people have come together to make
HTTPS a lot faster, and easier, and cheaper, and all around
better than it was in the past. And HTTPS is necessary
for unlocking the best the web has
to offer in terms of both capabilities
and performance. And that’s why we think it’s
both possible and really important for every site
on the powerful web today to use HTTPS. [MUSIC PLAYING]

Danny Hutson

Leave a Reply

Your email address will not be published. Required fields are marked *