Insufficient Transport Layer Protection#

Insufficient Transport Layer Protection (ITLP) occurs when data transmitted between a client and a server is not adequately protected using HTTPS/TLS, leaving it vulnerable to interception or modification during transmission. This can result from missing encryption, outdated protocols (e.g., SSL), weak cipher suites, misconfigurations, or failure to properly enforce secure communication.

Maps to: OWASP WSTG-CRYP-01 (Testing for Weak Transport Layer Security), CWE-319 (Cleartext Transmission of Sensitive Information), CWE-326 (Inadequate Encryption Strength).

Types of Attacks#

1. Cleartext Transmission (No TLS at All)#

The application accepts sensitive requests - login, session cookies, API calls - directly over plain HTTP, with no encryption whatsoever. Anyone on the network path (public Wi-Fi, compromised router, ISP-level interception) can read the traffic in plaintext.

2. SSL Stripping / HTTPS Downgrade#

Even when HTTPS exists, if the application doesn’t force it (no redirect, no HSTS), an attacker positioned as a man-in-the-middle can intercept the initial HTTP request before it ever reaches HTTPS, and silently proxy the rest of the session over HTTP while showing the victim a normal-looking page. The victim never sees a certificate warning because they were never on HTTPS to begin with.

3. Weak Protocol / Cipher Suite Negotiation#

TLS supports many versions and cipher suites for backward compatibility. If a server still accepts old, broken protocols (SSLv3, TLS 1.0/1.1) or weak ciphers (RC4, 3DES, export-grade), an attacker can force protocol/cipher downgrade negotiation to the weakest option the server will accept, then break that weaker encryption.

4. Certificate Validation Failures#

Self-signed certificates, expired certificates, hostname mismatches, or missing certificate pinning (particularly in mobile apps) let an attacker present their own certificate during a MITM attack, and the client accepts it anyway.

Attack Surfaces#

HTTP endpoints
Authentication Requests
Session Cookie Transmission
API Communications
Mixed Content Resources
WebSocket Connections
File Transfers
Third-party Integrations
Mobile app API backends (often skip certificate pinning entirely)

Exploitation and Bypassing Defenses#

Most ITLP findings are proven through interception rather than payload crafting - the “exploit” is demonstrating that data is actually readable or modifiable in transit, not injecting anything.

Setting up interception#

# Position yourself as MITM using a proxy (for authorized testing on your own network segment / test environment only) Burp Suite: set as system/browser proxy, intercept HTTP requests directly Or, for a quick CLI-based downgrade test without a full proxy setup:
curl -v http://target.com/login -d "user=test&pass=test123"
# If this succeeds and returns a session cookie or auth response, credentials are travelling in cleartext - capture with tcpdump/Wireshark to prove it:
sudo tcpdump -i any -A 'tcp port 80 and host target.com'

Testing whether HTTPS is actually enforced#

# Does HTTP even respond, or does something immediately redirect?
curl -sI http://target.com/ | head -5

# If it does redirect, check WHERE and WHEN - some apps only redirect on the login page but leave other endpoints (APIs, password reset, "remember me" tokens) reachable over plain HTTP
curl -sI http://target.com/api/v1/profile
curl -sI http://target.com/reset-password

A partial redirect (only some paths enforce HTTPS) is a common real-world finding - don’t stop testing after confirming the homepage redirects correctly.

curl -sI https://target.com/login | grep -i "set-cookie"
# Vulnerable: Set-Cookie: sessionid=12345
# Secure:     Set-Cookie: sessionid=12345; Secure; HttpOnly; SameSite=Strict

No Secure flag means the same cookie will also be sent over a plain HTTP request to the same domain if one exists anywhere in the app - even if the login page itself is HTTPS-only.

Testing HSTS enforcement#

curl -sI https://target.com/ | grep -i "strict-transport-security"

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age            - how long (seconds) the browser remembers to force HTTPS for this host
includeSubDomains  - extends the policy to every subdomain, not just the exact host
preload            - submits the domain to browsers' built-in HSTS preload lists;
                      requires max-age >= 31536000 (1 year) AND includeSubDomains

Vulnerable if: header is missing entirely, max-age is small (a few minutes/hours instead of a year), or includeSubDomains is absent on an app where subdomains also handle sensitive data.

Testing WebSocket transport security#

GET /socket HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Check whether the connection uses ws:// (insecure) or wss:// (encrypted):

Insecure: ws://example.com/socket
Secure:   wss://example.com/socket

A wss:// page that falls back to ws:// when the secure connection fails (rather than refusing to connect) is a downgrade path worth testing explicitly.

Testing TLS version and cipher support#

# testssl.sh - comprehensive TLS/cipher/vulnerability scanner
testssl.sh target.com:443

