WWDC2017 Session 701

Transcript

[ Applause ]
>> Good morning and welcome to
your Apps and Evolving Network
Security Standards.
My name is Bailey Basile and I'm
secure transports engineer at
Apple.
Today, my colleague Chris and I
will be talking to you about the
ways that network security
standards change and how that
affects you and your apps.
We know that all of you care as
much about your users' privacy
and security as we do.
And that's why when you see
attacks like BEAST, and CRIME,
and DROWN, you worry about
whether your app is affected.
Unfortunately, all protocols
age, and as they are in the
public more attacks are found
over time.
Even worse, the algorithms upon
which these standards rely have
a built-in shelf life.
That means that as they age and
as computers get faster, those
algorithms become vulnerable to
attacks like collisions,
factorization and brute force.
When you hear about these scary
sounding attacks like a FLAME
and BREACH, and POODLE.
Well, maybe poodle doesn't sound
so scary.
When you hear about these scary
attacks, you wonder what you can
do to prevent your app from
appearing in the press the next
time a big attach happens.
And that's why today, I'm going
to be talking about some best
practices that you can follow in
order to ensure that your app is
not affected.
I'll also talk a little bit
about how Apple helps you by
removing insecure options from
our platforms.
Chris will then give you an
update on app transport
security, which is a mechanism
that you can use in your apps in
order to ensure that best
practices are enforced.
Finally, Chris will be giving
you a talk about Transport Layer
Security, or TLS and an exciting
new evolution in that protocol.
So, let's dive right into those
best practices.
I'll start at a high level.
First, the biggest thing you
have to remember, because as I
said, those protocols age, and
those standards have a built-in
shelf life, you can't set and
forget the security of your app.
You have to go through on a
regular basis and make sure that
your app is up to date.
And to know what to change, you
should be following standards
bodies, academic research and
industry best practices.
But the good news for all of
you, is that you are already
doing this because you're here
today.
If you are a developer or a
library developer, you may be
using a third-party library in
your app.
And those can be very risky.
In particular, if you're
integrating a third-party
library you have to be sure you
keep it up to date.
A library that you integrated
three years ago is already out
of date and maybe using weakened
security.
That means that your users are
not getting the security that
you want.
If you're using our APIs, we
help you here.
First, we remove many of the
insecure options from our APIs
so that you aren't affected.
We also make available App
Transport Security, or ATS, in
order for you to be able to
enforce those best practices in
your app, as long as you are
avoiding ATS exceptions.
Finally, when those attacks
happen, before those attacks
happen you have to remind your
clients, investors and managers
that it is worth the maintenance
cost to update your app so that
when the next attack happens you
are not scrambling to remediate
the problem wasting time and
energy and money as your app
appears in the press named as
one of the bad apps.
So, let's take a look back at
those attacks I was talking
about earlier.
I'd like to go through some
detailed best practices that you
can use to avoid these attacks.
Specifically, in the area of
encryption, cryptographic
hashes, public keys, protocols,
and revocation.
So, let's start right off the
bat with encryption.
Encryption, as all of you know
is a mechanism that you can use
to prevent your users' data from
being read by an attacker.
But unfortunately, some of the
algorithms that we've been using
for encryption for a long time
are vulnerable to attacks where
the key material or the plain
text could be recovered by an
attacker.
In particular, RC 4 is
vulnerable to an attack where
the key is recoverable within as
little as three days.
Furthermore, the CBC modes of
both Triple-DES and AES are
vulnerable to attacks like BEAST
and Lucky 13 that mean that the
algorithm is not providing the
same level of security as you
want your users to have.
We plan to remove both RC 4 and
Triple-DES from TLS across our
platforms in the future.
So, now is the time to upgrade.
Instead, you should be using
authenticated encryption
algorithm like AES-GCM or
ChaCha20/Poly1305.
Those will ensure that you have
both the best encryption and can
detect when that data has been
modified.
Speaking of modified data.
Let's talk now about
cryptographic hashes.
As you know, cryptographic
hashes are a mechanism that
allows you to detect when the
input data has been changed.
But unfortunately, some of the
cryptographic hash algorithms
that we've been using are
vulnerable to what's called a
collision attack.
A collision attack is where two
different inputs produce the
exact same output.
And so, you can't tell when an
attacker has modified the data
because the hashes will be the
same.
In particular, both MD 5 and
SHA-1 have demonstrated
collision attacks.
In fact, an MD-5 collision was
used in the Flame malware in
order to bypass platform
security and gain access to
users' systems.
We removed trust in all MD-5
signed certificates across our
platforms in previous years.
SHA-1 just recently had an
attack.
The Shouted attack was performed
earlier this year, and so this
is the freshest information.
Knowing that the SHA-1 one
attack was imminent, we removed
trust in all SHA-1 signed
certificates for TLS servers
when connecting through WebKit
and Safari.
And we've seen such an
improvement in the disk use of
SHA-1 certificates, that today
I'm announcing that we're
removing trust across all TLS
connections for SHA-1 signed
certificates.
I'll talk a little bit more
about how that affects you and
your app later on.
Instead, you should be using any
of the SHA-2 family of hashes in
order to get that best security
and avoid these collision
attacks.
Next, I'd like to talk about
public keys.
Public keys, as you know, are a
mechanism that provides an
identity, a sort of identity for
you.
Such that other people can
verify that something you signed
was signed by you and not
someone else.
And can be used to send you
encrypted data that only you can
decrypt with your private key.
But unfortunately, RSA key sizes
smaller than 1024 bits are
vulnerable to factorization
attacks.
In particular, a 768-bit RSA key
was factored back in 2009 and
that's why we removed trust from
any certificates using key sizes
smaller than 1024 bit RSA back
in the spring of 2016.
But the reality is even 1024 bit
RSA key sizes are not good
enough.
And we expect that an attack on
a 1024 bit RSA key is imminent.
And that's why today I'm
announcing that we're removing
trust from certificates using
key sizes smaller than 2048 bits
across all TLS connections to
servers.
In order to avoid these removals
and ensure that you have best
security, you should be using
RSA key sizes greater than or
equal to 2048 bits, or any of
the elliptic curves that are
trusted on our platforms.
Next, I'd like to spend some
time talking about protocols.
Protocols, as you know, are the
mechanism that you actually use
to talk to servers.
They are interoperable, which
means that you don't have to
worry whether the server you're
talking to across the world
supports the protocol you're
using.
Unfortunately, some of these
protocols are weak or provide no
security in particular.
If you are using http all of
your users' data is being
transmitted in the clear.
That means that anyone listening
in knows exactly that data.
But some of the older TLS
versions, like SSL Version 3,
TLS 1.0, and TLS 1.1 are also
vulnerable to numerous attacks.
And so, you should be avoiding
these when you configure your
servers.
We removed the use of SSL
Version 3 back in fall of 2015.
So, you've been protected on
that count for a while.
Instead, you should be using
HTTPS, that is HTTP over TLS,
with TLS 1.2.
TLS 1.2 is the current best
standard available for TLS
security.
But I'm pleased to announce
today that we're adding support
for the draft specification of
TLS 1.3.
Chris will be talking more about
that a little bit later.
Finally, I'd like to talk about
revocation.
Revocation is the mechanism that
clients use to verify the
certificate and determine
whether that certificate should
be trusted in the event that a
certificate is mishandled or
missed issued.
And of course, the worst thing
you can do in the area of
revocation is not check it.
Unfortunately, our platforms do
not check revocation by default
currently and I'll explain why
later.
That is, unless of course you
are using OCSP Stapling.
OCSP being the Online
Certificate Status Protocol.
If your servers are using OCSP
Stapling, your certificates are
always being checked for
revocation.
So, let's drill down into how
OCSP and OCSP Stapling work.
First, as usual, a server
requests a certificate from a
trusted third-party called a
certificate authority.
The server then uses that
certificate to identify itself
to clients connecting to it.
The client, in order to verify
that identity, then requests
information as to the status of
that certificate from the
certificate authority.
The certificate authority
replies back with a signed
message indicating the status of
the certificate that the client
is looking at.
The client verifies that
response and then uses that
status to determine whether to
continue the connection to the
server.
But unfortunately, OCSP has some
drawbacks.
As you can see from that
previous description It requires
an additional network connection
for every connection to the
server.
That means that your connections
in your apps appear slower and
none of us want that.
Furthermore, OCSP is performed
in the clear.
That means that all of the
traffic indicating which
certificate the client wants
checked is visible to anybody
watching.
And the reason that OCSP is
performed in the clear is that
it you would need it to
establish a secure connection.
So, if you had to establish a
secure connection to get OCSP,
you might end up in a circular
problem.
That's why OCSP is a huge
compromise of your users'
privacy.
Since all that information is in
the clear.
Anyone who is listening can and
find out what servers that
client is connecting to.
Furthermore, that third-party
certificate authority can
aggregate data as to which IP
address is which clients are
talking to which servers and
sell that to anybody they want.
So, that's very bad.
These 2 drawbacks are the reason
that we do not have OCSP enabled
by default.
And if you wanted to enable OCSP
in your app you would have to
integrate additional APIs.
So, next I want to talk about
OCSP Stapling, which is a
dramatic improvement on OCSP and
an evolution in the protocol
that removes many of the
drawbacks of OCSP.
As before, the server gets a
certificate from the certificate
authority.
But before sending that
certificate to a client, the
server requests the OCSP
response from the certificate
authority.
And when it gets that signed
response back, the server
verifies it and then sends it
along with the certificate to
the client.
The client can then verify both
the certificate and the
revocation status
simultaneously.
So, this is a huge win, both in
terms of performance, because
you don't need that additional
network connection on your
client.
And in terms of privacy, because
the client doesn't have to
connect to a third party to find
out about the revocation status.
But even OCSP Stapling has some
drawbacks.
We've noted that despite
encouraging all of you to adopt
it on your servers, that
adoption has been slow.
We are aware that enabling OCSP
in some of the open source
server implementations does have
drawbacks.
But we, nonetheless, encourage
you to fix those issues and to
adopt OCSP in order to improve
the security and the speed of
your app.
But the worst thing about OCSP
is that it actually doesn't
protect users against malicious
servers.
In particular, the malicious
server just need omit the
stapled OCSP response and the
client will never know that that
malicious server has a revoked
certificate.
That's why I'm pleased to
announce to you today that we
are enhancing revocation across
all of our platforms.
And it starts with us.
First, we gather information
from certificate transparency
logs.
Certificate transparency logs or
CT logs contain cryptographic
proofs of the existence of a
certificate.
You can find out more about CT
and how it works and how you can
use it to enhance the security
of your app by watching last
year's "What's New in Security"
session.
We use the information from the
certificate transparency logs to
find out about all of the
certificates that are trusted on
our platforms.
And if you want to help us
gather information about your
certificates in your apps and
your servers, you should verify
that your certificates are
logged to a CT log.
Many CA's will do this for you
so you just need check.
With that information, we now
know all of the certificate
authorities that are trusted on
our platforms.
And from that information we can
request all of the revocation
information from those
certificate authorities.
We then gather all of that
revocation information back.
We aggregate it into a single
efficient bundle, and then make
it available to all of our
clients.
Those clients check in
periodically with us to get that
bundled revocation information,
and use that latest status
revocation information when
checking server certificates
that they are using.
If the client hits a certificate
that is listed there, the client
will then perform OCSP.
Unless of course your app is
using OCSP Stapling.
The client uses this to verify
that the certificate really is
revoked.
So, we think this is a dramatic
improvement on the existing
state of revocation on our
platforms.
It has a dramatic improvement in
the privacy compromise area.
The bundle that we provide of
revocation information is the
same across all of our clients
and all of our platforms.
So, we never know which clients
are connecting to which servers.
Furthermore, only certificates
that are in that list require
the additional OCSP connection.
So, only the limited set of
certificates there risk that
additional privacy compromise if
your servers are not using OCSP
Stapling.
Another huge advantage is that
the information is automatically
updated.
That means that the client
always have that freshest
revocation information available
to them when making all of their
connections and this means that
you also get this for free.
You don't need to make a single
API call to get this best
practice security and faster
connections.
So, I've covered a lot of ground
in the last 20 minutes and I'd
like to recall what we talked
about.
First we talked about encryption
and using authenticated
encryption ciphers in your
servers and your apps.
We talked about hashes and how
to avoid collision attacks.
We talked about public keys and
using strong public keys that
are not subject to
factorization.
We also talked about protocols
and using the latest protocols
like TLS 1.2 and HTTPS to secure
your apps.
Finally, we talked about
revocation and how you can
improve the security of your app
by using revocation and OCSP
Stapling on your servers, and
the ways in which we've helped
you with a brand-new revocation
mechanism.
Now, I promise you that I'd talk
a little bit more about those
trust removals that I announced
earlier.
Let's go back and recall what
those trust removals were.
First, I announced that we would
be removing trust in any SHA-1
signed certificate for
connections to TLS servers
across all of our platforms.
I also announced that we would
be removing trust in
certificates using key sizes
smaller than 2048 bit RSA, also
in all TLS connections to
servers.
If you are connecting to a
server using TLS that has one of
these weak certificates, your
app will fail to make that
connection on macOS High Sierra
and iOS 11, and watchOS 4 and
tvOS 11.
Let's back up and remind
ourselves what certificates this
trust removal does not affect
based on my description.
First, this does not affect root
certificates.
In particular, root certificates
are not subject to the type of
collision attacks that we are
worried about with the SHA-1.
Also, we already removed all
roots certificates using key
sizes smaller than 2048 bits
back in fall of 2015.
So, you've been protected there
for awhile.
These trust removals also do not
affect enterprise distributed
certificates through mobile
device management or MDM.
It also doesn't affect user
installed certificates through
mail, Safari or keychain access.
Finally, it also doesn't affect
client certificates when used
with mutual authentication in
TLS.
It's not that we're not worried
about attacks on the
certificates, we are.
But we know that it takes time
for enterprises and users to
update all of their certificates
and their infrastructures to use
the latest algorithms.
And so, we're giving them just a
little bit more time.
I promise that we will be
removing trust in those
certificates later on.
So now is the time to start
updating, not then.
Now, you're probably wondering
what this looks like.
Because if it's affecting your
app, you need to know.
If you are in Safari, you see an
error dialog that looks
something like this.
And if we drill into the
certificate pane, we see that
there's a specific error message
for these removed weak
certificates.
And that's how you will know if
you're connecting to such a
certificate.
Now, many of you are app
developers and so you care more
about what you're going to see
in the logs.
Because you may never connect to
this server through Safari.
If you're looking in the logs,
you're going to see an invalid
searching or -9807 SSL error in
your URL session or URL
connection.
There's only one thing that you
can do in order to fix this
problem and that is to have your
server administrators upgrade
their servers to use new
certificates.
The good news is that all
certificate authorities trusted
on our platforms only issue
certificates that are not
subject to these removals and
you can find a list of all of
the root certificates that are
trusted on our platforms at this
link.
So, we've covered quite a bit
more ground now and I think I at
least am wondering what should I
do when I go back to my office.
How can I ensure that I have
best security.
And the very first thing you
should do is check your
implementations, libraries and
servers against those best
practices that I've listed.
We even have that handy chart
that you can use to ensure that
you have those good algorithms.
If you're a server developer you
might actually have quite a bit
of work to do in order to ensure
you have the best security for
all of your clients.
You should go through and
replace any SHA-1 or weak RSA
key certificates so that your
clients will not see failures on
our platforms.
And if you haven't already, you
should upgrade your servers to
TLS 1.2 and one of those
authenticated encryption ciphers
that I listed earlier.
You should allow the client to
determine what order to use
those ciphers because the
clients may be optimizing to use
the best and fastest cipher as
opposed to one of the slower
equally secure ciphers.
If you haven't already should
also enable OCSP Stapling so
that you can be sure that all of
your clients always have up to
date revocation information and
don't have to make privacy
compromising additional network
connections.
Finally, in order to help us
with our new revocation
mechanism you should check that
your certificates are being logs
to a certificate transparency
log.
Now many of you are probably app
developers.
And the good news for you is
that you have only one job.
Our platform has made it easy to
adopt best practices and all you
have to do is avoid ATS
exceptions.
If you are using an ATS
exception.
You are saying that connection
should have weaker security than
our platform can enforce.
So, now Chris is going to talk
to you about app transport
security a little bit more and
give you an update on the
current status.
Chris.
[ Applause ]
>> Thank you, Bailey.
Now, continuing along this
thread of best practices, I want
to dive a little bit deeper into
ATS.
ATS for those that aren't
familiar is a feature we
released in iOS 9 and
[inaudible] aimed at increasing
the security and privacy of your
customers' data.
ATS ensures that most of the
application data sent over the
network is encrypted and
protected by default.
Basically, this means moving
away from insecure and legacy
HTP toward HTTPS.
And that means a couple things,
the first of which is to use the
latest standardized version TLS,
version 1.2.
This has been updated and
amended over the years to take
into account some of the attacks
that Bailey eluded to earlier.
It also means using strong
cryptography.
That means using block cyphers
like AES and hash functions from
the SHA-2 family.
Importantly, it also means using
key exchange algorithms that
provide forward secrecy.
And this is an increasingly
important property in today's
day where the content of your
application's data as
transmitted over the network are
kept save, even in the event
that the long-term private key
of a server is compromised.
Now, we live in a world where
not all TL servers are equal,
and moreover, not all TLS
servers use the same version or
configuration.
For example, you might have to
connect to an add server that
doesn't even support HTTPS.
So, what do you do?
This is where exceptions come
in.
Exceptions allow your app to opt
out of ATS enforcement for
particular domains, or globally
across your application.
Exceptions are intended to be
temporary to help you maintain
functionality while servers
upgrade to more modern TLS
configurations.
Last year, we announced plans to
start requiring justification
for exceptions in the app store.
And since then, we've heard that
the exceptions we had available
to you did not adequately meet
all of your use cases.
And since universal ATS adoption
remains our primary goal, we've
taken that time to update the
exceptions that we have
available to you to meet and
satisfy these use cases.
And I want to dive into some
recent ones that were added in
the past.
Specifically, we've gone beyond
just acceptance for WebKit
content.
There are exceptions now to
ensure that if you are streaming
data through the AVFoundation
framework that happens to be
encrypted at rest, you can opt
out of ATS for that particular
data.
We also have exceptions to
support opting out of ATS for
arbitrary WebView request and
opting out of ATS for local
network connections.
Here, local network connections
is just a connection made to a
raw IP address, or a server with
an unqualified domain name.
I want to be clear, even though
it may not be necessary for the
security and privacy of your
data to opt out of ATS, because
you have otherwise encrypted
your data before transmitting
it.
We still believe that the right
and proper thing to do is to use
TLS to protect your data in
transit.
That means as app developers,
and as Bailey already mentioned,
your goal should be to minimize
or remove exceptions where at
all possible, if it is within
your power to do so.
I also want to point out a
recent key that was added to
support certificate
transparency.
If you want a particular server
to opt into or participate in
certificate transparency to help
protect your apps, and users'
apps against certificate
[inaudible] attacks, you can
specify for a particular domain
whether or not you want that
server to participate in CT.
Now, we remain committed to ATS.
And in the past year we've
continued upgrading the services
that we make available to you as
developers, to make sure that
they are ATS compliant.
All the services you see here
are fully ATS compliant, meaning
that your apps will not have to
specify and exceptions when
talking to them.
You get best practice network
security out of the box, which
is the ultimate goal.
Now, also in this past year, we
kept an eye on the app store to
track and see how ATS adoption
is going.
We see adoption increasing.
We've also been seeing the
number of exceptions increasing.
Which means that there's still
more work to be done.
If you are an app developer,
continue to be vigilant and
remove, or minimize your reliant
on exceptions.
If you are a server operator or
owner, please continue upgrading
your server configurations to
support 1.2 and more modern
versions of TLS.
Now, speaking of TLS, I want to
give you a brief glimpse into
the future of this critical
security protocol.
For those of you who don't know,
TLS is quickly becoming the
[inaudible] of the internet.
More and more of your traffic is
protected on the wire thanks to
TLS, today.
However, not all traffic is
protected the same.
This protocol has been with us
for many, many years and there
are many different
implementations and
configurations of servers out
there supporting a wide variety
of TLS versions.
And over time the protocol has
been patched and amended to
generally address some of the
attacks that Bailey eluded to
earlier and just to fix up
general deficiency in the
protocol.
In recent years, the internet
community has taken it upon
themselves and deemed it
necessary to start working on
the next version of this
critical protocol.
TLS 1.3. And in the spirit of
best practices, we are closely
tracking this work to ensure
that we are ready to adopt it
and help you adopt it when it
becomes a standard.
TLS 1.3 is truly best practice
by design.
All of the features, the
majority of the features that
are in ATS compliance
configurations are simply part
of the core standard.
That means legacy cryptographic
cipher suites, hash functions,
and key exchange algorithms are
simply not allowed.
Not that you shouldn't use them,
they're just not there to begin
with.
That means the specification is
overall much simpler.
Which means that it's easier to
implement, easier to reason
about, and most importantly
easier to test.
And this gives us greater
confidence that the
implementation is free, or at
least has very few problems that
have plagued TLS libraries in
the past.
As a result of this simplicity,
it also has improved network
efficiency.
And let me show you what I mean
by that.
Let's walk through a typical
handshake in TLS 1.2 and 1.3 to
establish a connection to a
server.
We start with a TCP connection,
which requires one round trip
between the client and the
server.
Next step you start your TLS
handshake, where the client and
server exchange some hellos and
some initial centrifugation
information needed to proceed
with the rest of the connection.
In TLS 1.3, they actually start
also negotiating key material
used to encrypt the rest of the
traffic sent over that section,
which means that in the next
round, the client can start
sending application data.
In 1.2, the client and server
are still negotiating key
material, which means that
requires one more round trip to
establish this session and start
sending data.
Now, this may not seem like a
lot, but let me put it in
perspective for you.
We collect data from a wide
variety of devices on different
networks, both carrier, cellular
and wi-fi around the world.
And our data suggests that at
least 10% of cellular
connections, or at least 10% of
TLS connections on cellular
networks, rather, require at
least 800 milliseconds to
complete.
And 10% of TLS connections on
wi-fi networks take 500
milliseconds to complete.
TLS 1.3 would effectively shave
1/3 of that time off, which is a
huge win in mobile world.
Now, TLS 1.3 is still very much
a work in progress.
And that's why ATS compliance is
still focused on getting you to
1.2, and ensuring that you're
using the latest proper standard
of the protocol.
However, if you want to
experiment with TLS 1.3 to
prepare yourself for this
protocol, I'm pleased to
announce that we can now allow
you to do that.
It is not on by default in any
of our systems.
However, if you opt into the
seed and want to start
experimenting with it, you can
install a profile on iOS, or
enable system wide TLS 1.3 on
macOS with the simple defaults
write.
And you would do this to prime
your application and your
network as the protocol marches
toward standardization in the
next year.
And in the meantime, we're
paying our due diligence and
working with third parties and
with our enterprise partners to
ensure their apps and their
networks are ready for the
adoption of the protocol as
well.
Now, I want to take a step back
and come full circle with
everything Bailey and I talked
about today.
One of our primary objectives is
to help you keep your customers'
data secure and private.
And we do this by giving you
best practice tools and
technologies to help achieve
that goal.
However, you need to do some
work yourself.
And that means avoiding legacy
or deprecated algorithms when at
all possible.
And it also means continuing to
upgrade to modern TLS
configurations.
If you're a server owner,
operator, again, that means
moving to 1.2 to make sure that
every app that is ATS compliant
can speak to you.
If you're an app developer,
again, that means minimizing or
reducing the use of exceptions.
And if you're particularly
adventurous, that means also
trying out TLS 1.3 to prime your
application and your network for
the next exciting version of
this protocol.
If you'd like any more
information on any of the topics
that Bailey and I discussed, you
can visit this link above.
Next up in this room we have a
session on privacy and your
apps, which I highly encourage
everyone to attend, given your
interest in security.
Tomorrow we have two back to
back jam packed sessions full of
advances in networking, which
would be very interesting and
relevant to anyone at all who is
interested in TLS.
And that's all I have.
Thank you for your time and
attention, enjoy the rest of the
conference.
[ Applause ]