Why you should avoid SSL for your next application | Cossack Labs

**protocol design**: **protocol itself is obscure and complicated**: which makes it hard to audit and easy to introduce bugs. TLS 1.3 is an attempt to address these challenges, and it does eliminate some of the pitfalls. **Protocol lacks important features**: perfect forward secrecy comes only in most recent TLS 1.2 in some (not all) ciphersuites, and most ciphersuites in TLS 1.3. **Protocol mandates only client authenticating the server, reverse is optional**: works by default without authenticating the client, which is how the web security should be built, but isn't sufficient for trusted application-server communication. **Communication leaks data**: session status, identity of parties. **Authentication before encryption**: misplaced sequence of authentication and encryption led to POODLE attack's second coming. TLS 1.3 mainly offers AEAD mode of symmetric encryption, which eliminates the problem completely, if appropriate ciphersuite is chosen. Ciphersuites to use: … **Poor choice of ciphers and cipher modes**: **Performance over security**: diffie-hellman exchanges are used in worst way possible, opening doors to abuse. **Most bad ciphers are kept in SSL for too long**: for example, RC4 is known to have weaknesses ~10 years before actually getting exploited, yet it is still widely supported by default SSL configurations, because it was used to mitigate another cryptographic attack some time ago. This is only addressed in TLS 1.3 by disallowing anything but AEAD symmetric ciphers. **Most bad ciphers are still in your browser and your server**: just check for yourself how's my ssl, ssl labs **Certificate trust model**: certificate authority, certain certificate parameters and structure of trust is flawed too: they've been created for too generic purpose and adapted to the needs of certificate authorities, not end-users: **OCSP/CSR revocation list verification is nearly useless**: failure to verify for revocation status doesn't stop browsers and apps from proceeding (soft-fail). … **SSL pinning is hard to do**and easy to break **Complicated PKI infrastructure is necessary to maintain CAs**: which is, again, a risk vector of it's own. **Issuing certificates relies on DNS and e-mail**, which delivers your certificates. E-mail's domain is not required to be verified. … ##### Legacy and compatibility... SSL has long history of problems - not least due to decades-long-lasting compatibility and legacy code and obscure implementations of rather a complicated protocol. For example, the very first SSL protocol (SNP) was introduced with "It is designed to resemble the Berkeley sockets interface so that security can be easily retrofitted into existing socket programs with only minor modifications." attitude in mind. This is not exactly what you want a security protocol to focus on. Lately, TLS 1.3 addresses most of these issues by throwing most obviously insecure cryptographic choices away.