The words “encryption”, “SSL” and “HTTPS” is associated with strong security. Many of us feel that if our servers are SSL enabled, your data is secure.
Well, that’s not always the case. If not configured correctly, encrypted communication can be broken.
Here are a few TLS/SSL best practices to help you lock down your encrypted communication.
-
-
1. Use only valid CA certificates (No self-signed certs)
Let’s say your site has a certificate called Cert-A. Your customers encrypt their data and send it to you using Cert-A.
What if someone replaces Cert-A with a fake Cert-B (everything looking the same) while it’s on the network? Your customer will encrypt their data using Cert-B, which can then be read by the attacker. This is called a Man-In-The-Middle (MITM) attack.
Your customer’s browser prevents MITM attacks by checking who created the certificate. If it was created by a company trusted by the browser (there are only about 174 of them), the browser shows a green light.
GoDaddy created the certificate of bobcares.com. Since GoDaddy is trusted by all browsers, the address bar shows a green light.
The issue with self-signed certificates
If you create your own certificate, your customer’s browser can’t verify who created it, and will show an error.
If your customer goes ahead with the transaction anyway, there’s no way for the customer to know if an attacker has replaced your self-signed cert with a fake cert (which will also show the same error).
If an attack like that happens, and your customer loses sensitive information, guess who’s gonna get the bad name? You.
So, it is always best to get a valid CA certificate for your site. And it need not be expensive. There are free options these days, like Let’s Encrypt.
-
2. Use minimum 2048-bit encryption
The average PC now has many times more power than what we had 5 years back. So, theoretically, it is possible for an attacker to break certificates of strength 1024 bit or less.
So, it is best to use minimum 2048 bit encryption for your certificates.
More than 2048 bit encryption (that is 4096 bit) can cause a performance penalty
-
3. Disable SSL v2, SSL v3
Encrypted connections are popularly known as “SSL connections”. SSL or Secure Sockets Layer is an encryption protocol developed by Netscape way back in 1995.
While it served the internet well for 20 odd years, it’s now found to be riddled with a few serious vulnerabilities like DROWN and POODLE.
So, it is best to disable these protocols from your system.
Read : How to fix POODLE vulnerability and disable SSL v2 and v3
-
For as low as
$74.99/server/mo
Get full spectrum infrastructure management services – including setup, monitoring & maintenance.
Never again face a critical business downtime. We keep your servers secured, optimized and updated at all times. Our engineers monitor your servers 24/7 and fix issues before it can affect your customers.
-
4. Disable TLS 1.0
TLS or Transport Layer Technology was developed in 1999 as a replacement for SSL protocols. However, it’s first version TLS 1.0 is also found to have vulnerabilities such as BEAST, POODLE, etc.
Also, TLS 1.0 is considered unsafe by PCI (Payment Card Industry) standards. If you use your servers for eCommerce, it’s recommended that you disable TLS 1.0 and instead use TLS 1.1 and 1.2.
-
5. Disable weak ciphers
As a child, many would have used certain “codes” to talk to friends. For eg. Pig Latin is one such code.
For “adult” secure communication, these codes are called ciphers. However, not all ciphers are secure. So, make sure these ciphers are disabled from your server:
- Anonymous Diffie-Hellman (ADH)
- Null cipher
- Export cipher
- Weak ciphers (less than 56 bit encryption)
- RC4
- 3DES
-
6. Encrypt all services
The internet has ears everywhere. At any point, it’s safe to assume that data going out of your server is being recorded by parties with malicious intent.
With encryption becoming cheap or even free, it is now possible to encrypt everything without incurring high costs.
So, It is a best practice to configure your services to accept ONLY TLS connections. For eg. in websites, enable HSTS (HTTP Strict Transport Security), which will ensure that browsers around the world will reject any page that’s not protected by your certificate.
By encrypting everything, you deny attackers every bit of information such as your browsing behavior, people you contact, the products you are interested in, and more.
-
7. Look out for SSL/TLS vulnerabilities
A lot of SSL and TLS vulnerabilities were disclosed in the past couple of years. If anything, the rate of bug disclosures are only going up.
So, it is important to keep an eye out for new vulnerabilities, and take quick remedial actions to patch it.
Some vulnerabilities won’t have an immediate patch available, but there would be recommended mitigation steps that can fend off attacks until a patch is available. Eg. Here’s how we mitigated DROWN vulnerability by disabling weak ciphers and protocols.
In short..
If not configured properly, encrypted communications can be broken quite easily. Today we’ve seen the top 7 best practices to make sure your TLS/SSL connections are unbreakable.
Bobcares helps online businesses of all sizes achieve world-class security and uptime, using tried and tested solutions. If you’d like to know how to make your server more reliable, we’d be happy to talk to you.
For as low as
$74.99/server/mo
Get full spectrum infrastructure management services – including setup, monitoring & maintenance.
Never again face a critical business downtime. We keep your servers secured, optimized and updated at all times. Our engineers monitor your servers 24/7 and fix issues before it can affect your customers.
What should one do if you want a SSL certificate for an internal server? The SSL should have a FQDN and public IP right? So how can this be fixed; having a proper certificate for a (large) company internally?