Full Report
Ron Auger sent an email to the [WASC Mail list] on some fine work presented recently by Microsoft Research. The paper (and accompanying PPT), titled [Pretty-Bad-Proxy: An Overlooked Adversary in Browsers’ HTTPS Deployments] is pretty cool and shows several techniques for a malicious inline proxy to sniff SSL sessions passing through the proxy. Its genuinely a bunch of cool findings and has been handled neatly (with the exception of some shocking clipart!).
Analysis Summary
# Research: Pretty-Bad-Proxy: An Overlooked Adversary in Browsers’ HTTPS Deployments
## Metadata
- Authors: [Credited to Microsoft Research, though specific authors are not fully listed in the source context.]
- Institution: Microsoft Research
- Publication: [Not explicitly named, likely a conference proceeding or technical report associated with Microsoft Research publications.]
- Date: [Prior to June 07, 2009 (when the summary email was posted)]
## Abstract
This research unveils a novel attack vector where a malicious inline proxy can successfully eavesdrop on HTTPS/SSL sessions intended to be securely transmitted through the proxy. The technique exploits specific browser handling of intermediary proxy responses, allowing the proxy to inject malicious content that executes within the security context of the targeted HTTPS site, effectively bypassing SSL protections for sensitive data captured via client-side scripting.
## Research Objective
The primary objective was to investigate overlooked vulnerabilities in how web browsers handle HTTPS connections (SSL/TLS) when traversing intermediary proxies, specifically focusing on techniques an inline proxy could employ to sniff or compromise these secure sessions.
## Methodology
### Approach
The approach involved demonstrating esoteric techniques by exploiting the browser's interpretation of error responses (specifically HTTP 502 codes) received from a proxy during the initial connection negotiation phase for an HTTPS site, and then leveraging cross-context execution to compromise the session. A more advanced variation explored removing the necessity for full proxy control by utilizing local network sniffing combined with a race condition against the valid proxy server.
### Dataset/Environment
The evaluation focused on the interaction between standard web browsers and a malicious inline proxy environment configured to intercept HTTPS connection setup signals.
### Tools & Technologies
The research relied on exploiting standard HTTP response codes (specifically 502) and injecting controlled, malicious JavaScript content into these intermediary responses.
## Key Findings
### Primary Results
1. **Exploiting Proxy Error Responses:** A malicious inline proxy can respond to a browser's connection request (via the `CONNECT` method for HTTPS) with an HTTP 502 error code. Crucially, the browser interprets content embedded within this error response (e.g., malicious JavaScript) within the security context ($\text{origin}$) of the originally requested secure site ($\text{https://mybank.com}$).
2. **Context Compromise via iFrame Injection:** The malicious proxy injects JavaScript that subsequently opens an `<iframe>` pointing to the legitimate HTTPS site. Since the injected script runs under the security context of the target site, the script loads in the browser with full access to the page's Document Object Model (DOM) and session data.
3. **Mitigation Evasion:** This technique bypasses the typical SSL/TLS protection because the decryption occurs securely end-to-end, but the compromise happens *client-side* after the browser has already established the secure tunnel and rendered the sensitive content.
### Supporting Evidence
The effectiveness of the approach was demonstrated through a scenario involving an attack against an imagined banking session (`https://mybank.com`), proving that the injected evil-JavaScript gains full access to that page’s context.
### Novel Contributions
The primary technical innovation lies in weaponizing the browser's semantic interpretation of intermediary proxy error responses (like 502) during the HTTPS setup phase to enforce the target site's security context onto injected, hostile content.
## Technical Details
The attack chain is meticulously orchestrated:
1. User initiates $\text{https://mybank.com}$.
2. Browser sends $\text{CONNECT}$ message to the evil proxy.
3. Evil proxy replies with an HTTP **502 Proxy Error**, critically embedding **evil-JavaScript** alongside the error body.
4. The browser renders the 502 response, but due to flawed contextual interpretation, executes the embedded JavaScript within the security realm of $\text{https://mybank.com}$.
5. The evil JavaScript then initiates a request (potentially via an `<iframe>`) to the intended $\text{https://mybank.com}$, where it runs fully authorized by the browser's session state, allowing data sniffing.
## Practical Implications
### For Security Practitioners
This research highlights that the assumed security boundary provided by HTTPS is fragile when traversing untrusted or malicious intermediaries, particularly in environments where proxies are mandated or widely used.
### For Defenders
Defenses require browser vendors to strictly enforce security contexts across all responses received during connection setup, ensuring that error messages from proxies do not grant privileged execution contexts matching the target URL.
### For Researchers
The findings prompt deeper investigation into the handling of security context propagation across network layers, especially concerning proxied and tunneled connections.
## Limitations
The direct exploitation described initially required full control over the malicious inline proxy. The paper reportedly addresses this by showing a variant relying on network snooping and a race condition against the legitimate proxy.
## Comparison to Prior Work
While previous attacks may have focused on Man-in-the-Middle (MITM) attacks leveraging SSL certificate manipulation, "Pretty-Bad-Proxy" offers a distinct method that subverts the application layer's security context enforcement *after* the TLS negotiation is theoretically secure, by abusing auxiliary proxy protocol responses.
## Future Work
The report suggests that given the success of this technique, further work is needed to identify and patch similar context-confusion vulnerabilities across different protocols or intermediary components of the web stack.
## References
- [Pretty-Bad-Proxy: An Overlooked Adversary in Browsers’ HTTPS Deployments] (Link provided in source context)
- [WASC Mail list archives] (Source of discussion referencing the paper)