Link Search Menu Expand Document
☰
×
Topics

Insufficient Transport Layer Security

Play SecureFlag Play Labs on this vulnerability with SecureFlag!

  1. Insufficient Transport Layer Security
    1. Description
    2. Impact
    3. Prevention
      1. Server configuration
      2. Certificates
      3. Web Applications
    4. Testing
    5. References

Description

Communication between systems may traverse a wide range of carrier networks, ISP networks, Wi-Fi, and the Internet. Unfortunately, threat agents located between two communicating parties might be capable of intercepting, reading, and manipulating the data while it’s traveling across the wire.

Protecting sensitive or private data has become a mandatory requirement in the modern-day, urged on at legislative levels courtesy of the evident porous nature of our networked systems. Luckily, many end-user tools like browsers and mobile applications have taken the call for better security and privacy seriously, altering their approaches to technological design and function to align with the rightful expectations of their users.

Security and privacy concerns concerning communication interception have been addressed by enabling Transport Layer Security, typically involving HTTPS and its security layers; Transport Layer Security (TLS) and its now-deprecated predecessor, Secure Sockets Layer (SSL).

TLS is a cryptographic protocol designed to render secure communication over a computer network, providing privacy, data integrity, and authentication between two or more communicating systems. Specifically, TLS can provide several security benefits:

  • Confidentiality: Protection against an attacker attempting to read traffic content.
  • Integrity: Protection against an attacker attempting to modify traffic.
  • Replay prevention: Protection against an attacker replaying requests against the server.
  • Authentication: Allowing the client to verify that they are connected to the real server (the client’s authentication is optional).

Impact

Insufficient implementation or misconfiguration of TLS can expose sensitive data to unauthorized access, increase susceptibility to man-in-the-middle (MITM) attacks, and compromise data integrity and confidentiality. If certificates expire, users might experience service disruptions, leading to potentially lead to reputational damage and loss of business.

Non-compliance with security standards due to improper TLS configuration could also result in legal repercussions and financial penalties. The cumulative effect could be a loss of user trust, reputational damage, and a significant impact on business continuity and profitability.

Prevention

In modern systems, the performance cost of providing communications security is negligible, and every network service should enforce Transport Layer Security.

Protecting a service with TLS is not an easy task, and it is important to test and verify configurations. The following aspects should be taken into consideration when configuring TLS:

Server configuration

  • Only Support Strong Protocols: Web applications should only support TLS 1.2 and TLS 1.3, with all other protocols disabled. SSL protocols are deprecated and should not be used under any circumstances.
  • Only Support Strong Ciphers: TLS supports a large number of cipher suites with varying levels of security. Where possible, only enable GCM ciphers. However, if supporting legacy clients is absolutely necessary, it may require enabling other ciphers. At a minimum, the following types of ciphers should always be disabled: “Null ciphers”, “Anonymous ciphers”, and “EXPORT ciphers”.
  • Use Strong Diffie-Hellman Parameters: Where ciphers that use the ephemeral Diffie-Hellman key exchange are in use, deploy at least a 2048 bit-prime parameter.
  • Disable Compression: TLS compression should be disabled to protect against CRIME vulnerability.
  • Patch Cryptographic Libraries: Ensure your TLS libraries are kept up to date with the latest security patches.
  • Test the Server Configuration: There are a number of tools that can be used to quickly validate the configuration of a server, such as “SSLyze”, “testssl.sh”, and “tls-scan”.

Certificates

  • Use Strong Keys: The private key used to generate the cipher key must be at least 2048 bits in size.
  • Protect The Keys: Filesystem permissions and other controls should be implemented to protect the private key from unauthorized access.
  • Use Strong Cryptographic Hashing Algorithms: Certificates should use SHA-256 for the hashing algorithm rather than MD5 and SHA-1.
  • Use Correct Domain Names: The domain name (or subject) of the certificate must match the fully qualified name of the server presenting the certificate. This name is stored in the “commonName” (CN) attribute of the certificate and, recently, in the “subjectAlternativeName” (SAN) attribute.
  • Carefully Consider the use of Wildcard Certificates: Wildcard Certificates violate the principle of least privilege, as a single certificate is valid for all subdomains of a domain and should only be used where there is a genuine need.
  • SSL Pinning: Storing commonly used certificates locally to compare against the advertised one from the host, helping to prevent MITM attacks.
  • Renew Certificates Regularly: To avoid outages and downtimes due to expired certificates, set up an automated process for renewing SSL/TLS certificates well before their expiry dates. Utilize monitoring tools to alert administrators in case of nearing expiry or failed renewal attempts.

Web Applications

  • Do Not Mix TLS and Non-TLS Content: TLS should be used for all pages; external resources that load over unencrypted HTTP (such as JavaScript or CSS) should be programmed to load over HTTPS.
  • Use the “Secure” Cookie Attribute: All cookies should be marked with the “Secure” attribute, which instructs the browser only to send them over encrypted HTTPS connections.
  • Use HTTP Strict Transport Security: HTTP Strict Transport Security (HSTS) instructs the user’s browser to always request the site over HTTPS and prevents the user from bypassing certificate warnings.
  • Consider the use of Client-Side Certificates: High-value applications or APIs should enforce client-side authentication.

Testing

Ensure that a verified application uses TLS or strong encryption, regardless of the sensitivity of the data being transmitted, by implementing the most recent, leading configuration advice to enable and order preferred algorithms and ciphers.

References

Wikipedia - Transport Layer Security

OWASP - Transport Layer Protection Cheat Sheet

OWASP - TLS Cipher String Cheat Sheet

Table of contents