SSL Stripping Detector

About SSL Stripping

SSL stripping (also known as SSL/TLS downgrade attack) is a man-in-the-middle attack where an attacker intercepts a user's connection and downgrades it from HTTPS to HTTP. The attacker establishes their own HTTPS connection to the server while communicating with the victim over unencrypted HTTP. Our detector checks if your website is vulnerable by testing HSTS enforcement, HTTPS redirect behavior, and certificate validation.

How to Use

Enter the domain name of the website you want to test.
Click "Run" to perform the SSL stripping vulnerability check.
Review the results showing HSTS status, HTTPS redirect behavior, and vulnerability assessment.
Follow the recommendations to enable HSTS and enforce HTTPS to protect against stripping attacks.

Use Cases

•Check if your website is vulnerable to man-in-the-middle downgrade attacks
•Verify HSTS (HTTP Strict Transport Security) is properly configured
•Audit HTTPS redirect chains for security gaps
•Ensure compliance with security best practices for transport layer security

Frequently Asked Questions

An SSL stripping attack exploits the fact that many users type a domain name without specifying HTTPS. An attacker intercepts the initial HTTP request and maintains an unencrypted connection with the victim while proxying the traffic to the legitimate HTTPS server. This allows the attacker to read and modify traffic in transit.

HSTS (HTTP Strict Transport Security) tells browsers to always connect to your site over HTTPS, even if the user types HTTP or clicks an HTTP link. This prevents SSL stripping attacks by ensuring the browser never makes an unencrypted request to your domain after the first HTTPS visit.

The recommended HSTS max-age is 31536000 seconds (1 year). You should also include the `includeSubDomains` directive to protect all subdomains. For maximum protection, consider submitting your domain to browser preload lists, which hardcode HSTS rules into browsers.

An active attack where someone on your network answers your HTTPS request with plaintext, having intercepted the connection before encryption started. Because the first request is made in the clear, the attacker can respond and the browser shows the page with no visible warning — the padlock is simply absent rather than alarming. It works because the browser had no prior instruction to insist on HTTPS.

Partly, and the part it stops is the easiest route. The attacker cannot serve plaintext from the origin's own redirect because the redirect itself points at HTTPS. But they can still intercept and rewrite that redirect before the browser sees it, so a redirect alone is not sufficient — which is exactly why HSTS exists and why the two together are the real answer.

Because it removes the browser's freedom to be downgraded. Once a domain is in the preload list, or once a browser has seen the header, it goes straight to HTTPS without making a plaintext request first — so there is no unencrypted request for an attacker to answer. That is the difference between mitigating stripping and preventing it, and it is why this page pairs the redirect finding with the header recommendation.

You can test the conditions rather than run the attack. Make a plain HTTP request and inspect where it goes, check for the HSTS header on the HTTPS response, and confirm the domain is in the preload list. Tools exist that perform actual stripping simulations, but they need a network position you would not have in production — which is precisely the position an attacker needs and you do not.

No, not for the first request. The certificate only protects connections that are already encrypted, so a browser deciding what to do with a plaintext request has not yet used it. This is why a perfectly valid certificate and a strippable connection coexist happily — and why people with good certificates are still surprised to be read over the shoulder at a cafe.

How Stripping Is Detected

SSL stripping is an active attack: an interceptor answers your HTTPS request with plaintext and downgrades the browser silently. This page tests the specific precondition that makes it possible.

1Request the site over plain HTTP and read the Location header of the response. Whether that redirect points at HTTPS is the crux: an attacker can only strip a connection the browser was not already committed to keeping encrypted.
2Report the verdict from that redirect alone, stating the destination scheme. A redirect to HTTPS closes the easiest stripping route; anything else leaves the downgrade available.
3Say what this does not prove. A redirect is necessary but not sufficient: the attacker can also intercept the redirect itself, which is precisely what HSTS prevents. This page therefore reports the redirect and points at HSTS as the control that actually closes the gap.

The check is a precondition test, not an attack simulation. Nothing is sent to fool a browser here, and a pass means the redirect exists — the interception case needs the header policy on the HTTPS page to close.

Technical Details

Attack: SSL stripping attack detection and prevention
Protection: HSTS and HSTS preloading
Detection: HTTP to HTTPS downgrade detection
Output: SSL stripping protection status and recommendations

Results