Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How to Ruin TLS Security

DZone's Guide to

How to Ruin TLS Security

While TLS isn't a magic bullet, it's the best thing we've got. So, read on to get some tips on what not to do when configuring HTTPS.

· Security Zone ·
Free Resource

DON’T STRESS! Assess your OSS. Get your free code scanner from FlexeraFlexNet Code Aware scans Java, NuGet, and NPM packages.

TLS may be the backbone of internet security today, but it's remarkably easy to misconfigure. There are three ways folks usually go about insecuring their HTTPS configs - weak keys, weak ciphers, and weak protocols.

So first, let's take a look at weak keys. And by weak here, I mean keys that either are too weak in and of themselves or keys that are stored insecurely. You need to use a strong key! A short, or easily guessable key, or particularly both, is a really bad idea. This key is used to configure the encrypted session, and, if it's known, an attacker can steal the session key while the session is being configured between the server and the client. And these keys need to be stored in a file that's only readable by the process running your web server. So what should you do? Create a specific user and group for the server you're running, and make sure that the key is only readable by that user.

Okay, so you've secured your keys - what's next? Well, the next thing folks will attack is your cipher suites. Usually, the defaults are okay - but don't use them anyway. Make sure you know exactly what suites are available, and which ones are still currently recommended. NIST Special Publication 800-175B is a great reference for this. I find it's best if you're explicit about the ciphers you'll use - both the ones that you accept and the ones that you deny. You need to stay on top of this too. Folks will regularly configure servers so that they're using strong encryption when first deployed, but they don't revisit the configurations, and, as a result, they end up running insecure systems over time as the algorithms they previously selected become obsolete. And this can happen faster than you think.

Finally, make sure you're only supporting TLS. Don't allow for a fallback to SSL, and, if possible, disallow fallback to weaker versions of TLS. Today, most browsers support TLS v.1.2, so you could likely just support that version in most cases. Now, this depends on your architecture. Some middleboxes (SSL proxies, that kind of thing) in your organization may not support the latest versions of TLS (this is still really common with TLS v.1.3, for example), so you may need to take that into account.

If you do any one of these things, you will have successfully created an insecure HTTPS server! Congratulations!

But if you're like the rest of us, you'll want to steer clear of these common errors. You'll be in much better shape.

Try FlexNet Code Aware Today! A free scan tool for developers. Scan Java, NuGet, and NPM packages for open source security and license compliance issues.

Topics:
tls ,https ,security ,network security ,web security

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}