# sslscan - quicker cipher/protocol enumeration
sslscan target.com:443

# openssl - manually force a specific protocol version to confirm it's actually accepted
openssl s_client -connect target.com:443 -tls1      # TLS 1.0
openssl s_client -connect target.com:443 -tls1_1    # TLS 1.1
openssl s_client -connect target.com:443 -ssl3      # SSLv3 (most clients no longer even support this flag)

What’s actually vulnerable:

Protocol/Cipher	Status
SSL 2.0 / SSL 3.0	Broken - POODLE (SSLv3), should never be enabled
TLS 1.0 / TLS 1.1	Formally deprecated (RFC 8996) - flag as a finding, but note it’s a compliance/deprecation issue more than an immediately exploitable break in most configurations
TLS 1.2	Not inherently vulnerable - acceptable when configured with strong AEAD (Authenticated Encryption with Associated Data) cipher suites (AES-GCM, ChaCha20-Poly1305) and no CBC/RC4/3DES. Do not flag TLS 1.2 support alone as a finding - only flag it if the cipher suites it negotiates are weak
TLS 1.3	Current secure baseline - removes support for all the legacy weak ciphers by design

Weak cipher suites to specifically check for, and why each is broken:

SSL_RSA_WITH_3DES_EDE_CBC_SHA / TLS_RSA_WITH_3DES_EDE_CBC_SHA → 3DES’s 64-bit block size is vulnerable to SWEET32 (birthday-bound collision attack on large data transfers)
TLS_RSA_WITH_AES_128_CBC_SHA / ...CBC_SHA256 → CBC-mode ciphers using the vulnerable TLS record MAC-then-encrypt construction are susceptible to padding-oracle-class attacks (BEAST against TLS 1.0, Lucky-13 more broadly) - meaningfully less severe against AES-CBC in a modern stack than SWEET32 is against 3DES, but still worth disabling in favor of AEAD ciphers
Any _EXPORT_ or _NULL_ cipher → export-grade or no encryption at all, critical finding if present

Also check for weak Diffie-Hellman parameters (Logjam) and Heartbleed exposure, both still worth a quick pass on older infrastructure:

testssl.sh --logjam target.com:443
testssl.sh --heartbleed target.com:443

Testing certificate validity#

# CLI cert inspection - faster and more precise than manual browser checking, and works for non-browser endpoints (APIs, mobile backends) too
echo | openssl s_client -connect target.com:443 -servername target.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Check for hostname/SAN mismatch specifically
echo | openssl s_client -connect target.com:443 -servername target.com 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Flag any of: self-signed cert (issuer == subject), expired notAfter date, hostname not present in the SAN list, or a certificate chain that doesn’t validate to a trusted root.

Advanced Attack Scenarios#

1. Mobile App Certificate Pinning Bypass#

Mobile apps often talk to APIs over HTTPS but skip certificate pinning, meaning any valid CA-issued certificate (including one an attacker generates via a MITM proxy like Burp with its CA installed on the test device) will be accepted. Where pinning is implemented, it’s frequently bypassable via runtime instrumentation:

# Frida-based universal SSL pinning bypass - commonly used against Android apps
frida -U -f com.target.app -l ssl-pinning-bypass.js

This turns a properly-pinned app back into a plaintext-visible one for testing purposes, and reveals whether the underlying API traffic itself relies on transport security alone (no additional payload-level integrity check) once pinning is defeated.

2. Mixed Content Escalation to Full Session Compromise#

A single HTTP resource loaded on an otherwise HTTPS page (an image, a script, a stylesheet) gives a network attacker a foothold: they can’t read the HTTPS traffic, but they can tamper with that one HTTP response. If it’s a JS file, this becomes stored-XSS-equivalent - an attacker on the network path can inject arbitrary JavaScript into an otherwise secure page. Check DevTools Console for mixed-content warnings, then specifically identify whether any flagged resource is a script (highest severity) versus an image (lower, but still worth reporting).

3. Downgrade via Third-Party/Embedded Content#

If the target application embeds a third-party widget, ad, or iframe that itself loads over HTTP (or has weaker TLS than the parent site), an attacker who compromises that weaker link inherits partial control of the page context - this is worth checking specifically when auditing third-party integrations alongside transport security.

Detection Techniques#

A. Manual Detection Techniques#

Check for HTTP Instead of HTTPS

Steps
- Change URL to HTTP
- Observe if it loads
- Check if credentials can be submitted
Example: http://example.com/login

Vulnerable if:
- Page loads over HTTP
- Login works over HTTP
- No redirect to HTTPS
Check HTTP → HTTPS Redirection

