pretty bad proxy an overlooked adversary in browsers https deployments l.
Skip this Video
Loading SlideShow in 5 Seconds..
Pretty-Bad-Proxy: An Overlooked Adversary in Browsers’ HTTPS Deployments PowerPoint Presentation
Download Presentation
Pretty-Bad-Proxy: An Overlooked Adversary in Browsers’ HTTPS Deployments

Loading in 2 Seconds...

play fullscreen
1 / 22

Pretty-Bad-Proxy: An Overlooked Adversary in Browsers’ HTTPS Deployments - PowerPoint PPT Presentation

  • Uploaded on

Pretty-Bad-Proxy: An Overlooked Adversary in Browsers’ HTTPS Deployments . Shuo Chen † , Ziqing Mao † ‡ , Yi-Min Wang † , Ming Zhang † † Microsoft Research ‡ Purdue University May 20 th , 2009. HTTPS and Its Adversary Assumption.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Pretty-Bad-Proxy: An Overlooked Adversary in Browsers’ HTTPS Deployments' - benjamin

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
pretty bad proxy an overlooked adversary in browsers https deployments

Pretty-Bad-Proxy: An Overlooked Adversary in Browsers’ HTTPS Deployments

Shuo Chen†, Ziqing Mao† ‡, Yi-Min Wang†, Ming Zhang†

†Microsoft Research ‡Purdue University

May 20th, 2009

https and its adversary assumption
HTTPS and Its Adversary Assumption
  • HTTPS: end-to-end secure protocol for web traffic.
    • Adversary assumption: MITM (man-in-the-middle).

HTTPS server




SSL tunnel

  • Are today’s browser implementations consistent with this assumption?
our research
Our research
  • Key finding
    • A class of browser vulnerabilities (demo)  proxy can defeat end-to-end security promised by HTTPS
    • Vulnerabilities exist in all major browsers
  • Industry outreach
    • Technical work finished in summer 2007
    • Paper withheld until this conference
    • Worked with all vendors to address the issues
the pretty bad proxy pbp adversary
The Pretty-Bad-Proxy (PBP) adversary



HTTPS server

Rendering modules






SSL tunnel, encrypted

attacks in this talk
Attacks in this talk
  • Key issue: browsers load unencrypted content from proxy in the HTTPS context of the victim server
    • Attack 1: Proxy’s error response
    • Attack 2: Proxy’s redirection
    • Attack 3: HTTP-intended pages that are HTTPS loadable
    • Attack 4: Visual context (GUI behavior, no script)
attack 1 error response
Attack 1: error response
  • Proxy’s error page: e.g., 502-server-not-found, other 4xx/5xx response;
  • Script in error page runs in





<iframe src=


502:Server not found

attack 2 redirection 3xx
Attack 2: redirection (3xx)

<script src=“https://js.”> server


PBP server

HTTP 302: redirection


Script will run in the context of

attack 3 http intended but https loadable pages hpihsl pages
Attack 3: HTTP-Intended-But-HTTPS-Loadable Pages (HPIHSL pages)
  • Many websites provide both HTTP and HTTPS services
    • Sensitive pages, e.g. checkout  HTTPS only
    • Non-sensitive pages, e.g., merchandise  Intended for HTTP access
    • However, non-sensitive pages are often accessible through HTTPS as well!.
  • What’s wrong with HPIHSL pages?
    • They often import scripts through HTTP
    • The scripts will run in the HTTPS context.




HTTP scripts

attack 3 continued
Attack 3 continued
  • Browsers warn about HTTP resource in HTTPS contexts, don’t they?
  • The detection logic is only to determine the address bar’s appearance
    • Address bar only concerns top level page, so …
bypassing the detection logic attack 3 cont
Bypassing the detection logic (attack 3 cont.)
  • Using an HTTPS iframe in an HTTP top level page.

Top level: HTTP

Attack script to run in the HTTPS context

Hidden iframe: HTTPS for an HPIHSL page

