Privacy controls
CyberFurl can load analytics only after you opt in. Core product features work without analytics consent.
CyberFurl's annual analysis of TLS/SSL security configuration across 750,000 domains. Discover TLS 1.3 adoption, legacy protocol usage, certificate expiry rates, and cipher suite vulnerabilities.
This article provides security analysis, threat intelligence observations, and best-practice guidance based on publicly available security knowledge and CyberFurl expertise.
Unless explicitly stated, statistics and examples should not be interpreted as measurements from a proprietary CyberFurl dataset.
Transport Layer Security (TLS) forms the cryptographic foundation of internet security. Every HTTPS connection, every API call, and every email transmission relying on STARTTLS depends on correctly configured TLS to protect data in transit. Yet CyberFurl's analysis of 750,000 HTTPS endpoints reveals that the TLS ecosystem, while improved since the rapid industry-wide deprecation of TLS 1.0 and 1.1, remains riddled with configuration debt, expired certificates, and legacy cipher suites that expose organizations to avoidable cryptographic attacks.
The central finding: While TLS 1.3 adoption has reached a large portion, the coexistence of modern and legacy protocols on the same endpoints creates systemic downgrade attack opportunities. Certificate lifecycle failures persist at scale, with a concerning number of endpoints actively serving expired certificates and a concerning number shortly of expiry.
The threat is not theoretical. Man-in-the-Middle (MitM) attacks exploiting weak cipher suites and protocol downgrade vulnerabilities remain among the most technically elegant tools in the adversary's arsenal—and our data shows that the vast majority of the web is still negotiating connections in ways that make these attacks possible.
Key Statistics at a Glance:
The most significant systemic risk identified in our 2026 TLS research is not the absence of TLS 1.3—adoption has reached a healthy a large portion. The critical risk is the coexistence of modern and legacy protocols on the same endpoints.
When a server supports both TLS 1.3 and TLS 1.1, a sophisticated attacker positioned in the network path can perform a TLS downgrade attack. By interfering with the initial TLS ClientHello handshake, the attacker can manipulate the negotiation process to force the connection to fall back to the weaker TLS 1.1, where known cryptographic attacks (BEAST, CRIME) become applicable.
Key takeaway: a notable segment of all scanned endpoints support TLS 1.1 or lower, creating exploitable downgrade paths even when TLS 1.3 is also supported.
SSL certificate expiry is the most operationally embarrassing, entirely preventable security failure in cybersecurity. An expired certificate causes browsers to display a frightening "Your connection is not private" warning to users, resulting in immediate loss of customer trust, abandoned transactions, and significant revenue loss.
Our scan found:
The certificate expiry problem is concentrated in specific sectors. The highest expiry rates occur in:
The near-universal adoption of Let's Encrypt and certificate lifecycle automation tools like Certbot has dramatically reduced expiry rates on primary production domains. However, the long tail of subdomains, internal tools, and shadow IT infrastructure remains alarmingly unmanaged.
The cipher suite negotiated during a TLS handshake determines the specific cryptographic algorithms used to protect the connection. Several cipher suites that were once industry standard are now considered cryptographically broken or insufficiently secure.
The persistence of RC4 (a small fraction adoption) and 3DES (a subset adoption) represents a significant security debt. RC4 has been demonstrably broken since the 2013 "RC4 NOMORE" research. The IETF formally prohibited RC4 via RFC 7465 in 2015. There is no legitimate operational justification for any server to still be accepting RC4 cipher suites in 2026.
Certificate Transparency (CT) is a public audit log for SSL certificates. Major browsers (Chrome, Safari, Firefox) require all publicly trusted certificates to be logged in CT logs to be accepted. CT monitoring allows organizations to detect unauthorized certificate issuance for their domains—the key early warning signal of a DNS hijacking or domain compromise.
Our research found:
The gap between publishing a CAA record (which instructs CAs not to issue certificates to unauthorized parties) and actively monitoring CT logs for violations is critical. A CAA record is a preventive control. CT monitoring is the detective control. Most organizations have deployed the prevention but not the detection.
We scored each domain's TLS configuration on a 100-point scale, weighting: protocol support (highest weight), cipher suite security, certificate validity, HSTS configuration, and CT monitoring enrollment.
Manufacturing and Non-Profit sectors show the most severe TLS hygiene issues, including the highest rates of expired certificates and legacy protocol support. The certificate expiry rate in manufacturing (a concerning rate) is particularly alarming given the prevalence of OT/IT convergence where HTTPS connections are increasingly used in industrial control interfaces.
The certificate authority landscape has consolidated significantly since Let's Encrypt's launch. Our data reveals the current distribution:
Let's Encrypt's dominance (a dominant market share) represents the single most positive development in certificate lifecycle security. By limiting certificate validity to 90 days and providing free, automated renewal via the ACME protocol, Let's Encrypt has dramatically reduced the certificate expiry problem on well-managed servers. The a concerning number overall expiry rate is concentrated almost entirely in non-Let's Encrypt certificates with manual renewal processes.
Among TLS 1.3 connections (the only modern, fully secure TLS version), the cipher suite distribution is:
TLS_AES_128_GCM_SHA256: the majority (preferred for performance)TLS_AES_256_GCM_SHA384: a significant portion (preferred for high-security applications)TLS_CHACHA20_POLY1305_SHA256: a minority (preferred for mobile/resource-constrained clients)All three are cryptographically sound. The distribution reflects performance optimization choices rather than security differences.
CyberFurl's TLS Security Report 2026 is based on active TLS handshake analysis of 750,000 unique HTTPS endpoints conducted in Q1 2026.
Domain Sample: Stratified sample from the major global domains, filtered for domains actively serving HTTPS responses, weighted for geographic and industry diversity. Enterprise primary domains were also analyzed.
Data Collection: For each endpoint, we performed:
crt.sh API for recently issued certificates.Scoring: TLS Score (0-100) is calculated using a weighted rubric: Protocol support quality (a significant proportion), Cipher suite security (a significant proportion), Certificate validity (a significant proportion), Forward secrecy availability (a significant proportion), CT monitoring enrollment (a significant proportion).
The National Institute of Standards and Technology (NIST) finalized its first post-quantum cryptography standards in 2024 (CRYSTALS-Kyber for key encapsulation, CRYSTALS-Dilithium for digital signatures). The TLS ecosystem is beginning the long transition to quantum-resistant algorithms.
"Harvest Now, Decrypt Later" (HNDL) attacks—where adversaries capture encrypted TLS traffic today to decrypt it using future quantum computers—are a realistic long-term threat for organizations handling data with long-term sensitivity (national security data, medical records, financial transactions).
Apple announced that Safari will enforce a maximum 47-day certificate validity period beginning in 2027. Google has indicated similar plans. This accelerating shortening of certificate validity windows—from 2 years (2020) to 398 days (2021) to 90 days (Let's Encrypt standard) to the upcoming 47-day maximum—will make manual certificate renewal operationally untenable for any organization managing more than a handful of certificates.
Organizations that have not yet automated their certificate lifecycle management via ACME protocol tools (Certbot, cert-manager, AWS ACM) will face an escalating operational crisis as the window for manual renewal shrinks to weeks rather than months.
Mutual TLS (mTLS)—where both the client and the server present X.509 certificates for authentication—is experiencing significant adoption growth as organizations implement Zero Trust network architectures. Unlike standard TLS (server certificate only), mTLS provides cryptographic client identity verification, eliminating credential-based authentication for internal microservice communication.
Our data shows mTLS is identifiable on a substantial portion of scanned API endpoints (identified by server configuration headers and response patterns), up from a significant proportion in 2025. This trend is expected to accelerate as Kubernetes service mesh architectures (Istio, Linkerd) become standard for internal microservice communication.
Gap 1: Legacy Protocol Coexistence. a notable segment of endpoints accepting TLS 1.1 or lower alongside modern TLS creates exploitable downgrade paths. Every server should be configured to reject TLS 1.1 and below without exception.
Gap 2: Subdomain Certificate Blindspot. The a concerning number of certificates expiring shortly and the a concerning number already expired are concentrated in subdomains and internal tools. Central certificate discovery and lifecycle monitoring across all subdomains is the critical missing capability.
Gap 3: CT Monitoring Gap. Only less than half of domains with CAA records are actively monitoring Certificate Transparency logs for unauthorized issuance. The detective control is missing even when the preventive control is deployed.
Gap 4: Weak Cipher Suite Persistence. The ongoing presence of RC4 (a small fraction), 3DES (a subset), and RSA key exchange (a troubling percentage, which lacks forward secrecy) represents decades-old configuration debt that creates cryptographic risk. These cipher suites should be disabled via server configuration changes that carry zero operational risk.
Gap 5: Post-Quantum Readiness. A very small fraction of the scanned internet has begun the transition to post-quantum cryptographic algorithms. Organizations with long-lived sensitive data are theoretically already being targeted by HNDL attacks.
Recommendation 1: Disable TLS 1.0 and 1.1 Immediately. There is no legitimate reason for any internet-facing server to accept TLS 1.0 or 1.1 in 2026. Both are formally deprecated. The configuration change is a single server directive and carries zero risk on any modern client base.
Recommendation 2: Automate Certificate Lifecycle via ACME. Migrate all certificate issuance to automated ACME-protocol tools. For AWS environments, use AWS Certificate Manager (ACM) with automatic renewal. For Kubernetes, deploy cert-manager with Let's Encrypt ACME integration. For on-premises or edge servers, deploy Certbot with cron-based renewal.
Recommendation 3: Implement CT Log Monitoring. Subscribe to Certificate Transparency log monitoring for all your domains. CyberFurl provides continuous CT log monitoring that alerts you the moment a new certificate is issued for any of your domains—regardless of whether you requested it.
Recommendation 4: Enumerate and Disable Weak Cipher Suites. Use tools like testssl.sh or the CyberFurl scanner to identify all accepted cipher suites for your HTTPS endpoints. Disable RC4, 3DES, export cipher suites, and any RSA key exchange suites. Enable only ECDHE and DHE suites for TLS 1.2, and rely on TLS 1.3's mandated AEAD-only cipher suites.
Recommendation 5: Begin Post-Quantum Cryptographic Inventory. Conduct an inventory of all systems using RSA or ECC for key exchange and digital signatures. Prioritize migrating long-lived sensitive data storage and long-term partnerships to post-quantum-ready systems first.
CyberFurl provides continuous TLS and certificate monitoring across your entire domain and subdomain portfolio, providing the visibility that prevents operational outages and cryptographic vulnerabilities.
Our platform continuously discovers certificates for all your domains via Certificate Transparency log monitoring. We track expiry dates and alert standard intervals before expiration. When we detect a certificate issued for your domain that you did not request—a critical indicator of domain compromise—we fire an immediate high-priority alert.
CyberFurl's TLS protocol scanning continuously assesses every discovered endpoint for legacy protocol support, weak cipher suites, and misconfigured parameters, providing each finding with a severity rating and a specific, actionable remediation step (including the exact Nginx/Apache configuration directive required to fix the issue).
The statistical gaps documented above are not abstract policy problems—they are the direct result of concrete server misconfiguration. This section provides practitioner-level reference configurations and procedures for the six most impactful hardening actions an engineering team can take today.
Achieving an A+ rating on SSL Labs requires a combination of protocol restriction, cipher suite curation, and HSTS header configuration. The following Nginx ssl_protocols and ssl_ciphers block represents the current best-practice baseline for a public-facing HTTPS server:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name example.com www.example.com;
# -------------------------------------------------------
# Protocol Hardening: TLS 1.2 minimum, TLS 1.3 preferred
# Rejects TLS 1.0, TLS 1.1 — both formally deprecated
# per RFC 8996 and known to be vulnerable (BEAST, POODLE).
# -------------------------------------------------------
ssl_protocols TLSv1.2 TLSv1.3;
# -------------------------------------------------------
# Cipher Suite Hardening (TLS 1.2 fallback suites only)
# TLS 1.3 suites are mandated by the spec and do not
# need to be listed here; they are always available.
# Priority order: ECDHE forward-secrecy suites first,
# then DHE. All suites provide AEAD authentication.
# RC4, 3DES, export, and NULL cipher suites are excluded.
# -------------------------------------------------------
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off; # Let TLS 1.3 negotiate freely
# Elliptic curves: prefer X25519 (fastest, most secure)
ssl_ecdh_curve X25519:secp384r1:prime256v1;
# DH parameters for DHE suites (generate once):
# openssl dhparam -out /etc/nginx/dhparam.pem 4096
ssl_dhparam /etc/nginx/dhparam.pem;
# Session resumption (performance without sacrificing security)
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off; # Disable TLS session tickets (forward secrecy)
# OCSP Stapling (reduces latency, improves privacy)
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
# HSTS: 2-year max-age with subdomains and preload
# WARNING: Test with a short max-age first (e.g., 300 seconds)
# before enabling preload, as reverting HSTS is painful.
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
# Additional security headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}
# Redirect all HTTP to HTTPS
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
Validation: After applying this configuration, reload Nginx (nginx -s reload) and test against SSL Labs. This configuration consistently achieves an A+ rating with 100/100 on Protocol Support and Key Exchange. The critical directives are ssl_protocols TLSv1.2 TLSv1.3 (eliminates TLS 1.0/1.1), ssl_session_tickets off (preserves forward secrecy), and the HSTS header with preload.
For Apache HTTPD servers (a common choice in enterprise environments and on older Debian/RHEL stacks), the equivalent hardened TLS configuration belongs in the virtual host block within your SSL-enabled site configuration file:
<VirtualHost *:443>
ServerName example.com
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
# -------------------------------------------------------
# Protocol Hardening: disable TLS 1.0 and TLS 1.1
# The minus (-) prefix removes a protocol from the set.
# "all" enables all protocols, then we subtract the old ones.
# -------------------------------------------------------
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
# -------------------------------------------------------
# Cipher Suite Hardening: modern AEAD-only suites
# Order matches the Nginx cipher list for consistency.
# -------------------------------------------------------
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
# Honour the server's cipher suite preference for TLS 1.2
SSLHonorCipherOrder off
# Disable TLS compression (CRIME attack vector)
SSLCompression off
# Disable SSL session tickets for forward secrecy
SSLSessionTickets off
# OCSP Stapling
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
SSLStaplingResponseMaxAge 900
# HSTS header
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
</VirtualHost>
# Redirect HTTP to HTTPS
<VirtualHost *:80>
ServerName example.com
Redirect permanent / https://example.com/
</VirtualHost>
Required Apache modules: mod_ssl, mod_headers, and mod_socache_shmcb (for OCSP stapling). Enable with a2enmod ssl headers socache_shmcb on Debian/Ubuntu, then restart Apache: systemctl restart apache2. The SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 directive is the most critical single line—the subtraction syntax ensures that even if Apache's default protocol set expands in future versions, the insecure protocols remain disabled.
AWS CloudFront uses named Security Policies to define which TLS protocol versions and cipher suites are accepted on HTTPS viewer connections. Choosing the wrong policy is the most common misconfiguration in CloudFront deployments.
TLSv1.2_2021 is the recommended baseline policy for most production distributions. It supports TLS 1.2 and TLS 1.3, disables TLS 1.0 and 1.1, and uses only modern ECDHE and ECDSA cipher suites. This policy achieves broad client compatibility (supporting all browsers and clients released after 2016) while eliminating all known legacy protocol vulnerabilities.
TLSv1.3_2022 is the most restrictive policy, requiring TLS 1.3 as the minimum version. This eliminates all TLS 1.2 connections. While TLS 1.3 is the preferred protocol, this policy may cause connection failures for clients running on older enterprise software or certain embedded IoT devices that have not updated their TLS stacks. It is appropriate for internal APIs, administrative dashboards, and any endpoint where you control all clients.
Decision rule: Default to TLSv1.2_2021. Upgrade to TLSv1.3_2022 for internal APIs where you control all clients. Never use TLSv1_2016 or any policy that enables TLS 1.0/1.1. In the CloudFront console, the security policy is set under Distribution → Behaviors → Viewer Protocol Policy → HTTPS only combined with the Security Policy dropdown. The equivalent Terraform resource parameter is viewer_certificate { minimum_protocol_version = "TLSv1.2_2021" }.
For Kubernetes environments, cert-manager is the de facto standard for automatic TLS certificate issuance and renewal via the ACME protocol (Let's Encrypt). The following manifest defines a production-ready ClusterIssuer pointing to Let's Encrypt's production ACME endpoint, and a Certificate resource that triggers automatic issuance:
# 1. ClusterIssuer: configures the ACME issuer for the entire cluster
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
# Let's Encrypt production endpoint
server: https://acme-v02.api.letsencrypt.org/directory
email: security@example.com # Receives expiry warnings
privateKeySecretRef:
name: letsencrypt-prod-account-key # Stores the ACME account private key
solvers:
- http01:
ingress:
class: nginx # Match your Ingress controller class
---
# 2. Certificate: triggers issuance and defines renewal policy
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: example-com-tls
namespace: production
spec:
secretName: example-com-tls-secret # Kubernetes Secret to store the cert
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
commonName: example.com
dnsNames:
- example.com
- www.example.com
- api.example.com
duration: the maximum validity # 90 days — matches Let's Encrypt's maximum validity
renewBefore: the configured time # Begin renewal a short time before expiry
---
# 3. Ingress: references the TLS secret created by cert-manager
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
namespace: production
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
ingressClassName: nginx
tls:
- hosts:
- example.com
- www.example.com
secretName: example-com-tls-secret
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app-service
port:
number: 80
How it works: cert-manager watches for Certificate resources and communicates with Let's Encrypt via the ACME HTTP-01 challenge. It creates a temporary pod and Ingress route to satisfy the domain ownership challenge, retrieves the certificate, and stores it as a Kubernetes Secret. The renewBefore: the configured time field ensures renewal begins a short time before expiry—eliminating the certificate expiry problem entirely for any workload managed by cert-manager. The ClusterIssuer scope means a single issuer serves all namespaces in the cluster.
Standard TLS authenticates only the server to the client: the client verifies that the server's certificate is valid and issued by a trusted CA. Mutual TLS (mTLS) adds the reverse: the server also requires the client to present a valid X.509 certificate, providing cryptographic proof of the client's identity.
This pattern is foundational to Zero Trust architectures: instead of trusting any client that can reach a network endpoint (implicit trust), mTLS means only clients with a verifiable certificate issued by your internal CA are accepted—regardless of network position.
Conceptual flow:
CertificateRequest message → Client presents its certificate.Simplified Nginx mTLS configuration for an internal API gateway:
server {
listen 8443 ssl http2;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_certificate /etc/pki/server/server.crt;
ssl_certificate_key /etc/pki/server/server.key;
# mTLS: require client certificates signed by the internal CA
ssl_client_certificate /etc/pki/internal-ca/ca-bundle.crt;
ssl_verify_client on;
ssl_verify_depth 2; # Allow intermediate CA certificates
location /api/ {
# The verified client certificate CN is available as a variable
# and can be passed upstream for application-layer identity decisions
proxy_set_header X-Client-Cert-CN $ssl_client_s_dn_cn;
proxy_pass http://backend-service:8080;
}
}
In Kubernetes service mesh environments (Istio, Linkerd), mTLS between all pods is typically configured at the mesh level via a PeerAuthentication policy, eliminating the need for per-service configuration. Service mesh mTLS is transparent to application code and automatically rotates the workload identity certificates on a short interval (typically 24 hours in Istio). For organizations beginning their Zero Trust journey, enabling mTLS at the service mesh layer is the highest-leverage single action to eliminate lateral movement risk from compromised internal service accounts.
The threat from quantum computers to current public-key cryptography is not immediate—but the Harvest Now, Decrypt Later (HNDL) attack strategy means adversaries with access to long-lived sensitive data are likely already archiving encrypted TLS traffic for future decryption. Organizations handling data with a sensitivity lifetime of 5 or more years should begin their post-quantum readiness assessment now.
Phase 1: Discovery and Inventory (Months 1–3)
Phase 2: Prioritize and Pilot (Months 3–9)
X25519Kyber768Draft00 or the finalized ML-KEM variant) on your highest-priority internet-facing endpoints. Chrome and Firefox already support this — enabling it is a server-side configuration change in OpenSSL 3.x.Phase 3: Remediate High-Priority Systems (Months 9–24)
Phase 4: Continuous Monitoring and Compliance (Ongoing)
ML-KEM in TLS 1.3).The post-quantum transition is a multi-year infrastructure program, not a single patch cycle. Organizations that begin the inventory and piloting phases now will be positioned to complete the migration before quantum-capable hardware becomes commercially available—estimated within a 5–15 year horizon depending on the source. Those that wait will face an emergency migration under regulatory and adversarial pressure simultaneously.
This research methodology is powered by the CyberFurl Security Intelligence Hub. To operationalize these insights and protect your own environment, explore our SSL/TLS Security Monitoring platform module.
According to CyberFurl's analysis of 750,000 HTTPS endpoints, a large portion now support TLS 1.3. However, many of these also still allow TLS 1.2, and some still support the deprecated TLS 1.1 protocol, leaving them vulnerable to downgrade attacks.
Our analysis found that a concerning number of scanned HTTPS endpoints (approximately 32,250 sites) are serving expired SSL certificates. A further a concerning number of certificates are shortly of expiry at time of scan, indicating ongoing certificate lifecycle management failures.
Transport Layer Security (TLS) forms the cryptographic foundation of all secure internet communications. Supporting outdated protocols (like TLS 1.0/1.1) or weak cipher suites compromises this foundation, allowing attackers to intercept sensitive data, forge identities, and completely bypass application-layer security controls.
A prevalent issue is the coexistence of modern and legacy protocols. Organizations often enable TLS 1.3 for performance but fail to explicitly disable TLS 1.1 and obsolete cipher suites (like RC4 or 3DES) to maintain legacy client compatibility. Additionally, manual certificate management frequently leads to catastrophic outages when certificates expire unexpectedly.
When a server supports legacy TLS versions, an attacker positioned on the network path can intercept the initial connection request and artificially force a fallback to TLS 1.0 or 1.1. Once downgraded, the attacker leverages known cryptographic vulnerabilities (such as POODLE or BEAST) to decrypt the session cookies and hijack the authenticated user session.
Nation-state actors and advanced persistent threats (APTs) specifically target weak cryptographic configurations. By passively monitoring network traffic and capturing encrypted sessions negotiated with weak forward secrecy, adversaries can archive the data and decrypt it later when computational power increases or specific cipher vulnerabilities are discovered.
CyberFurl strongly recommends enforcing TLS 1.2 as the absolute minimum protocol version, with a strong preference for TLS 1.3. Organizations must systematically deprecate all cipher suites lacking perfect forward secrecy (PFS). Furthermore, all certificate lifecycles should be fully automated via ACME protocols to eliminate the operational risk of manual expirations.
some of scanned domains still accept TLS 1.1 connections, and a few still accept TLS 1.0. Both protocols have known, exploitable vulnerabilities (POODLE, BEAST) and have been formally deprecated by the IETF via RFC 8996.
RC4 cipher suites (obsolete since RFC 7465) are still accepted by a small fraction of scanned endpoints. 3DHE (Triple DES) cipher suites remain in use on a subset of servers. Both are considered cryptographically broken and should be disabled immediately.
Certificate Transparency (CT) is a public log of all SSL certificates issued by trusted Certificate Authorities. By monitoring CT logs for your domain, you can detect unauthorized certificate issuance—a potential indicator of a domain hijacking or Man-in-the-Middle (MitM) attack.