What to do when you take control/inherit a Secure Network Environment.

There are a lot of reasons why you might inherit a network. Maybe the person who handled SSL/TLS left abruptly, or perhaps you’re doing a favor for a friend. Whatever the reason, it can be overwhelming to get a handle on the sorts of care and feeding a computer system requires from an SSL/TLS standpoint. This is understandable. It’s a lot of responsibility to ensure that a system keeps running without expired certificates, or older SSL/TLS protocol versions that might leave your customers at risk.

First, it’s worth discussing the purpose of SSL/TLS certificates. SSL/TLS allows for communication to be sent securely over an insecure channel. Making use of both symmetric and asymmetric cryptography, SSL/TLS protects communications over the internet from prying eyes. While it can work with a variety of protocols, most commonly you’ll see SSL/TLS used to secure HTTP traffic. It also serves a second major purpose – ensuring that the website you’re visiting really is who they claim they are. This is accomplished via a trusted third party (in this case a certificate authority) who signs the public key served out by the web server, allowing clients to verify trust for the site. This way, they can be assured that there isn’t some malicious ARP poisoning attack redirecting their traffic to another illegitimate server.

SSL/TLS certificates have assigned to them an expiration date, after which it is expected that they be replaced. This allows a certificate authority to periodically revalidate someone’s claim that they’re entitled to issue a certificate for a given domain name. Unfortunately, this means that if a certificate lapses, users will be presented with an error, which can tarnish your company’s reputation.

There are other considerations beyond just making sure that your certificate isn’t expired. This is the bare minimum. Specifically, it is important to insure that only modern versions of the SSL/TLS protocol are allowed by your server (as of this writing only TLS 1.2 and TLS 1.3 are considered secure, and all other protocol versions should be disabled unless you rely specifically on legacy clients, as this will break compatibility with older browsers). It is also imperative to make sure that only strong ciphers are used with TLS 1.2. (TLS 1.3 only supports secure ciphers as of this writing, but that may change as new vulnerabilities are found.)

Gather Information:

• Make sure that you can get into the account for whatever CA or reseller issues your certificates.
• Make a list of all URLs that are accessible from the internet. Prioritize these, but do not ignore internal only endpoints!
• Make a list of all URLs that are accessible on the local intranet only. Make sure to go back and secure these.
• Make sure to familiarize yourself with the process of generating a CSR and Private Keys.
• Check your backups – if you accidentally delete something you shouldn’t, or break a configuration, you’ll want to be able to revert easily. VM snapshots are a great choice for easily reverting to server state a few minutes prior.
• Talk to business folks about any other services you may not be aware of. Let them drive your prioritization of services.
• Make sure that you’ve downloaded and installed OpenSSL (at least version 1.1.1 for TLS 1.3 support) and nmap. You’ll need them for our next steps.

Make a calendar:

• Once you have a list of all of your endpoints, it’s time to get a handle on expiration dates. Many CAs or resellers will send you an email 30 days or so before a certificate expires. Make sure that you’re included on this email.
• Separately, check expiration for each certificate you’re responsible for. You’ll want to start replacing certificates early in case you run into any issues and need to revert in order to get your bearings.

Perform a security scan:

• For external endpoints, Qualys is a really excellent tool for determining security of an SSL/TLS endpoint. It will check both supported protocol versions and supported ciphers. We also have our own Tool available here which is still in active development.
• For internal endpoints, you can run the following commands to determine if an endpoint supports the following protocol versions:

## Ideally your endpoint will support this, but if it doesn’t, it’s not a big deal.
openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_3
## You definitely want your endpoint to support TLS 1.2. If it does not, look into updating software or making changes to server configuration.
openssl s_client -connect www.example.com:443 servername www.example.com  -tls1_2
## TLS 1.1 is not as secure as TLS 1.2, but is not high priority to disable.
openssl s_client -connect www.example.com:443 servername www.example.com -tls1_1
## TLS 1.0 has recently become a high priority to disable.
openssl s_client -connect www.example.com:443 servername www.example.com -tls1
## SSL 3 is an extremely high priority to disable.
openssl s_client -connect www.example.com:443  servername www.example.com -ssl3

Note that the endpoint you’re scanning is repeated here because the connect parameter determines what endpoint your software connects to, and the servername determines what SNI name to request. Sometimes the same server servers multiple sites depending entirely on what name is used to connect.

Using nmap, we can determine cipher support:

nmap --script ssl-enum-ciphers -p 443 www.example.com

Your result will look like the following:

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 2048) - A
|       TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: A

You can compare the ciphers you support against the really excellent list Mozilla maintains here. wiki.mozilla.org/Security/Server_Side_TLS

Looking Forward:

• Make a decision about what certificate CA / reseller you want to use going in the future.
• Determine what actions will need to be taken in order to remove support for any legacy TLS versions or insecure ciphers that your services support.
• Keep on top of expiring certificates! Letting them lapse is a bad look, and is easily avoidable.
• Determine what’s required for your organization to begin supporting TLS 1.3.