SSL / TLS : Best Practices

Hi All,

So finally, I got time to write something. Today, I'm gonna write about SSL and TLS. It’s pretty common terms in Information Security. However, only few heads know actual use of it, difference between them, vulnerabilities present in ciphers, best practices etc.

Let’s understand it in security best practices perspective and do not get into core technical details like Message authentication process, key material generation, Its design & implementation, its RFC etc. I will write about such core part in another post.

Let’s start...

Now days, people/corporates are majorly concern about data that is being sent between application and across the so called “Untrusted Internet” world. Corporates are using cryptographic protocols to authenticate their application server and clients. And also to encrypt messages between authenticated parties. (Server to Server, Server to Client etc).

As of now, there are two cryptographic protocols designed to make web communications secure over untrusted network (e.g. Internet). And those two Protocols are "SSL (Secure Sockets Layer)" and "TLS (Transport Layer Security)".

TLS and SSL are most widely recognized as the protocols that provide secure HTTP (HTTPS) for Internet transactions between Web browsers and Web servers. TLS/SSL can also be used for other application level protocols, such as File Transfer Protocol (FTP), Lightweight Directory Access Protocol (LDAP), and Simple Mail Transfer Protocol (SMTP). TLS/SSL enables server authentication, client authentication, data encryption, and data integrity over networks such as the World Wide Web.

SSL and TLS, Both protocols use Asymmetric Cryptography. SSL and TLS both use X.509 certificates to authenticate two or more parties. Both work on three features of Security (Confidentiality, Integrity and Availability).

How SSL/TLS handshake works:

In SSL/TLS, client submits a list of cipher suites that it supports and then server pick up one suite from the list to negotiate a secure communication channel. Later, secure communication starts. However, some servers will select the first supported suite from the list which is not a best practice.

Vulnerabilities and Best Practices:

Since, there are many vulnerabilities discovered in last few years like BEAST, Renegotiation attack, Version rollback attacks, CRIME attacks, BREACH attacks, POODLE, FREAK attack, logjam attack, Heartbleed attack etc. 
Hence, below are our Recommendations which you need to follow while implementing SSL/TLS to avoid these attacks:

1. SSL v2 is insecure and must not be used.
   
2. SSL v3 is insecure when used with HTTP and weak when used with other protocols. It’s also obsolete, which is why it shouldn’t be used.
3. Disable support for TLS v1.0 (see note below).
4. Disable insecure client-initiated renegotiation.
5. NULL cipher suites provide no encryption.
6. Export key exchange suites use authentication that can easily be broken. Do not use Export ciphers. (FREAK Attack)
7. Anonymous Diffie-Hellman (ADH) suites do not provide authentication.).
8. Suites with weak ciphers (typically of 40 and 56 bits) use encryption that can easily be broken. Make sure your all support ciphers length is more than 128 bits.'
9. RC4 and MD5 is weaker.
10. 3DES provides about 112 bits of security. This is below the recommended minimum of 128 bits, but it’s still strong enough. A bigger practical problem is that 3DES is much slower than the alternatives.
11. Enable HSTS on webserver.
12. Implement Forward Secrecy.
13. Use Certificate pinning, if required.
14. Set Ciphers in order (First Priority is for strength and size of cipher).

Currently, TLSv1.1 and TLSv1.2 are consider to be secure than any other protocol when they are correctly implemented (with above recommendations).

In order to support older clients, you may need to continue to support TLS v1.0 for the time being. With some workarounds, this protocol can still be considered secure enough for most web sites.

One point in above recommendations that I would like to cover, 

Support Forward Secrecy:

Forward Secrecy is a protocol feature that makes secure conversations that are not dependent on the server’s private key. It means, if your server administrator goes on holidays and server's private key gets compromised, administrator can still continue to enjoy his holidays. ;)

With cipher suites that do not support Forward Secrecy, someone having a server’s private key can decrypt all earlier encrypted conversations.

You need to support and prefer ECDHE suites in order to enable Forward Secrecy. Most of modern web browser support ECDHE. However, to support & cover almost all clients, you should use DHE suites as fallback after ECDHE.

Server Supporting ECDHE & DHE with recommended order

There are lots of tools available in market using which you can test your server’s SSL/TLS strength/vulnerabilities. Below are some which I prefer and are best among all:

Online Tools:

https://www.ssllabs.com/ssltest/

Offline Tools:

> SSLscan(From, Kali 2.0 onward is good)

> TestSSLserver

> SSLdiagnos

> TLSenum (especially for checking order of ciphers)

Thanks for your time.. :)

Got queries? Leave a comment down below, I would love to reply..

Ref: ssllabs, owasp, qualys

Read More