Encryption in Transit
debt(d7/e5/b5/t7)
Closest to 'only careful code review or runtime testing' (d7). Tools listed — semgrep, ssllabs, owasp-zap — are specialist scanners that can catch some cases (e.g. CURLOPT_SSL_VERIFYPEER false, HTTP URLs in code), but internal service calls to MySQL, Redis, or message queues without TLS are often invisible without network-level inspection or careful code review. The gap between the external HTTPS surface and internal unencrypted connections is not caught by default linters, pushing this to d7.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix says to enforce HTTPS for all traffic AND between all internal services, verify CURLOPT_SSL_VERIFYPEER, and add mTLS for service-to-service communication. Common mistakes span MySQL connections, cURL calls, internal microservice HTTP, and HSTS headers — these touch multiple configuration files, connection setup code, infrastructure config, and deployment settings. Not a single-line patch, but not a full architectural rewrite either.
Closest to 'persistent productivity tax' (b5). Encryption in transit applies to web, API, and CLI contexts. Every new service connection, DB connection, queue consumer, and cURL call must be reviewed for TLS compliance. It doesn't rewrite-or-live-with-it, but it is a persistent cross-cutting concern that slows down every new integration point and requires ongoing vigilance across the codebase and infrastructure.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception is canonically stated: developers assume HTTPS means all traffic is encrypted, but it only covers the browser-to-server leg. Database connections, internal service calls, and message queue connections are frequently unencrypted despite HTTPS being present. This directly contradicts the reasonable mental model that 'my app is secure because it uses HTTPS,' making it a serious, well-documented trap.
Also Known As
TL;DR
Explanation
Encryption in transit uses TLS (Transport Layer Security) to protect data between: browsers and web servers (HTTPS), services communicating internally (mTLS), application servers and databases, and message queues. HTTPS alone is insufficient if internal traffic is unencrypted — an attacker who compromises an internal network segment can intercept database credentials. Mutual TLS (mTLS) requires both parties to present certificates, eliminating the need for credentials in service-to-service communication.
Common Misconception
Why It Matters
Common Mistakes
- MySQL connection without SSL — credentials and all data in plaintext on the network.
- CURLOPT_SSL_VERIFYPEER = false — disables certificate verification, enabling MITM.
- Internal microservice communication over plain HTTP — encrypted external, unencrypted internal.
- Not using HSTS — allows the first request to be downgraded from HTTPS to HTTP.
Code Examples
// Unverified TLS — MITM possible:
$ch = curl_init('https://payment-api.internal');
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); // Never!
// MySQL without SSL:
$pdo = new PDO('mysql:host=db.internal', 'user', 'pass');
// Credentials and queries in plaintext// Verified TLS:
$ch = curl_init('https://payment-api.internal');
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true); // Default — keep it
curl_setopt($ch, CURLOPT_CAINFO, '/etc/ssl/certs/ca-certificates.crt');
// MySQL with TLS:
$pdo = new PDO(
'mysql:host=db.internal;ssl_ca=/etc/ssl/mysql-ca.pem',
'user', 'pass',
[PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT => true]
);
// mTLS with client certificate:
curl_setopt($ch, CURLOPT_SSLCERT, '/certs/client.crt');
curl_setopt($ch, CURLOPT_SSLKEY, '/certs/client.key');