how pervasive attack 3 cont
How pervasive? (attack 3 cont.)
  • Very easy to find HPIHSL pages that import scripts
  • The paper shows 12 websites having this problem.
    • These HTTPS domains are not trustworthy.
    • They cover a wide range
      • Online shopping sites
      • Banks, credit card companies
      • Open source projects management site
      • Top computer science departments
      • Even the home domain of a leading certificate authority
attack 4 visual context
Attack 4: Visual context
  • In attack 1, script in proxy’s error page runs in the HTTPS context. (all browsers)
  • This attack
    • No script, only static HTML
    • Due to GUI behavior
      • IE, Opera and Chrome display a certificate on the GUI as long as it is in the certificate cache.
attack 4 continued
Attack 4 continued
  • A perfect GUI spoofing attack
    • Fresh browser, single tab, address bar input

Schedule a one-second timer for refreshing the page.


<meta HTTP-EQUIV=“Refresh” CONTENT=“1; URL=”>


Before the timer is expired, cache a PayPal certificate

<img src=“” style=“display:none”>

a response page

Get a.jpg from the real server

the phishing page (5xx)

threat level 1 when the proxy is malicious
Threat level 1: when the proxy is malicious
  • Proxies are used in many environments
    • Corporate and university networks
    • Hospitals, hotels
    • Third-party free proxies
  • Due to PBP issues, security of HTTPS communication depends on proxy’s integrity
    • Is proxy infected by viruses, hijacked by attackers or configured by malicious insiders?
threat level 2 even without a compromised proxy
Threat level 2: even without a compromised proxy
  • All these attacks work as long as

(1) Attacker can sniff your machine at the link layer

      • For HTTPS, you need to assume this.

(2) The browser has its proxy capability ON

WPAD: Web Proxy Auto Discovery

PAC script: Proxy Auto Config script

Manual configuration

attack tests
Attack tests
  • Our test bed
    • Proxy required for web traffic to the Internet
    • WPAD (default), PAC-script-config or manual-config
    • Tested on Ethernet
    • Tested on open wireless network

GET /wpad.dat

GET /wpad.dat

return goodProxy_cfg

return PBP_cfg


vulnerability status more recent than the camera ready version
Vulnerability status (more recent than the camera-ready version)

Besides point fixes, how can we systematically prevent (or find) these bugs?

Future PBP issues

mitigations by securing the network
Mitigations by securing the network
  • Not a fundamental “solution”
    • HTTPS security should not depend on the network.
    • However, it is worthwhile to have mitigations
      • Some issues not patched
      • New issues found in the future
  • Mitigations
    • Wireless router: use WPA (WiFi Protected Access)
    • Corporate network: deploy IPSec on many types of servers
      • Not only web servers, but DNS, DHCP, PAC servers
    • Travelling employees: secure-VPN to your corporate networks
conclusions and future work

Rendering modules

Conclusions and Future Work


  • The PBP adversary
    • Targeting the rendering modules
    • Encrypted/unencrypted contents confused


  • Developers of rendering modules need to deal with MITM
    • HTTPS layer not masking MITM for rendering modules.
  • Beyond HTTPS
    • Other end-to-end protocols: Kerberos, IPSec, etc
    • E.g., HTTP over IPSec, using Kerberos authentication
      • What do you want to achieve if a proxy is in between?
potential misinterpretations
Potential misinterpretations
  • HTTPS is flawed.
  • We argue that many proxies are not secure enough to tunnel HTTPS.
  • We advocate link layer security.
  • In addition to browser issues, we also show issues in WPAD, etc.

OCCUR: Open Chronologist for

Currently Undisclosed Research

  • A free web service for timestamping research ideas
    • Why: some research contributions cannot be published immediately, e.g., due to responsible disclosure policy.
    • What: OCCUR gives your idea a timestamp from VeriSign
    • Details: search for “Microsoft OCCUR” or ask me offline