Search
Table of Contents
- Machine Identity Security: The Definitive Guide
- What Is Workload Identity? Securing Non-Human Identities
- What Is a Non-Human Identity (NHI)? Machine Identity Security Explained
-
What Is a Machine Identity?
- How Do Machine Identities Work?
- Machine Identity Management (MIM) vs. Human IAM
- Architecture Components and Identity Types
- Secrets Management vs. Machine Identity Management
- Lateral Movement and Attacker Workflow
- Cloud Security Implications and CIEM
- Implementation Steps for Machine Identity Security
- Machine Identity FAQs
What Is an SSL Stripping Attack?
5 min. read
Table of Contents
An SSL stripping attack is an in-the-middle technique that downgrades a web session from HTTPS to HTTP, thereby removing encryption. The attacker maintains an HTTPS connection to the real site while serving the victim an HTTP response, exposing credentials and session data. This attack matters to identity security because it targets authentication and can enable account takeover.
Key Points
-
HTTPS downgrade: Attackers block the upgrade to HTTPS, keeping the victim on HTTP. -
Credential exposure: Usernames, passwords, and form data can be transmitted in plaintext on the victim's side. -
Session risk:Attackers can capture session identifiers if sessions are transmitted over insecure transport. -
Entry conditions: Public or hostile networks make interception easier, but any compromised path can work. -
Partial HTTPS flaw: Encrypting only the login page leaves earlier steps on HTTP, giving attackers a window to block the HTTPS upgrade entirely. -
Control priority: HTTPS everywhere, plus HSTS, to force secure transport and reduce downgrade attacks. -
Machine impact: Tokens and secrets can leak during device, agent, or API onboarding flows.
Why SSL Stripping Belongs in Identity Security
Identity security fails fast when authentication flows run over insecure transport. SSL stripping targets the exact moment identity data moves: sign-in, token exchange, session establishment, and redirects.
Even if attackers cannot break TLS, they do not need to; they only need to prevent the victim from using it. That makes SSL stripping a practical enabler of identity theft, not a niche networking trick.
SSL Stripping Explained
HTTPS protects confidentiality and integrity by encrypting traffic and authenticating the server using TLS. SSL stripping targets the HTTP-to-HTTPS transition and strips it, preventing the victim from reaching encrypted content.
In plain terms, the attacker convinces the victim to talk HTTP while the attacker talks HTTPS to the real site. The site appears secure, but the victim’s side is exposed.
How SSL Stripping Works
First, a user starts on HTTP or follows a link that triggers a redirect to HTTPS. The attacker intercepts the redirect and prevents the upgrade from completing.
Next, the attacker opens an HTTPS connection to the legitimate site and an HTTP connection to the victim, then relays traffic between them. The attacker can read what the victim sends and can also modify the content the victim receives.
Where SSL Stripping Happens
Public Wi-Fi is a classic attack vector because attackers can create lookalike hotspots and control traffic for connected users. Travel environments and shared networks increase exposure because users accept convenience over verification.
This is not only a Wi Fi problem. If an attacker gains a position on a network path, they can attempt to downgrade any environment that still has HTTP endpoints.
Signs of SSL Stripping
No single signal proves SSL stripping, but these indicators should trigger an investigation.
User visible signals
- A login or checkout page loads over http:// when you expect https://
- The padlock disappears during sign-in, or the browser shows a security warning
- The site behaves normally on trusted networks and oddly on public networks
SOC and web signals
- HTTP traffic appears for domains that should enforce HTTPS only
- Redirect patterns shift, or entry pages show abnormal 301 or 302 behavior
- Users report sign-in prompts that do not match known authentication flows
Identity-Focused Impact
SSL stripping can expose credentials, but the bigger risk is what happens next. Attackers can reuse credentials to access SaaS apps, internal portals, and administrative consoles.
If session handling is weak, attackers can also pivot from credential theft to session takeover. That is how a single downgrade event becomes an identity incident.
Machine Identity Security Impact
Machine identity security covers non-human identities such as workloads, services, APIs, agents, and devices. SSL stripping matters here because onboarding and operational workflows often move high-value secrets through browsers and portals.
A leaked token or key can outlive the user session and enable programmatic access at scale. That turns a single downgraded session into a persistent machine-credential problem.
Where Machine Secrets Leak
Use this as a quick mental checklist during onboarding, troubleshooting, and incident review.
- API portals: Admins copy API keys, bearer tokens, and client secrets from a web console into tools or scripts. If the console session runs on HTTP during a downgrade, attackers can capture those values.
- Agent enrollment: Set up flows that often issue one-time installers, enrollment codes, or registration tokens for endpoints and agents. If any step allows HTTP traffic, attackers can keep the connection unencrypted and steal whatever the admin downloads or pastes.
- CI token paste: Teams paste tokens and connection strings into CI variables during hurried fixes. If that work happens in a downgraded browser session, a single capture can become a long-lived machine credential.
- Device registration: Device provisioning portals may display certificates, bootstrap configs, or activation links. If redirect and link handling is loose, downgrade conditions can expose the material used to establish trust.
How to Prevent SSL Stripping
For Website Owners and Security Teams
The goal is to eliminate downgrade attack vectors and enforce secure transport by default.
HTTPS everywhere: Serve every page over HTTPS, not only authentication screens. If users can begin a journey on HTTP, attackers can try to keep them there.
HSTS enforcement: Use Strict Transport Security so browsers refuse to use HTTP for that domain on future connections. This is one of the most direct countermeasures to downgrade attempts. To close the first-visit gap where the browser has not yet seen the HSTS header, submit the domain to the browser HSTS preload list. Together, HSTS and preload are the most direct countermeasures to downgrade attempts.
Harden entry paths: Ensure internal links resolve to HTTPS and canonical URLs point to HTTPS. Keep redirects deterministic so you do not leave optional upgrade behavior that attackers can exploit.
Secure session handling: Mark session cookies as Secure and HttpOnly, then apply SameSite settings aligned to your authentication model. This does not replace HTTPS, but it reduces damage when users take risky paths.
For Machine Identity Workflows
Secure enrollment transport: Require HTTPS for all enrollment and bootstrap steps, including documentation links that direct users to setup pages. Treat setup as production authentication.
Short-lived issuance: Use short-lived enrollment tokens and rotate them aggressively so a single capture creates a narrow blast radius.
Proof of possession: Prefer credentials that require possession, such as client certificates or signed requests, so a copied string alone does not unlock access.
Mutual authentication: For service-to-service and workload communication, use mutual TLS (mTLS) to ensure both sides of a connection verify each other's identity. This removes reliance on bearer tokens that can be captured or replayed.
Workload identity standards: Frameworks like SPIFFE provide cryptographically attested identity to workloads without requiring static secrets to be generated, displayed, or copied. When workloads receive identity through platform-level attestation rather than human-mediated enrollment, the entire class of browser-based credential exposure is eliminated.
Certificate pinning (where supported): For mobile applications and API clients with controlled release cycles, certificate pinning adds a layer of protection by rejecting connections to servers presenting unexpected certificates. Note that pinning adds operational overhead during certificate rotation and has been deprecated in some browser contexts, so evaluate applicability based on your client ecosystem.
For employees and travelers
Treat unknown Wi-Fi as hostile. Use organization-provided secure access methods such as VPN or zero trust network access (ZTNA) before performing any authentication or administrative actions on untrusted networks.
Do not rely solely on visual browser indicators, as they can be spoofed or overlooked under pressure. If a login page loads on HTTP unexpectedly, disconnect and switch to a trusted network before re-authenticating.
SSL Stripping Prevention Checklist
Use this checklist for identity-critical web applications and machine onboarding portals.
- HTTPS default: Ensure every route serves HTTPS and immediately redirects HTTP to HTTPS.
- HSTS enabled: Set Strict-Transport-Security with a strong max-age, then includeSubDomains when appropriate.
- HSTS preload: Submit production domains to browser HSTS preload lists to close the first-visit vulnerability.
- No mixed links: Ensure all internal links, resources, and canonicals reference HTTPS.
- Cookie flags: Use Secure and HttpOnly flags, then set SameSite based on your sign-in flow.
- Redirect integrity: Validate redirect logic and remove optional upgrade behavior.
- Secret hygiene: Never display long-lived secrets by default, prefer one-time reveal with rotation.
- Mutual TLS for services: Require mTLS for machine-to-machine communication to eliminate the risk of bearer token replay.
- Enrollment limits: Use short-lived tokens for device, agent, and workload onboarding.
- Monitoring: Alert on HTTP requests to domains that should never serve HTTP.
- User guidance: Train users to stop when HTTPS disappears, especially on public networks.
SSL Stripping FAQs
SSL stripping is a specific in-the-middle method that downgrades a web session from HTTPS to HTTP. A general in-the-middle attack can intercept traffic in many ways, but SSL stripping targets the HTTPS upgrade step so the victim stays unencrypted while the attacker maintains HTTPS to the real site.
A victim starts on HTTP or follows a link that should redirect to HTTPS. The attacker intercepts the redirect, keeps the victim on HTTP, opens an HTTPS connection to the real site, and relays traffic between the two sides. Anything the victim sends over HTTP can be read or changed by the attacker.
A strong sign is seeing a login page load over http://rather than https://. A missing padlock or browser warning during sign-in also signals risk, especially on public networks. On the defense side, HTTP requests to domains that should enforce HTTPS and abnormal redirect patterns should trigger an investigation.
Serve HTTPS sitewide and enforce HSTS so browsers refuse HTTP for that domain. Remove mixed HTTP and HTTPS patterns and ensure links and redirects always resolve to HTTPS without requiring an optional upgrade step. Add secure session cookie settings to reduce downstream identity impact.
SSL stripping relies on the victim being able to start on HTTP or being kept on HTTP during an upgrade. If a site enforces HTTPS everywhere and uses HSTS correctly, it becomes much harder to keep victims on HTTP because browsers will insist on HTTPS for that domain.
