Link Search Menu Expand Document

Insufficient Transport Layer Security

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


Communication between systems may traverse a wide range of carrier networks, ISP networks, Wi-Fis, 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 authentication of the client is optional).


The consequences of employing insufficient Transport Layer Security are dire; even semi-capable attackers may be able to execute successful attacks to read your session cookie, manipulate your home banking account, inject Javascript into the web pages while you browse, or leverage the intercepted information to completely compromise you and your environment.


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 aspect 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 GCM ciphers should be enabled. However, if supporting legacy clients is absolutely necessary, other ciphers may be required. At a minimum, the following types of ciphers should always be disabled: “Null ciphers”, “Anonymous ciphers”, “EXPORT ciphers”.
  • Use Strong Diffie-Hellman Parameters: Where ciphers that use the ephemeral Diffie-Hellman key exchange are in use, at least a 2048 bit-prime parameter should be used.
  • Disable Compression: TLS compression should be disabled in order 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”, “”, and “tls-scan”.


  • 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 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.

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 to only 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.


Ensure that a verified application satisfies the following high level requirements:

  • TLS or strong encryption is always used, regardless of the sensitivity of the data being transmitted
  • The most recent, leading configuration advice is used to enable and order preferred algorithms and ciphers

  • OWASP Testing Guide: Testing for Weak Cryptography


Wikipedia - Transport Layer Security

OWASP - Transport Layer Protection Cheat Sheet

OWASP - TLS Cipher String Cheat Sheet