1 IEEE Symposium on Security and Privacy, May 2009 Shuo Chen, Ziqing Mao, Yi-Min Wang, Ming Zhang Microsoft Research Purdue University May 20 th, 2009

1IEEE Symposium on Security and Privacy, May 2009IEEE Symposium on Security and Privacy, May 2009

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

†Microsoft Research ‡Purdue University

May 20th, 2009

2IEEE Symposium on Security and Privacy, May 2009

HTTPS: end-to-end secure protocol for web traffic.

Adversary assumption: MITM (man-in-the-middle). browser HTTPS server

Internetproxy

SSL tunnel

Are today’s browser implementations consistent with this assumption?


Key findingA class of browser vulnerabilities (demo) proxy can defeat end-to-end security promised by HTTPS

Vulnerabilities exist in all major browsers

Industry outreachTechnical work finished in summer 2007Paper withheld until this conferenceWorked with all vendors to address the issues


TCP/IPTCP/IP

HTTP/HTTPS

Rendering modules

Browser PBP HTTPS server

Unencrypted

SSL tunnel, encrypted

HTTP/HTTPS


Key issue: browsers load unencrypted content from proxy in the HTTPS context of the victim server

Attack 1: Proxy’s error responseAttack 2: Proxy’s redirection Attack 3: HTTP-intended pages that are HTTPS loadableAttack 4: Visual context (GUI behavior, no script)


<iframe src=“https://bank.com”>

Proxy’s error page: e.g., 502-server-not-found, other 4xx/5xx response;

Script in error page runs in https://bank.com.

browser PBPBankserver

https://bank.com

502:Server not foundhttps://bank.com


browser PBP

bank.com server

https://bank.com

evil.com server

<script src=“https://js. bank.com/foo.js”>

https://js.bank.com

HTTP 302: redirection to https://evil.com

https://evil.com

Script will run in the context of https://bank.com


sensitive

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.

Non-sensitive

HTTP scripts

HPIH

SL


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 …


Hidden iframe:

HTTPS for an HPIHSL page

http://resources.jcpenny.com/

foo.jsAttack script to run in the HTTPS

context

Top level: HTTP

Using an HTTPS iframe in an HTTP top level page.


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


In attack 1, script in proxy’s error page runs in the HTTPS context. (all browsers)

This attackNo script, only static HTMLDue to GUI behavior

IE, Opera and Chrome display a certificate on the GUI as long as it is in the certificate cache.


Schedule a one-second timer for refreshing the page.<head><meta HTTP-EQUIV=“Refresh” CONTENT=“1; URL=https://www.paypal.com”></head>

Before the timer is expired, cache a PayPal certificate <img src=“https://www.paypal.com/a.jpg” style=“display:none”>

a response page

Get a.jpg from the real

serverthe phishing page (5xx)

A perfect GUI spoofing attackFresh browser, single tab, address bar input



Proxies are used in many environmentsCorporate 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?


All these attacks work as long as(1) Attacker can sniff your machine at the link

layerFor HTTPS, you need to assume this.

(2) The browser has its proxy capability ONWPAD: Web Proxy Auto Discovery

PAC script: Proxy Auto Config script

Manual configuration


GET /wpad.dat

return PBP_cfg

GET /wpad.dat

return goodProxy_cfg

attacker

Our test bedProxy required for web traffic to the Internet

WPAD (default), PAC-script-config or manual-config

Tested on Ethernet

Tested on open wireless network


IE 8 (since beta 2)

Firefox 3.0.10

Safari 3.2.2 (or before)

Opera sinceDec. 2007

Chrome1.0.154.53

Error-response issue

Fixed Fixed Fixed Fixed Fixed

Redirection issue

N/A Fixed Fixed Fixed N/A

HPIHSL issue fix suggested for next version

Fix proposed Acknowledged Acknowledged

Acknowledged

Cached certificate issue

Fixed N/A N/A Fixed Fixed

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


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

MitigationsWireless 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


The PBP adversaryTargeting the rendering modules

Encrypted/unencrypted contents confused

TCP/IP

HTTP/HTTPS

Rendering modules

Developers of rendering modules need to deal with MITM

HTTPS layer not masking MITM for rendering modules.

Beyond HTTPSOther end-to-end protocols: Kerberos, IPSec, etc

E.g., HTTP over IPSec, using Kerberos authenticationWhat do you want to achieve if a proxy is in between?


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.


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 VeriSignDetails: search for “Microsoft OCCUR” or ask me offline

http://research.microsoft.com/en-us/projects/occur/

Documents

1 IEEE Symposium on Security and Privacy, May 2009 Shuo Chen, Ziqing Mao, Yi-Min Wang, Ming Zhang Microsoft Research Purdue University May 20 th, 2009