This article was originally published in iOS Growing up. For more WWDC articles, please contact the author.

Today, we are increasingly concerned about user privacy and information security, but as computers become more efficient over time, old network protocols and encryption algorithms become vulnerable to new hardware and attacks.

What can we do about network security?

  • Always pay attention to the security of the App and ensure the timely update of the App
  • Keep abreast of industry developments, latest standards, academic research and industry practices
  • Ensure that integrated third-party libraries can be updated in a timely manner to avoid security risks
  • The OS removes security risks
  • App Transport Security (ATS) enforces best practices in apps
  • Compared with the serious consequences after being attacked, it is worthwhile to invest some maintenance costs in the early stage

Common network attacks

Here’s a summary of some of the most common cyber attacks that vary in their targets, from data theft to identity masking, and they’re color-coded. I’m going to go through some practices to show you how to avoid these attacks, Specifically, practices related to encryption, cryptographic hashes, public keys, network protocols, revocation and so on.

The TLS protocol

At present, most App networks have switched to HTTPS. HTTPS actually adds TLS layer under HTTP. TLS is the basis of network security, which can encrypt and authenticate the transmitted content to avoid tampering with the transmitted content.

The TLS protocol is composed of the TLS handshake protocol and the TLS recording protocol. The TLS recording protocol encrypts the transmitted content. The TLS handshake protocol is divided into four sub-protocols, which negotiate encryption algorithms, share keys, and convey warnings.

TLS protocol involves a variety of different cryptographic technologies, such as asymmetric encryption, hash function, digital signature technology used in the handshake protocol, symmetric encryption, hash function and other technologies used in TLS recording protocol. These technologies are described in detail below, and which technologies are outdated and need to be replaced with more secure encryption algorithms to ensure security.

Introduction to cryptography

In this paper, some encryption algorithms are involved, which can be divided into symmetric encryption and asymmetric encryption according to the way the key is used:

  • Symmetric encryption: Encryption and decryption use the same key. Common encryption algorithms include DES and AES.
  • Asymmetric encryption: Also known as public key encryption, different keys are used for encryption and decryption. Common encryption algorithms include RSA and ECC.

In addition to the above two encryption algorithms, there are a number of techniques used to ensure information integrity and identity authentication:

  • Cryptographic hashing algorithm: It is not an encryption algorithm, but is used to ensure that information has not been tampered with. The cryptographic hash function computes a hash value based on the contents of the message, which is then used to check the integrity of the message.
  • Digital signature: The sender of a message is encrypted with a private key and the receiver is decrypted with a public key. The ciphertext encrypted with the private key can only be decrypted by the corresponding public key, so this process can be called digital signature and used for identity authentication.
  • Certificate: a public key certificate digitally signed by the CA for identity authentication.

encryption

Encryption is a well-known way to prevent information from being eavesdropped, but some encryption algorithms have become so insecure that attackers can easily crack them. RC4, in particular, can now be breached in as little as three days. Also, triple-DES and AES encryption algorithms are not secure against attacks like BEAST and Lucky 13. Apple is planning to eliminate Triple-des and RC4 on all platforms and does not recommend the use of AES-CBC, but has not given a specific date. Apple recommends that we use aes-GCM or ChaCha20/Poly1305.

A cryptographic hash

A cryptographic hash will have an input value and an output value, the input is called a message, and the output is called a hash value. Cryptographic hash computes a hash value based on the input, and this hash value can be used to determine whether the information is complete. But some of these cryptographic hashes are no longer secure, and hackers can tamper with the data in the form of collision attacks. A collision attack is a massive attempt to find different input values, but the output values are the same, and then tamper with the data. Because the tampered hash value does not change, you cannot tell if the data has been modified.

Md-5 and SHA-1 are no longer secure, and Apple has removed signing certificates for the MD-5 algorithm in previous years. Sha-1 also came under attack earlier this year. As a result, Apple will no longer trust sha-1 signed certificates. For absolute security, developers should use the SHA-2 algorithm.

Public key cryptography

Generally, only the private key can be used to open the encrypted content after the public key is encrypted. However, the 768-bit RSA was breached in 2009, and Apple removed support for certificates with RSA signatures below 1024 bits in the spring of 2016. An attack on 1024-bit RSA encryption is on the way, so Apple has announced that it will no longer trust certificates with RSA signatures below 2048 bits. You should use RSA encryption greater than 2048 bits, or any other elliptic curve cipher trusted by Apple platforms.

agreement

If the developer is using HTTP, it means that whatever you’re transmitting is available to anyone listening. Some aging TLS versions, such as SSL 3.0, TLS1.1, and TLS1.0, are also insecure. These protocols should be avoided and developers should use HTTPS, which is based on TLS1.2.

