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.

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.