Your website or application must be set up within communications networks in order to be accessible to users. Each connection point to an external environment is a possible attack vector that makes up your attack surface. In order to encrypt traffic between your site and your users, you can set your system up with an SSL certificate that uses SSL/TLS protocols to secure traffic.
However, if your server uses a weak SSL algorithm or an insecure SSL/TLS version, you'll need to update the system to protect your customers and your assets. This article provides a brief introduction to SSL/TLS networking, how to identify weak and insecure elements in your SSL setup, and what actions you can take to secure your system and protect user data.
How Network Communications and SSL/TLS Handshakes Function
The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols provide encrypted communications between public web systems through a defined public key infrastructure (PKI). Most websites and apps use SSL certificates to supply a cryptographic key that will authenticate between servers and establish a secure transmission method, typically over an HTTPS (Hypertext Transfer Protocol Secure) connection. SSL/TLS certificates are a type of X.509 certificate used for identity authentication between your servers and users' browsers. SSL/TLS security provides the strong cryptography required by regulations such as PCI-DSS and FISMA through use of public/private key encryption.
SSL/TLS protocols establish communication channels through encryption, authentication, and integrity. SSL/TLS communication uses cipher suites that ensure multiple levels of cryptography. A cipher suite is a set of cryptographic algorithms used during the TLS handshake to help secure communications, and each cipher suite is named with the algorithms that make up the suite.
A TLS handshake is how networks communicate with each other over secure means:
- The server (your website or application) listens on port 443 for secure HTTPS connection requests.
- The client (a user's browser) connects to port 443 and exchanges messages with the server to determine the validity of the exchange and which cryptographic parameters to use for this session. (These are often referred to as the client hello, server hello, and client key exchange.)
- Once the TLS version and cipher suite are agreed upon and the digital certificates have been exchanged and authenticated, an encrypted session is opened and secure communications can be relayed between the client and the server until the client ends the session.
Every certificate uses an encryption algorithm to make the encrypted data unreadable without the appropriate key pair that can decrypt the data. The encryption algorithms that make up a cipher suite are designed to be difficult to reverse engineer, and certificates are constantly adapting to more secure standards, which is why it is so important to renew certificates before they expire.
However, if an SSL certificate relies on an outdated version or insecure cipher suites, then the SSL connection may not be as secure as your users expect. Because the cipher suite is selected through a negotiation between the client (a user's browser) and the server (your site), weak SSL cipher suites should be disabled so that they are not eligible for selection. If you are using OpenSSL as your SSL/TLS toolkit, you can run [.rt-script]openssl ciphers[.rt-script] to generate the cipher list that you currently have available.
Cipher suites that are known to be weak, like the SSLv2 and SSLv3 protocols, should be updated so that your users' sessions are protected. Insecure TLS versions and weak cipher suites may introduce Common Vulnerabilities and Exposures (CVEs), decryption exploitation, padding-oracle (POODLE) attacks, and man-in-the-middle attacks. Any known CVEs include CVSS scores that indicate the risk impact they could have. Additionally, users may not be able to make a secure connection if there are insecure versions or weak cipher suites, and any weak connections could potentially be decrypted by a well-resourced attacker.
Because outdated versions may remain enabled for legacy support, it's important to disable known insecure versions and migrate to the most recent encryption algorithms. In order to make those changes, you will need to identify any weak SSL/TLS versions, insecure cipher suites, or otherwise concerning aspects of your certificate setup.
How to Identify Weak SSL Ciphers and Insecure TLS
The Open Worldwide Application Security Project (OWASP) provides a variety of resources for examining your SSL/TLS security from inside your own systems. You can check your ports and other SSL services with OWASP's guidance, but it can be time-consuming to run manual investigations.
You can also use an automated scanning tool that accounts for the necessary data to ensure that you can quickly identify any weak links in the encryption standards for your external assets. UpGuard BreachSight provides continuous monitoring and automated scanning for potential threats, including known vulnerabilities related to SSL/TLS protocol.
In addition to risks related to SSL certificate expiration and missing SSL certificates, UpGuard scans for weak or otherwise insecure SSL/TLS configurations. UpGuard evaluates collected data and compare the expected response against the actual response for a specified asset, such as a domain or IP address. Our process notes the detection date at which this result was first identified so that you can stay up-to-date with security across your systems. For any given asset, UpGuard will provide a list of additional checks we have run, which enables you to identify related findings together and create a plan of action. You can always export a PDF version of findings for a given asset to be shared with relevant stakeholders. The PDF findings will list current risks by highest severity first, followed by additional checks that are not currently at risk.
UpGuard users are notified with these risk findings for weak and insecure SSL:
- Weak SSL algorithm
- Insecure SSL/TLS versions available
- Insecure cipher suite supported and Weak cipher suites supported
- Untrusted SSL certificate
The Weak SSL algorithm finding evaluates whether the industry standard SHA-256 encryption algorithm is in use with your SSL certificate. SHA-256 computes multiple rounds of 32-bit hash functions, which is in accordance with the Federal Information Processing Standards (FIPS) 180-4 for secure hash standards. UpGuard will scan for the expected SHA-256 encryption algorithm and, if it is not in use, identify which SHA algorithm is in use.
The Insecure SSL/TLS versions available finding identifies which version of SSL/TLS is in use across your systems. UpGuard scans for any known insecure protocol versions, including SSL versions 1, 2, and 3, as well as TLS version 1, which are known to be susceptible to padding-oracle attacks ("POODLE"). The Insecure SSL/TLS versions available finding communicates whether your system has a known insecure version that should be disabled against the expected response (no known insecure versions).
Frequently, an insecure protocol version is connected to the Weak cipher suites supported finding. Each cipher suite is named according to its algorithmic makeup, so you can quickly identify the components that make up any given cipher suite. With the [.rt-script]TLSv1.0: TLS_ECDHE_RSA_WITH_RC4_128_SHA[.rt-script] cipher suite as an example, you can analyze each component:
- TLSv1.0: This sample cipher suite is supported by TLS version 1.0, which was deprecated in 2021 due to security concerns.
- ECDHE_: The sample uses the Elliptic-curve Diffie-Hellman Ephemeral (ECDHE) key exchange, which allows for distinct key exchange during the TLS handshake. While ECDHE is an accepted secure algorithm, the remaining algorithms in the sample are not secure.
- RSA_WITH_RC4_128_: The sample cipher suite also incorporates RSA authentication with Rivest Cipher 4 with 128-bit key (RC4 128). RC4 has a flaw that makes it incredibly susceptible to decryption, particularly with the 128-bit key.
- SHA: This sample also uses the Secure Hash Algorithm 1 (SHA-1) by default, despite deprecation of SHA-1 to move to improved SHA options with larger key sizes for data encryption.
You can add any weak cipher suite, including the sample provided, to a blocklist so that it cannot be used, though it is also beneficial to know how to identify elements of weak cryptographic algorithms.
Most SSL certificates are issued from trusted certificate authorities known to most browsers. However, certificates can also be self-signed or issued by an untrusted authority. A self-signed certificate and certificates from an untrusted authority mean that your user cannot trust that the certificate provides the same level of encrypted security as a certificate from a trusted certificate authority. Additionally, some browsers will not allow traffic to these types of certificates as they cannot verify the certificate authority. If you receive the Untrusted SSL Certificate finding, you should replace the untrusted certificate with a valid certificate that you generate through a certificate signing request. If your domain or IP address has other risk findings related to SSL/TLS, you may be able to mitigate those with a new certificate as well.
How to Mitigate Insecure SSL and Weak Cipher Suite Findings
Once you have identified security concerns related to the strength of your SSL/TLS certificates, you can make changes to protect your system and strengthen your web server's security posture. After resolving any common issues, you can prevent attacks on weak cipher suites by implementing up-to-date standards and disabling any known weak cipher suites or insecure versions of SSL/TLS.
Update SSL/TLS versions
Replace certificates that use insecure SSL/TLS versions or weak cipher suites. All versions of SSL and TLS versions below 1.2 are insecure, so only TLS 1.2 or higher should be allowed for your system.
Upgrade the cipher suites
When you request a new certificate, you can specify stronger encryption algorithms from the issuer. Encryption standards are constantly changing, so it is important to renew certificates on a recurring basis (at least once per year, if not more frequently) so that your TLS cipher suites are aligned to the current TLS standards.
Modern ciphers, such as the DHE and ECDHE families and Galois-counter mode (GCM), are still in use. ECDHE is stronger than DHE, so you can remove DHE values but that may result in reduced compatibility across operating systems and devices. Likewise, the Advanced Encryption Standard (AES) provides strong symmetric-key encryption and has three available key sizes: AES-128 for 128-bit keys, AES-192 for 192-bit keys, and AES-256 for 256-bit keys.
Disallow any weak algorithms
You can also specify SSL ciphers you wish to exclude from your system to ensure up-to-date compatibility with modern browsers. There are some encryption algorithms that are known to be insecure and which should be disabled for use with your web application, including the Data Encryption Standard (DES), Electronic Codebook (ECB), and Cipher Block Chaining (CBC). Other vulnerable encryption algorithms include 3DES, RC4, and the message-digest algorithm (MD5).
Ensure your certificates are issued by a trusted certificate authority
Untrusted certificates cause errors in most browsers and often prevent users from accessing your site. Intentional use of self-signed or untrusted certificates should be done with extreme care to ensure both the accessibility and security of affected systems.
Automate certificate renewal
Prevent your SSL certificate from lapsing due to expiration by setting up an automated renewal cycle.
Route all traffic through HTTPS
Enforce an HTTP Strict Transport Security (HSTS) policy so that all site traffic uses a secure connection, thus preventing site lookalikes through SSL stripping. To serve traffic over HSTS, you may need to update your configuration files with additional directives and timeout settings. If you use Apache as your proxy server, you will need to update the [.rt-script].htaccess[.rt-script] file with a header that sets HSTS routing. For other proxy servers, you may need to update any config or template files for the secure routing.
Protect your SSH connections
If you provide any routes for SSH (secure shell) connection, it is important to ensure those are not vulnerable to encryption-breaking. Your SSH connections should not be external, as only your internal team should be using SSH to run commands on your server. As you consider your cipher suites, you may wish to consider how the digital signature authentication is set. Many cipher suites use either the RSA (Rivest-Shamir-Adleman) algorithm or ECDSA (Elliptic Curve Digital Signature Algorithm), which both have advantages and disadvantages.
How UpGuard Can Help
Current UpGuard users can log in and access their Risk Profile in BreachSight to assess whether any of the SSL findings referenced in this article are impacting external assets. You can also evaluate common SSL findings related to missing certificates and certificates that have expired. Once you have identified security concerns, you can manage your remediation process within UpGuard as well. You can reach out to our support team to investigate and verify any SSL findings that have been identified for your assets.
If you're not a current UpGuard user and you want to review your public-facing assets for these findings and more, sign up for a trial.
