iOS9 ATS on Amazon AWS Elastic Load Balancers

Introduction

Since Apple is introducing App Transport Security (ATS) with iOS 9 and OS X 10 making effort for best security practices. For developers it means (according to iOS Developer Library):

If you’re developing a new app, you should use HTTPS exclusively. If you have an existing app, you should use HTTPS as much as you can right now, and create a plan for migrating the rest of your app as soon as possible. In addition, your communication through higher-level APIs needs to be encrypted using TLS version 1.2 with forward secrecy. If you try to make a connection that doesn’t follow this requirement, an error is thrown.

Follow up

Assuming basic knowledge with AWS ELB (read the previous article on High-grade Encryption with Amazon AWS Elastic Load Balancers),

what needs to be done is:

  1. make sure to use TLS 1.2 ONLY
  2. enable FS forward secrecy. In Transport Layer Security (TLS), Diffie–Hellman key exchange-based PFSs (DHE-RSA, DHE-DSS) and elliptic curve Diffie–Hellman-based PFSs (ECDHE-RSA, ECDHE-ECDSA) are available.

ECDSA keys are something to look forward in future (only <1% ECDSA keys in use, as majority keys are RSA keys)

  1. with ECDSA you can get the same level of security as RSA but with smaller keys
  2. smaller keys have faster algorithms for generating signatures because the math involves smaller numbers
  3. smaller public keys mean smaller certificates and less data to pass around to establish a TLS connection
  4. ECDSA keys do NOT have yet hardware acceleration

This means quicker connections and faster loading times on websites using ECDSA key, but existing software uses hardware-accelerated RSA & AES, so at the moment the speed is not the major factor.

Lets have a look at cypher candidates TLS 1.2 cyphers:

https://www.openssl.org/docs/apps/ciphers.html#TLS-v1.2-cipher-suites

#normal RSA (CBC) (no-forward-secrecy)
TLS_RSA_WITH_AES_128_CBC_SHA256           AES128-SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256           AES256-SHA256

#fast RSA (GCM) (no-forward-secrecy)
TLS_RSA_WITH_AES_128_GCM_SHA256           AES128-GCM-SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384           AES256-GCM-SHA384

#normal FS (CBC)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256     ECDHE-RSA-AES128-SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384     ECDHE-RSA-AES256-SHA384

#fast FS (GCM)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256     ECDHE-RSA-AES128-GCM-SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384     ECDHE-RSA-AES256-GCM-SHA384

The cypher naming convention can be found here, or here at wiki i.e.

DHE-RSA-AES256-SHA. This means DHE for key exchange, RSA for server certificate authentication, 256-bit key AES for the stream cipher, and SHA for the message authentication.

And the winner is ECDHE-RSA-AES128-GCM-SHA256

The best option here is (my optinion)

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256     ECDHE-RSA-AES128-GCM-SHA256
  1. ECDHE is faster than any other DH variants and is a standard already (simple DH not widely adopted because its slower)
  2. we use RSA key, considering switching to ECDSA in near-future
  3. AES128 is considered same security level as AES256 read here or here there are number of flaws in AES256 also the reason itself why AES192 & AES256 exists is mostly not ‘because they are stronger encryption’ but due to bureocracy (3 security levels needed).
  4. choose suite with GCM (Galios/Counter Mode) instead of CBC Mode because GCM faster see intel document on openssl performance

GCMvsCBC

Breaking compatibility (DES-CBC3-SHA)

  1. If u have browser access, some old browsers might lack TLS 1.2 support, for example default Android 4.4 (and lower) browser will fail to connect.
  2. AES and ECDHE based suites are available if IE >= 7 AND OS >= Windows Vista. AES does not exist with IE8 on WinXP.

To keep compatibility with Windows XP (and other old software) try enabling the DES-CBC3-SHA cypher, it is slow but still considered secure.

IE Supported cipher suites.

TLS 1.3, Mobile specifics, chacha(cha)?

Since Apple limits TLS to 1.2 looking into future there is already TLS 1.3 draft that solves few remaining TLS problems:

  • TLS 1.3 reduces the handshake (latency)
  • It is not 100% but current iOS does support hardware accelerated AES, yet another reason to select RSA+AES, and ofc. modern desktop CPUs do have AES enc/dec.
  • ChaCha20-Poly1305 cypher is three times faster than AES-128-GCM on mobile devices. Spending less time on decryption means faster page rendering and better battery life blog.cloudflare.com. On desktop computers with hardware AES support, AES-128-GCM is still the faster choice. Unfortunately AWS ELB does not support ChaCha20 cypher atm.

Additionnal tools/materials

Written on August 11, 2015
https://moar.sshilko.com/2015/08/11/AWS-ELB-iOS9