SSL/TLS

Approximately 19% of mobile and web APIs still allow HTTP fallback instead of enforcing TLS, leaving sensitive data and authentication credentials exposed to interception.

Many programming languages (Python, Ruby, PHP, Perl) have insecure certificate verification defaults, either not verifying certificates at all or only checking the trust chain without hostname verification. This is fixed slowly due to backward-compatibility concerns.

Developers struggle to configure SSL/TLS securely, with many systems defaulting to insecure protocols (SSLv3, TLS 1.0/1.1) and weak cipher suites (RC4) that remain enabled despite known vulnerabilities. Balancing security best practices against legacy client compatibility requires expertise and continuous vigilance.

IoT devices have limited hardware capabilities for TLS operations, infrequent firmware updates, hardcoded certificates, weak random number generation, and lack of automated certificate rotation. Poor TLS in IoT exposes entire networks.

15% of publicly accessible certificates are self-signed, expiring twice as frequently as CA-issued certificates. Self-signed certificates require users to bypass browser security warnings, creating friction and opening the door to man-in-the-middle attacks.

The CA-based certificate trust model is fundamentally flawed, with OCSP/CRL revocation verification being nearly useless (soft-fail allows connections despite revocation). SSL pinning is difficult to implement and easy to break. CA infrastructure itself creates risk vectors, and certificate issuance relies on unverified DNS and email.

Cross-signing of CA certificates creates multiple possible trust chains. Different SSL stacks (Windows, OpenSSL) behave differently during verification, causing some platforms to fail validation while others succeed.

No single owner is responsible for SSL/TLS lifecycle tasks (updates, monitoring, renewal), leading to missed renewals, incomplete deployments, and configuration drift.

Managing SSL/TLS configurations becomes increasingly complex when multiple microservices require separate certificates. DNS synchronization issues across cloud platforms (AWS, Azure) make it difficult to automate certificate issuance and renewal with Let's Encrypt.

Early TLS versions had vulnerabilities in how renegotiation was handled, allowing man-in-the-middle attacks. Servers using older TLS libraries or failing to implement secure renegotiation remain vulnerable.

SSL adds significant computational costs through encryption/decryption and TLS handshake operations, increasing latency. Debugging SSL-related issues (certificate mismatches, mixed-content errors, protocol mismatches) is time-consuming and requires expertise.

Nginx experiences CPU saturation during SSL-heavy traffic, complex rewrite rules, or inefficient buffering, causing throughput drops and slowed request processing. Requires optimization of TLS sessions, cipher suites, and regex patterns.

SNI is only supported in TLS 1.x, not SSL 3.0. Additionally, older clients (MSIE on XP, Java 6, Android versions, and some programming languages) lack SNI support, causing certificate errors when multiple certificates are hosted on the same IP address.

Approximately 22% of organizations fail to monitor Certificate Transparency logs for fraudulent certificate issuance, making them vulnerable to man-in-the-middle attacks using unauthorized certificates.

TLS-level and HTTP-level compression can leak secret data like CSRF tokens through compression side-channels. Teams must carefully handle compression of responses containing secrets.

The Root CA may be known on the system but not present in the specific application's trust store, causing certificate verification failures even though the CA is globally trusted.

Users struggle with the complexity of Cloudflare's configuration, particularly with setting up SSL certificates correctly, requiring navigation of an extensive feature set.

Attackers obtain valid SSL certificates for phishing domains, making malicious sites appear legitimately encrypted. This bypasses user trust signals and makes phishing campaigns more effective.