Insecure TLS / SSL
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list specialist external tools — ssllabs, testssl.sh, owasp-zap, nmap — none of which are default linters or compilers. These require deliberate invocation against a running server, placing detection firmly in specialist-tool territory rather than automatic IDE/linter feedback.
Closest to 'simple parameterised fix' (e3). The quick_fix is a targeted web server config change: set minimum TLS 1.2, disable weak versions and cipher suites. This is a small, localised configuration update, not a one-liner swap (e1) but also not a multi-file refactor. PHP-side mistakes like CURLOPT_SSL_VERIFYPEER=false are individual call-site fixes, also e1–e3 range, keeping overall effort at e3.
Closest to 'localised tax' (b3). The misconfiguration primarily lives in web server config (Nginx/Apache) and individual curl call-sites, scoped to the web context. It imposes a compliance/audit burden and requires periodic re-checks as TLS standards evolve, but it does not reshape the broader application architecture or slow down unrelated work streams.
Closest to 'serious trap' (t7). The misconception field states exactly: developers believe 'any HTTPS connection is equally secure.' This directly contradicts the reality that TLS 1.0/1.1 and weak cipher suites leave HTTPS open to downgrade and interception. The trap is especially dangerous because CURLOPT_SSL_VERIFYPEER=false and self-signed cert workarounds feel like reasonable developer shortcuts but silently defeat all certificate validation — a contradiction with how the concept is named and presented.
Also Known As
TL;DR
Explanation
Insecure TLS configurations include using deprecated protocols (SSL 3.0, TLS 1.0, TLS 1.1), weak cipher suites (RC4, DES, 3DES, export-grade ciphers), short key lengths, or disabling certificate validation. These weaknesses can allow attackers to downgrade connections, exploit known protocol flaws like POODLE or BEAST, or perform man-in-the-middle attacks. PHP applications should enforce TLS 1.2+ in cURL and stream contexts, validate peer certificates, and follow Mozilla's SSL Configuration Generator recommendations.
Common Misconception
Why It Matters
Common Mistakes
- Setting CURLOPT_SSL_VERIFYPEER to false in curl calls — disables all certificate validation.
- Leaving TLS 1.0/1.1 enabled on the server — both are deprecated and vulnerable to downgrade attacks.
- Using self-signed certificates in production without adding them to the trust store — developers disable verification instead.
- Cipher suites that include NULL, RC4, or export-grade encryption — negotiated in downgrade attacks.
Code Examples
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);// Never disable peer verification; set a trusted CA bundle instead:
curl_setopt($ch, CURLOPT_CAINFO, '/etc/ssl/certs/ca-certificates.crt');