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