PARISA TABRIZ: Thank you.
Thank you.
OK, 30 minutes to lunch.
We can do this together.
So my talk is called "got ssl?"
As you guys know, more people
are connected to the web today
than ever before and
from more places.
So we're connected with
our laptops and our phones,
our tablets probably
soon enough,
with personal devices
and accessories.
And we access the internet from
untrusted and sometimes even
hostile networks.
With so much of our
lives moving online,
it's imperative
we're taking steps
to protect our data
and our users' data.
So this talk is my call to arms
to all of you as developers.
And in the next
30 minutes, I hope
to convince you about the
necessity and practicality
of SSL, and then give
you some pointers
to show you how to
actually make that happen.
So this is probably a
good place to start.
What's SSL?
It stands for Secure
Sockets Layer,
and it's a cryptographic
protocol designed
to provide communication
security over the internet.
I imagine a lot of
people have heard of it.
I'll just still
do a quick intro.
It guarantees
privacy, and it does
this via encryption
and integrity.
So this prevents somebody
from snooping or tampering
with the internet connection.
It's had its share of
security flaws over the years,
but it's the leading and
primary way today and really
the only way to ensure any
kind of data communication
security on the internet.
There's a couple
of acronyms that
are thrown around
interchangeably.
So very quickly,
I'll clarify these.
TLS, if you've heard of it, is
for most intents and purposes
the same as SSL.
You can consider them synonyms.
If we want to be precise,
SSL 3.1 was renamed to TLS.
SSL was the original name of
the specification when this came
out in the mid-'90s
from Netscape.
And TLS is the
IETF Standard name.
But they're interchangeable.
I will refer to the protocol
as SSL throughout this talk.
And then HTTPS is HTTP over SSL.
And I imagine most people
are familiar with this, too.
It's actually not a protocol.
But it's really
just the layering
of the security capabilities
of SSL and standard HTTP.
So if you're into
internet protocol stacks,
this is how it looks.
I'll leave it as an
exercise for all of you guys
to read about the specifics
of the SSL protocol.
But you should know that
it consists of two phases.
So there's this
first initial phase
between the client-- often
case your browser-- and the web
server.
And this is based on
public/private key
cryptography.
This initial part
of the protocol
is a handshake, which
is used to create
a shared key, a shared secret.
And this shared secret is used
by the second part of the SSL
protocol to actually encrypt
the communication of a session.
So networking on the
internet feels safe, right?
We open up a browser.
We send a request
to load some page
in sort of the
comfort of our device.
The response page is
delivered back to us.
It feels like it's immediate.
It's fast.
It feels like we're talking
directly to the website.
But in reality, we
know that it's not
like this direct connection.
And if you serve data over
plain HTTP between your browser
and the server, you have
absolutely no guarantees
that the data that's been sent
from your client to the server
has not been tampered with or
snooped by some person that
has access to the
network along the way.
So I'm sure people are
familiar with the comic XKCD.
It's really hard for
me to do a presentation
without including some
comic, because there's
just always something relevant.
I'll give people a second
to note our (Wo)man
in the Middle on the
open Wi-Fi network.
She's performing a
man-in-the-middle attack.
And as the name of
the attack suggests,
this is when an attacker
places himself or herself
or their malicious software
in between a victim
and a valuable resource.
And in today's talk, I'm going
to say that's your website.
So there are almost always
a few places someone
can access the network
between a request coming
from a browser and
the actual web server.
So, for example, who's on
Google Guest right now?
I imagine there's a couple
people-- OK, lots of people.
So this is going
through the Wi-Fi router
that's run by Google.
I don't know who it's run by.
Maybe you do, and
maybe you trust them.
But then it's going on to
some ISP and potentially
other intermediate
proxies between you
on your laptop or your
phone and that site
and then through all those
hops on the way back.
And if you are using HTTP,
this is an entirely clear text
protocol.
Again, you have no guarantee
that this data has not
been logged or tampered with.
That's going to be the
meme through this talk.
Do you know or trust the people
that run each one of those
hops?
If not, you should be concerned.
So even more depressingly,
even if you want HTTPS,
you can actually still
run into some issues
if the site doesn't avoid
some common downgrade
vectors from HTTPS to HTTP.
Users very rarely type in the
full URL, the scheme HTTPS
and the URL of where
they want to go
when they want to
visit some site.
So these things end up
automatically-- you're
either being
redirected by the site
or you're clicking some
link and going there.
And all of these
are opportunities
for downgrade attacks.
I'm going to talk
at the end about how
to actually avoid those.
But the internet
is a scary place.
I'm going to go over just two
tools that make these types
of man-in-the-middle
attacks really easy.
I encourage you
to check them out.
Maybe someone is running them
in the audience right now.
But the first one
is called SSLstrip.
So man-in-the-middle attacks
have been known about
for a really long time.
This tool came out
in 2009, just as kind
of a proof of concept
of how easy these
are to actually mount.
But what SSLstrip does
is it exploits the fact
that often sites
are still sending
some requests over HTTP.
As I mentioned, most people
don't type it directly
into the browser.
They're either clicking
a link or actually
getting redirected
from the site.
So there's this window of
opportunity for somebody
to man-in-the-middle and
actually replace outbound links
that are intended to be
HTTPS with HTTP in back.
And also it does some
homograph-style URL
replacement.
And it even throws
in a lock icon.
So people that are looking for
that as a sense of security
get that warm, fuzzy
feeling, but unfortunately
without the security.
SSLstrip came out in 2009.
One that got quite a
lot of broad attention
was called Firesheep.
This one came out the
following year, in 2010.
And it was much more usable
from the attacker standpoint.
You had a nice user interface.
So that's probably why it got
a little bit more attention.
Firesheep was a passive
man-in-the-middle attack,
and then it just listened
to an opened Wi-Fi network
for cookies that were
being sent in the clear,
authentication cookies.
And then it would pop
up people's accounts
that it was able to hijack.
And you could just click on
them and automatically listen in
on someone's chat or log
into their Facebook account.
So a site without SSL
is telling its users
that they don't care about
their privacy and integrity.
So in the '90s, HTTPS was
mainly considered something
that the banking
industry had to consider.
But it's just not
about banking anymore.
And serving over plain
HTTP is totally insecure.
Leave with that message.
Neither the browser
nor the server
can trust any of the data
that's sent over HTTP.
And this is a sad state for
users and site operators
as well.
And we know it's not
just a plausible risk.
So we have evidence of both
targeted and large-scale
government-run
snooping operations.
[LAUGHTER]
PARISA TABRIZ: Awkward laugh.
If you care about the privacy
and integrity of your users'
data, you need to be using SSL.
I would even go so
far as to say if you
don't care about the privacy and
integrity of your user's data,
how interesting is the
app that you're writing?
There are very few
exceptions that I
can think of where this should
not be seen as a requirement.
OK, so hopefully, you
guys all want SSL now.
So time to get it.
And I will continue
my sales pitch
by saying that SSL is fast,
cheap, and easier than ever
to get, which is good news.
So on my slide, I have a
quote from Adam Langley, who
works at Google and has done
a tremendous amount of work
getting SSL support at
Google and then kind
of across internet.
One of the most common excuses
that I hear from developers
about why they don't have SSL
is the performance and cost
impact.
And to be fair,
10 years ago, this
was a legitimate
concern and complaint.
I mention this first
part of the SSL protocol.
You do public key
cryptography, and this
is expensive computationally.
All of the cost is
in its handshake.
After that, it's never really
been too much of an issue.
10 years ago, this required
dedicated hardware.
It's not the case today.
This quote was from
2010, when Google started
supporting SSL for Gmail
by default for all users.
And it required no
additional hardware
and really had a very
limited performance impact.
So it's not too expensive.
Running an application
over SSL is really
no different from
communicating directly on TCP.
So there's very few
application modifications
you need to do as far
as performance goes.
You'll want to check
out operational pieces
to actually SSL deployment,
like how and where you deploy
your SSL servers, and record
size, and memory buffers,
and a lot of little
configuration things,
which I'm not going
to go over today,
but which there's a really
good reference for in this book
that I have linked.
They're sort of links sprinkled
throughout the slides,
if anything is interesting.
This book "High Performance
Browser Networking"
is by Ilya, who I think
spoke either earlier
yesterday or a speaking today.
And it has a great
checklist of things
that you'll want to
consider when deploying SSL.
And it's free.
So again, no excuse.
SSL is not a
performance hindrance.
It's also free!
So you can get free
certs from StartSSL.com.
This is just one that I've used
and I know other people use.
You can get free for
noncommercial uses.
If you have a commercially
use, it's something like $60.
So it's cheap.
And we have it.
It's fast.
It's cheap.
And I'm even going
to go as so far
as to say that SSL
is easy to deploy.
It's deceptively easy
to deploy, in fact.
So there's a couple of mistakes
that people need to avoid.
But there's a
really useful guide
that's put out by SSLLabs.com.
And it goes over
all of the things
that you need to do in detail.
And more importantly, it
has an automated tester,
so you can actually check
that you did everything right
and fix all the mistakes,
and then feel confident
that you're getting
all these things right.
So SSL is fast, it's
cheap, it's easy.
Get it, and then
let's get it right.
So you can test
for your actual SSL
deployment using SSLLabs.com.
But I want to go over a
couple of the application bugs
that I see most commonly.
So all sites fall
into three categories
when it comes to SSL adoption.
There are the sites which
don't offer it at all.
For HTTP-only
sites, users should
expect absolutely no security.
At least they know
what they're getting.
Then there's sites that
only serve exclusively
over HTTPS or on SSL.
And in this case, users should
expect private and untempered
communication for the
most part, barring
any bugs we don't know about.
And the world is a happy place.
And then there are the sites
that intentionally or sometimes
even inadvertently are serving
both over HTTP and HTTPS.
We call this mixed content
or sites with mixed content.
And this is where we
run into some problems.
So unfortunately,
situations where
you're serving some of
your site or some resources
that you're fetching over HTTP
can lead to downgrade attacks.
If you can avoid the
situation, you should do it.
If not, and this is the
case for a lot of sites,
you're going to need to take
some extra considerations
into account.
So as I said, if you're
serving anything over HTTP,
you need to take some
extra steps to avoid some
man-in-the-middle attacks.
These are specific classes
of man-in-the-middle attacks,
so I talked about
downgrade attacks.
You can also leak cookies.
If anybody can
tamper the data, they
can inject script
and actually do
a cross-site scripting
attack and render
script which kind of
uses whatever security
you would have gotten with SSL.
Even if you don't
care about security,
you need to care about
mixed content bugs,
because browsers
are going to make
the experience for
your users worse.
So as of Chrome 29, Chrome
blocks mixed content
that is coming from an iFrame,
JavaScript, cascading style
sheets, and plug-in
loads by default.
Firefox has similar behavior.
And you can see in
the top bar, that's
what the Chrome bar looks like.
If a user tries to visit
your site over SSL,
but you have any kind of active
content being served over HTTP,
it's not going to
load by default.
And they're going to actually
have to click to load.
So your page is
probably going to break.
Your user's going to
be annoyed because they
have to press a button just
to get the page to work.
And that sucks.
Also, browsers block other
types of content like images--
or they don't block them,
but you automatically
lose your green icon.
So you lose that warm,
fuzzy kind of assurance
to users that you care about
security, because you're
serving some mixed content.
You'll see a little warning in
Chrome that you can click on.
So as I said, even if you
don't care about mixed content,
for security's sake,
you should care about it
because users are going to get
a degraded experience when they
visit your sites, at least
in Chrome and Firefox.
So how do we actually
fix mixed content bugs?
Thankfully, it's fairly easy.
What we need to do is make
sure that all of our resources
are loaded by HTTPS, that
are loaded on a HTTPS page
by HTTPS.
So if these resources
are on the same domain,
you can just use relative URLs.
If you have to use
an absolute path,
you want to omit the
scheme or the protocol,
and the browser will
figure it out by itself.
In the second
example, I actually
include an example of a
scheme-relative URL, which
can look kind of funky if
you've never seen it before,
but it works.
So that's how you fix
mixed content bugs.
Not too hard.
Mixed content is a big
one, maybe, arguably,
the one that's a little bit
harder to fix because there
may be multiple
instances of this.
But another really common
application bug that I've seen
is not preventing sensitive
cookies from leaking over HTTP.
So if your cookies
are sensitive--
and in a lot of cases, they are.
They're doing something
with authentication or safe
preferences-- it's
imperative that you ensure
they don't get sent
over an HTTP connection.
And to do this,
you have to ensure
that you have the secure bit
set on your site cookie header.
It's unfortunate
that it requires
that, because a lot of
apps have missed that.
And this is actually
how Firesheep worked.
It relied on the fact
that a lot of sites
were not setting sensitive
cookies with a secure bit,
and they're easy
to sniff and used
to hijack people's accounts.
So a recent
interesting development
in the wild world
of SSL is something
called Strict
Transport Security.
This is a mechanism that
allows websites to opt
in for HTTPS-only rendering
and also strict HTTPS
start validation.
So the first tool
I mentioned, called
SSLstrip, it exploited the
fact that most people don't
type in HTTPS when
they visit a site.
They're typing just the domain
name or clicking on a link
or going to some bookmark.
And in that case, there's a
small window of opportunity
where the user makes HTTP
request that someone's allowed
to man-in-the-middle.
So Strict Transport Security,
or HSTS, as it's abbreviated,
attempts to address that threat.
Once this header is
saved in the browser,
it's going to bump up
automatically all HTTP traffic
to HTTPS.
And it will reject
any attempts to visit
that site over a
non-encrypted channel.
So this is actually really good.
I'm seeing more
sites adopt this.
There's still a very, very
small window of opportunity that
an attacker can
man-in-the-middle,
where someone's just
installed the browser,
and they actually don't
have this header set yet
by the application.
So Chrome and Firefox
actually come up
with some hard-coded
sites that have
elected into always using HSTS.
Some examples are
Twitter, Paypal.
There's Google Sites
on there and LastPass.
If you as a developer
want your site
to only be ever
accessed over SSL,
you can actually
just file a bug.
If you visit the
link on the slide,
you'll get all the
right contacts.
And we can include your site as
well in this hard-coded list.
But that's Strict
Transport Security.
Another cool and
even more recent
development is something
called Public Key Pinning.
So Public Key
Pinning is designed
to give website
operators a means
to restrict which certificate
authorities can actually
issue certificates
for their sites.
So this feature's been deployed
for Google Chrome for a while,
and it has proven to
be useful in preventing
attacks and actually making
the public aware of them.
So if people-- you potentially
heard about on the news
how there was a Dutch
CA that was exploited
in issuing forged
certificates for Google.com.
It was believed
that hackers were
targeting Iranian citizens.
Cert pinning is the feature
that actually allowed
us to detect these forged certs.
So there are two proposals
being worked on right now
to try to make this a standard.
And we're hoping
that that happens
and that other
websites can actually
use the public key pinning
feature at some point.
So I've spent my
entire time talking
about how awesome
SSL is, but I do
want to make sure people
leave with a totally
accurate impression of
what this gives you.
Because SSL is not a
security silver bullet.
It's good.
You need to do it.
It's not security magic
dust, and the only thing
you have to do.
So go over a couple disclaimers.
So first SSL-- it
doesn't actually
guarantee 100% privacy.
So we're piggybacking HTTP
entirely on top of SSL.
So we know that all
of that is encrypted.
We get the request
URL, query parameters,
contents of the page,
headers and cookies-- all
that's encrypted and private.
So this is good.
But SSL is working on
top of the TCP layer,
which requires IP
address and port numbers.
So these are necessarily going
to be leaking to somebody
who's listening on
an open network.
And also, while you can't
infer the actual contents
of the communication,
you can still
infer the amount and duration
of the communication.
So you're potentially left
open to some kind of traffic
analysis or pattern
analysis attacks.
And in very specific
services, it's
been demonstrated
that you can infer
something useful from this.
And people have countered
this with padding attacks.
But the reality is this
is just not something
that the vast majority
of applications
are going to need
to worry about.
But you should know that there
are some information side
channels that are being leaked.
So also, as I said, SSL
is a transfer protocol,
so attacks at other layers
are not going to be prevented.
So in particular,
IP level threats,
a denial of service attacks,
or any kind of network spoofing
attacks, they're are
not protected by SSL.
And then also, you'll have to
consider other web application
vulnerabilities.
If you've heard of cross-site
scripting or SQL injections,
these things are
prevented by SSL.
So you still got to think
about that, but that said,
SSL is the best
thing we have today
as far as protecting
users' communication, data
communication, and ensuring
any kind of level of security
for your site and your users.
So earlier this week, a couple
of days ago, the EFF published
this article with associated
info graphic about
SSL's adoption from the
list of companies in their
"Who's Got Your Back?" program.
So the program
are companies that
have committed to preventing
unlawful government
access to their data.
I think it's interesting.
Go Google, go Twitter, go
Dropbox and some other ones
that are getting five stars
across the board for what
they're doing.
But I think this is interesting
for people as a user.
You should check this out.
And you should be demanding
SSL for the services you use.
So file bugs,
chime in on forums,
and grab your
digital pitchforks.
Demand SSL for what you use.
And provide it for users, too.
This is another cool project.
It's called SSL Pulse,
and this project
aims to measure the
effect of security of SSL
across the internet.
So they look at about
200,000 SSL-enabled websites
from Alexa's list of
most popular sites.
They refresh their
data every month.
And this is just two graphs.
I encourage you to
check out the project,
because they show a
lot of other statistics
about where we're at SSL-wise.
And they kept the same
methodology and sample approach
for the past two years, so you
can kind of see trends in SSL.
A year ago today, November 2012,
we had about just under 15%
of SSL adoption.
So it's really cool
to see that we're now
over 50% adoption, at
least in these top sites.
But we need your help to
help push that even further.
And yeah, that's it.
I hope you're not
just hungry for lunch,
but hungry to get SSL working.
I promise you that if you're
not enjoying the summit or need
something to do
this evening, you
can get SSL set up on a personal
site for free-- startSSL.com--
in less than an hour,
and that's while you're
chatting with your friends and
like eating a bag of chips.
Test it out.
Get it working.
Get SSL.
[APPLAUSE]
