Unencrypted Communication (Cleartext Transmission)
Also known as: Cleartext transmission, Plaintext protocols, Missing TLS, Sensitive data in transit unencrypted
A service sends credentials or sensitive data over plain HTTP or another unencrypted protocol, so anyone on the network path can read it.
How it works
Cleartext transmission means sensitive data, such as passwords, session tokens, personal records or card data, is sent across a network without encryption. Any device on the path, including shared switches, Wi-Fi, a compromised router or a cloud network tap, can read it simply by capturing traffic.
It happens for ordinary reasons. A login form is served over http://, a file-transfer job still uses FTP, an admin uses Telnet, an application connects to its database with TLS disabled because it was easier in testing, or mail relays accept plain SMTP. Nothing breaks, so nobody notices.
Defenders find it through inventory and traffic. Scans show listeners on plaintext ports, configuration files contain http:// URLs and sslmode=disable style settings, and network monitoring shows protocol decodes with readable credentials on internal segments.
The fix is to make encryption the default and the only option: HTTPS everywhere with HSTS, secure replacements for legacy protocols, verified TLS on database and service-to-service links, and the old plaintext listeners switched off rather than merely discouraged.
Walk through it
- 1Name the cleartext protocol
- 2Fix the database connection
- 3Redirect the web listener
- Retire Telnet and plain SMTP
- Prove nothing sensitive is still clear
A packet-capture review on the partner file-exchange segment shows readable login lines. Read the capture and name the protocol that is carrying credentials in the clear.
$ tshark -r partner-segment.pcap -Y 'tcp.port==21' -T fields -e ip.src -e ip.dst -e ftp.request.command198.51.100.20 203.0.113.15 USER198.51.100.20 203.0.113.15 PASS198.51.100.20 203.0.113.15 STOR# Command channel on TCP 21 is readable; no TLS handshake precedes the login.
Spot it
- Listeners or flows on plaintext ports such as 21 (FTP), 23 (Telnet), 25 without STARTTLS, 80, 110 and 143.
- Protocol decodes in network monitoring that expose usernames, passwords or tokens in readable form.
- Application configuration containing http:// endpoints or database parameters such as sslmode=disable or encrypt=false.
- Login or checkout pages served over http://, or HTTPS pages that submit forms to http:// URLs.
- HTTPS responses that lack Strict-Transport-Security on hosts that handle credentials.
- Internal east-west traffic between services with no TLS handshake, especially across cloud or VLAN boundaries.
Network sensor (protocol decode)
ts=2026-10-11T08:14:02Z src=198.51.100.20 dst=203.0.113.15 dport=21 proto=ftp cmd=USER tls=false
ts=2026-10-11T08:14:02Z src=198.51.100.20 dst=203.0.113.15 dport=21 proto=ftp cmd=PASS tls=falseConfig scanner
file=orders-service/db.properties key=db.sslmode value=disable severity=high rule=cleartext-db-linkkqlConnections to plaintext management and transfer ports
DeviceNetworkEvents
| where RemotePort in (21, 23, 110, 143)
| summarize flows = count() by DeviceName, RemoteIP, RemotePort, bin(Timestamp, 1d)
| order by flows descPort numbers identify the protocol only by convention; confirm with a decode.
grepCleartext endpoints and disabled TLS in configuration
grep -rniE "(http://[a-z0-9.-]+|sslmode=disable|encrypt=false|ssl=false)" /srv/config --include=*.properties --include=*.yaml --include=*.envExpect some false positives such as localhost and documentation URLs.
Stop it
Encrypt all sensitive data in transit with current TLS
Serve every endpoint over HTTPS, replace FTP with SFTP or FTPS and Telnet with SSH, and require TLS on database, queue and service-to-service connections. Use modern protocol versions and verify certificates on the client side.
Make HTTPS the only path for browsers
Redirect port 80 to HTTPS with a permanent redirect, send Strict-Transport-Security on every HTTPS response, and mark session cookies Secure so they are never sent over HTTP.
Disable the cleartext listeners, then keep them off
Turn off legacy plaintext services instead of leaving them as an option, block the ports at network boundaries, and add configuration and port checks to the pipeline so cleartext cannot silently return.
Database connection with verified TLS
Vulnerable
db.sslmode=disableHardened
db.sslmode=verify-full
db.sslrootcert=/etc/pki/fabrikam-ca.pemrequire encrypts but does not check the server identity; verify-full does both.
HTTP listener that only redirects
Vulnerable
server { listen 80; location / { proxy_pass http://portal-app; } }Hardened
server { listen 80; return 301 https://$host$request_uri; }
# on 443: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;Roll HSTS out with a short max-age first, then raise it.
- Inventory every listener and outbound connection, and flag any sensitive flow without TLS.
- Redirect HTTP to HTTPS permanently and send HSTS with a max-age of at least one year.
- Replace FTP with SFTP or FTPS, Telnet with SSH, and plain SMTP with STARTTLS or implicit TLS enforced between relays.
- Require TLS with certificate verification on every database and internal API connection.
- Disable obsolete protocol versions and weak cipher suites on all TLS endpoints.
- Block plaintext ports at segment boundaries and alert on any new listener for them.
If it already happened
Block or redirect the plaintext service paths now, and disable the legacy listeners that cannot be fixed immediately.
Rotate every credential, token and key that crossed the network in the clear, and force sessions to be re-established over TLS.
Enable TLS or switch to the secure protocol, verify certificates on clients, and confirm with a fresh scan and capture that nothing sensitive is still readable.
Add cleartext port, protocol-decode and configuration checks to monitoring and CI, and make TLS the default in service templates.
Check yourself
1. A capture shows USER and PASS commands readable on TCP port 21. What is the best remediation?
2. Which database setting best protects both confidentiality and server identity on a client connection?
3. Why is redirecting port 80 to HTTPS not sufficient on its own?