Test whether the site forces a secure connection on every path, not just the homepage.
- Visit http://site.com
- See if it redirects to https://site.com
- Repeat against API endpoints, password reset, and other sensitive paths individually
Vulnerable if:
- No redirect
- Partial redirect (homepage only, other endpoints still serve over HTTP)
- Redirect happens only after login, leaving pre-auth traffic exposed
Check Cookie Security Flags

Steps: DevTools → Application → Cookies, inspect the session cookie.

Vulnerable if: Set-Cookie: sessionid=12345

Secure version: Set-Cookie: sessionid=12345; Secure; HttpOnly; SameSite=Strict
Check Mixed Content

Steps: Open DevTools → Console, reload page, look for “Mixed Content: loaded over HTTP” warnings.

Check specifically what type of resource is flagged - HTTP JS/CSS is a materially higher-severity finding than an HTTP image, since scripts can be tampered with to achieve code execution in the page context (see Advanced Attack Scenarios above).
Check HSTS Header

If the HSTS header is missing or misconfigured, attackers can perform SSL stripping or HTTPS downgrade attacks.

Secure:
```
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
```
Vulnerable if: header missing, max-age is short, or includeSubDomains absent.
Check WebSocket Security

Look for ws:// instead of wss:// in network traffic, and check whether the app silently falls back to ws:// if the secure connection fails.
Check TLS Version and Cipher Support

Use testssl.sh, sslscan, or openssl s_client (see Exploitation section above for exact commands).

Vulnerable if the server accepts: SSL 2.0/3.0, TLS 1.0/1.1, or any weak/export/NULL cipher suite. Do not flag TLS 1.2 by itself - check its negotiated cipher suites before deciding severity.
Check Certificate Validity

Use openssl s_client (see command above) rather than relying only on browser warnings - this also works against APIs and non-browser endpoints. Look for: self-signed certs, expired certs, hostname/SAN mismatches, and untrusted root CAs.

B. Automated Detection Techniques#

SSL/TLS Scanners - detect weak TLS versions, weak ciphers, and certificate issues
- testssl.sh
- sslscan
Web Vulnerability Scanners - automatically detect HTTP usage, mixed content, missing HSTS
- OWASP ZAP
- Burp Suite
Nmap SSL Scripts - detect supported TLS versions and weak ciphers
```
nmap --script ssl-enum-ciphers -p 443 example.com
```
Mobile-specific: MobSF (Mobile Security Framework) for automated detection of missing certificate pinning and cleartext traffic policy issues in Android/iOS app binaries.

Impacts#

Intercept sensitive data such as login credentials, session cookies, and API tokens transmitted over insecure connections.
Perform Man-in-the-Middle attacks to read or modify requests and responses between users and the application.
Downgrade secure connections to weaker protocols, reducing encryption strength and enabling decryption.
Replay intercepted requests to perform unauthorized actions on behalf of legitimate users.
Inject malicious JavaScript via tampered mixed-content resources, escalating a transport-layer weakness into effective XSS.
Full session hijacking via stolen cookies lacking the Secure flag, particularly on shared/public networks.

Prevention Techniques#

Enforce HTTPS across the entire application - every path, not just login/checkout.
Redirect all HTTP requests to HTTPS at the earliest possible point (ideally at the load balancer/edge, not just in application code).
Implement HSTS with a max-age of at least one year, includeSubDomains, and submit to the HSTS preload list where appropriate.
Disable outdated protocols: SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1.
Configure strong cipher suites only - prefer AEAD ciphers (AES-GCM, ChaCha20-Poly1305), disable CBC/RC4/3DES/export/NULL ciphers.
Set Secure, HttpOnly, and SameSite flags on all session cookies.
Eliminate mixed content - audit all embedded resources (JS, CSS, images, iframes, API calls) to confirm they load over HTTPS.
Use valid certificates from trusted CAs; monitor expiry dates and automate renewal.
Implement certificate pinning for mobile applications communicating with first-party APIs.
Regularly re-scan with testssl.sh/sslscan as part of CI/CD, since TLS configuration can silently regress after infrastructure changes.

Tools#

testssl.sh, sslscan - TLS/cipher/protocol scanning
Burp Suite (Proxy / Repeater) - manual interception and downgrade testing
Nmap (ssl-enum-ciphers) - protocol/cipher enumeration
openssl s_client - manual certificate and protocol inspection
Wireshark / tcpdump - packet-level confirmation of cleartext transmission
Frida - runtime SSL pinning bypass on mobile apps
MobSF - automated mobile app transport security analysis

Good to Read#

OWASP WSTG - Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection
Qualys SSL Labs - SSL/TLS Deployment Best Practices
RFC 8996 - Deprecating TLS 1.0 and TLS 1.1
OWASP Transport Layer Protection Cheat Sheet