Every website in this list had a valid SSL certificate when it was breached. SSL encrypted the connections between users’ browsers and the servers. The padlock appeared in every visitor’s address bar. And none of that had any relevance to how the breach happened.
SSL does one thing: it encrypts data in transit between a browser and a web server, and it verifies that the server’s identity was checked by a Certificate Authority. It does not protect the web application from vulnerabilities. It does not protect the database from injection attacks. It does not protect the server from unpatched software. It does not prevent stolen credentials from being used. It does not stop a malicious insider. It does not protect cloud infrastructure from misconfiguration.
The misconception that SSL prevents hacking is the single most consequential misunderstanding in web security for small and medium businesses. This article documents it with named breaches and documented attack vectors, because the misconception costs real money when it becomes the reason a business stops thinking about security after installing a certificate.
What SSL Protects and What It Does Not
| SSL protects against this | SSL does NOT protect against this |
| Network eavesdropping: an attacker monitoring network traffic between the user and the server cannot read the content of encrypted connections | Application vulnerabilities: SQL injection, XSS, CSRF, and other web application attacks that occur on the server side |
| Man-in-the-middle attacks where an attacker attempts to intercept traffic between browser and server | Database breaches: once an attacker is inside the server through any means, they can access the database regardless of SSL |
| Unencrypted transmission of passwords and payment card numbers between browser and server | Stolen credentials: if a user’s password is phished or leaked from another breach, SSL does not prevent login with those credentials |
| Certificate spoofing: a valid certificate proves the server’s identity was verified by a CA | Unpatched server software: Apache Struts, WordPress plugins, and any other server-side software vulnerabilities are unaffected by SSL |
| DNS hijacking when HSTS is in place: HSTS prevents protocol downgrade attacks | Supply chain attacks: compromised third-party software, plugins, or libraries installed on the server |
| Session token exposure in transit: session cookies marked Secure are encrypted in transit | Cloud misconfiguration: AWS security group errors, exposed metadata services, publicly accessible S3 buckets |
The padlock tells you the connection to this server is encrypted. It tells you nothing about the security of the server itself, the application running on it, the database behind it, the credentials used to access it, or the supply chain of software it depends on. Every major breach in the list below occurred despite valid SSL because the attack did not target the encrypted connection.
The Breach Database: Major Sites Hacked with Valid SSL
Target: December 2013
Target’s ecommerce website had valid SSL throughout the 2013 holiday season breach. The attack had nothing to do with the web connection. Attackers compromised a third-party HVAC vendor (Fazio Mechanical Services) that had network access to Target’s systems. From that foothold, attackers installed RAM-scraping malware on Target’s point-of-sale terminals. The malware captured payment card data from memory before it was encrypted, then transmitted it to attacker-controlled servers.
SSL was irrelevant: the payment card data was stolen from POS terminal memory before it ever reached the SSL-encrypted web connection. The attack vector was vendor network access and POS malware, neither of which SSL certificates address. 40 million payment card records and 70 million customer records were exposed.
Heartbleed (OpenSSL): April 2014
Heartbleed (CVE-2014-0160) is the one case in this list where the SSL implementation itself had a vulnerability, and it is worth understanding precisely why it is still fundamentally different from a failure of SSL to prevent hacking.
Heartbleed was a buffer over-read vulnerability in OpenSSL’s implementation of the TLS heartbeat extension. An attacker could send a specially crafted heartbeat request that caused the server to return up to 64 kilobytes of server memory. That memory could contain private key material, session tokens, usernames, and passwords of recently connected users.
The vulnerability was in the OpenSSL software implementation, not in the TLS protocol or the certificate. A valid EV certificate on the same vulnerable server provided no additional protection against Heartbleed. The fix was patching OpenSSL to version 1.0.1g, not obtaining a different type of certificate. This distinction matters: Heartbleed demonstrated that SSL implementations can have vulnerabilities, which is why keeping server software patched is essential, and why SSL certificates alone are not a security posture.
Yahoo: 2013 and 2014 (disclosed 2016 and 2017)
Yahoo’s 2013 breach (3 billion accounts, the largest in history) and 2014 breach (500 million accounts) both occurred on systems with valid SSL. The 2014 breach was attributed to a state-sponsored actor. Attack vectors included stolen session cookies (forged using a proprietary tool), compromised internal Yahoo systems, and exploitation of backend vulnerabilities. Yahoo’s password storage used MD5 hashing without salting, which allowed rapid offline cracking of leaked password hashes.
SSL did not protect against: forged session cookies (an application-layer authentication issue), weak password hashing (a password storage architecture issue), or the backend system compromise. The user’s HTTPS connection to Yahoo was encrypted throughout. The attack was on Yahoo’s own internal infrastructure.
Equifax: May to July 2017
Equifax had valid SSL on its consumer-facing websites when attackers exploited CVE-2017-5638, a critical vulnerability in Apache Struts, the web application framework Equifax used. The vulnerability allowed remote code execution via a specially crafted Content-Type HTTP header. Apache had released a patch for the vulnerability in March 2017; Equifax failed to apply it. Attackers exploited the unpatched vulnerability in May 2017 and maintained access until July 2017.
147 million consumer records were exposed including Social Security numbers, birthdates, addresses, and driver’s license numbers. SSL was irrelevant: the attack entered through a request to the web application, which SSL encrypted in transit. The vulnerability was in the application framework, not the transport layer. An EV certificate on the same unpatched server would not have changed the outcome.
Marriott and Starwood: 2014 to 2018 (disclosed 2018)
The Marriott breach, attributed to the same state-sponsored group that conducted the Equifax breach, began in the Starwood Hotels reservation system in 2014. Starwood was acquired by Marriott in 2016. The attackers maintained persistent access through the acquisition, remaining in the network for four years. They used remote access tools and credential theft to move laterally through the network.
500 million guest records were exposed including passport numbers, payment card data, and contact information for guests over the four-year period. SSL on Starwood’s and Marriott’s websites encrypted user connections throughout. The breach was in the reservation database infrastructure, not in the web-facing encrypted connection. Persistent network access and credential theft are not prevented by SSL certificates.
LinkedIn: June 2012
LinkedIn was breached in 2012; 6.5 million password hashes were initially disclosed, but the full scope (117 million credentials) became clear when the data appeared on dark web markets in 2016. LinkedIn’s website had valid SSL. The attacker accessed LinkedIn’s password database and extracted hashed passwords. LinkedIn was using SHA-1 without salting for password hashing. Offline cracking of unsalted SHA-1 hashes is computationally feasible.
SSL encrypted every login connection. The issue was that the passwords, once extracted from the database via an application-layer breach, could be cracked offline. SSL does not protect database contents or password hashing methodology.
Adobe: October 2013
Adobe’s breach exposed 153 million user records including encrypted credit card data and poorly encrypted passwords. The passwords were encrypted (not hashed) with 3DES in ECB mode, which is cryptographically weak and allowed pattern analysis to recover passwords. The breach was via an application-layer vulnerability that gave attackers access to the Adobe customer database.
Adobe’s websites had valid SSL. The breach was not a transport-layer attack. An attacker who intercepts your connection to adobe.com cannot read your encrypted session. An attacker who gains direct database access does not need to intercept anything; SSL has no bearing on their ability to read database records.
Capital One: July 2019
Capital One’s breach exposed 100 million credit card applications in the United States and Canada. The attacker, a former AWS engineer, exploited a misconfigured Web Application Firewall on Capital One’s AWS infrastructure. This created a server-side request forgery (SSRF) vulnerability that allowed querying the AWS EC2 metadata service. From the metadata service, the attacker obtained temporary credentials for a high-privilege IAM role and used them to list and download S3 bucket contents.
Capital One’s customer-facing websites had valid SSL. The breach was in AWS cloud infrastructure configuration, specifically a misconfigured WAF and exposed metadata service. SSL certificates are not part of the AWS IAM, WAF, or S3 security model. The attack required no browser connection at all.
SolarWinds: December 2020
The SolarWinds supply chain attack compromised the build process for SolarWinds Orion, a network management platform used by thousands of organizations including US government agencies. Attackers injected malicious code (SUNBURST) into the legitimate SolarWinds Orion software update process. Organizations that applied the trusted, digitally signed software update unknowingly installed the backdoor.
SSL and code signing certificates were present throughout. The SolarWinds website used HTTPS. The malicious update was distributed over HTTPS. The attack exploited the trust in the software update distribution chain, not any failure of transport encryption. Supply chain attacks target the software itself, which SSL certificates cannot inspect.
British Airways: August to September 2018
British Airways was fined 20 million pounds by the UK Information Commissioner’s Office for a breach exposing 400,000 customer payment card details. The breach used a Magecart attack: attackers injected malicious JavaScript into British Airways’ website that captured payment card details and form data as users typed them, before the data was submitted over the encrypted connection.
British Airways’ website had valid SSL. The SSL encryption protected data after it was submitted. The malicious JavaScript ran in the user’s browser before data was submitted, capturing it in plaintext before encryption. This is a client-side attack that SSL cannot prevent. The relevant protection would have been Content Security Policy (CSP) headers and subresource integrity, not a different certificate type.
The Common Thread Across Every Breach
Every breach above had valid SSL. Every breach above used an attack vector that SSL does not and cannot address:
- Unpatched application software (Equifax): SSL encrypts the HTTP request that exploited the Apache Struts vulnerability. The encrypted delivery of an exploit payload is not a failure of SSL; it is the correct behavior of TLS.
- Supply chain compromise (Target, SolarWinds): SSL certificates are issued to domains, not to software integrity. A certificate that verifies target.com’s identity does not verify the integrity of the software running on target.com.
- Credential theft and lateral movement (Marriott, Yahoo): SSL protects one connection at one moment. Once an attacker has valid credentials, they can authenticate over that same encrypted connection legitimately.
- Database-level access (LinkedIn, Adobe, Equifax): SSL sits at the network transport layer. An attacker who bypasses the transport layer through an application vulnerability has direct database access that SSL does not protect.
- Client-side script injection (British Airways): SSL encrypts data in transit. Magecart attacks capture data before it transits. The malicious JavaScript ran in the user’s browser, a layer below SSL’s protection scope.
- Cloud infrastructure misconfiguration (Capital One): SSL is a certificate-and-protocol layer. AWS IAM, S3 permissions, and WAF configuration are infrastructure layers. They are independent.
What SSL Actually Gives You and What the Rest of Security Requires
An SSL certificate is necessary. It prevents eavesdropping on your users’ connections, protects passwords and payment data in transit, enables HSTS enforcement, and satisfies PCI DSS transport encryption requirements. These are real, important protections. The internet without HTTPS would be substantially more dangerous.
An SSL certificate is not sufficient. The breaches above represent a small fraction of the documented cases where organizations with valid SSL were compromised through application vulnerabilities, unpatched software, credential theft, supply chain attacks, and infrastructure misconfigurations. The attack surfaces that destroyed Target, Equifax, Yahoo, Marriott, and British Airways were not the encrypted connection. They were the application, the database, the cloud configuration, the software supply chain, and the authentication system.
A $5 DV certificate and a $400 EV certificate are identically irrelevant to these attack vectors. Certificate validation level does not change the protection SSL provides against application-layer attacks; it changes only the identity verification in the certificate. Neither type of certificate would have prevented any breach in this list.
The practical security posture that would have prevented or limited most breaches above: patch management (Equifax), vendor network segmentation (Target), server-side request forgery protections and cloud IAM hygiene (Capital One), build process integrity and code signing policy (SolarWinds), password hashing with bcrypt or Argon2 (LinkedIn, Adobe), and Content Security Policy (British Airways). SSL was a prerequisite for each of these organizations’ web security but not a factor in any of these specific breaches.