At the same time, Apple announced the release of TLS 1.3 Beta, more on that later.

revoked

We may need to revoke the certificate when the private key is leaked or some other situation occurs. When receiving a certificate, the client must confirm the revocation of the certificate.

The Apple platform does not perform revocation checks by default. The following revocation mechanisms currently exist:

  • Certificate Revocation List (CRL), a List containing the serial numbers of revoked certificates, is maintained by Certificate authorities. Its disadvantages are that the CRL becomes larger and larger, and the real-time query becomes slower and slower. At the same time, the CRL of CA needs to be continuously requested, which has a certain delay.
  • The Online Certificate Status Protocol (OCSP) works like this. First, the server applies for a certificate from the CA. The server sends the certificate to the client for authentication. To verify the identity of the server, the client sends a request to the CA to obtain the revocation information of the certificate, and the CA returns the certificate status to the client. The client determines whether the server certificate is correct based on the returned result. As you can see, OCSP has a significant flaw in that clients need to send additional network requests to CA, which causes it to have some performance issues. In addition, OCSP is plaintext transmission, which may cause security risks. For these two reasons, Apple does not support OCSP authentication by default. If developers want to enable OCSP queries, they need to integrate other apis into the App.

  • OCSP Stapling makes up for the defects of OCSP. When a server requests a certificate from a CA, it also requests the revocation information from the CA and sends the revocation information and the certificate to the client. The client can verify the certificate and revocation information at the same time.

Although Apple encourages developers to use OCSP Stapling on the server side, it is far from widespread enough. Apple also announced enhanced certificate revocation verification across all platforms. Apple gets a list of trusted certificates from the Certificate Transparency Log, to which both developers and cas can submit certificates that are monitored and audited. Then, Apple queries the revocation status of the certificate from the certificate authority, binds all the revocation information together, and automatically sends the information to the client device at intervals. In this way, the client can periodically verify the revocation status of the certificate.

If a certificate is found in the revocation list during a TLS session, the client performs an OCSP check to verify that the certificate has been revoked. If the certificate is not in the revocation list, no OCSP check is performed. In this way, the client generally does not need to send additional network requests to the CA, avoiding performance issues.

review

Apple’s changes to encryption, hash functions, network protocols, certificate revocation checks, and public key cryptography are shown below:

New certificate error page

Safari has redesigned the certificate error screen. If you use a certificate that does not meet your requirements, you will see this screen.

You can use the certificate Viewer to further view the details of the certificate error.

ATS with TLS 1.3

ATS was introduced in iOS 9 to ensure that developers use encrypted networks to transfer data. But Apple found that the transition to full ATS was longer than expected, so it expanded its support for the ATS exemption.

Last year Apple realized that the current ATS exemption wasn’t enough for all developers, so it opened up separate exemption support for AVFoundation, WebView, and Webkit. Exemptions can be limited to a single domain name and the entire App, and exemptions for local networks (original IP addresses and unqualified host names) are also supported.

Despite the expanded exemption support for now, Apple still believes that ATS is the right choice and will actively recommend its use.

The history of TLS

TLS is a precursor to Secure Sockets Layer (SSL). Netscape was the first company to release SSL. Later, the Internet Standardization Organization took over and standardized SSL. In 1999, it was called TLS (Transport Layer Security). This was followed by an April 2006 update to TLS 1.0, which is not much different. TLS 1.2, Apple’s current protocol recommended for use over HTTPS networks, was released in 2008.

TLS 1.3 is a new TLS standard under development and is currently a draft version.

The TLS 1.3

At WWDC, Apple explained the changes to TLS 1.3 compared to TLS 1.2:

  • Best practices
  • Delete support for old encryption algorithms, such as RC4, SHA-1, CBC, and RSA encryption algorithms.
  • Simpler configuration, easier to test
  • Improved performance in TLS handshake and session recovery

As for the fourth optimization point, which should be our most concern, the TLS handshake is changed from the original four handshake to two handshake, that is, one RTT is reduced, and the key exchange and encryption algorithm negotiation of TLS 1.3 are put together. Thanks to this more efficient method of shaking hands, Apple claims to reduce handshake delays by about a third.

Although the official version is not yet available, you can now test the TSL 1.3 beta at developer.apple.com/go/?id=tls1… Download and install a profile on your phone and upgrade to iOS 11 to experience the latest TLS protocol. Meanwhile, in macOS High Sierra, TLS 1.3 can be enabled with the following terminal command.

defaults write /Library/Preferences/com.apple.networkd tcp_connect_enable_tls13 1Copy the code

reference

  • United States Apps and Evolving Network Security Standards
  • Presentation Slides (PDF)