Pretty-Bad-Proxy: I. INTRODUCTION

論文地址：Pretty-Bad-Proxy

I. INTRODUCTION

HTTPS is an end-to-end cryptographic protocol for securing web traffic over insecure networks. Authenticity and confidentiality are the basic promises of HTTPS. When a client communicates with a web server using HTTPS, we expect that: i) no HTTPS payload data can be obtained by a malicious host on the network; ii) the server indeed bears the identity shown in the certificate; and iii) no malicious host in the network can impersonate an authenticated user to access the server. These properties should hold as long as the end systems, i.e. the browser and the server, are trusted.

HTTPS是一種在不安全的網絡上進行安全傳輸的端到端的安全協議。可靠性和保密性是HTTPS的基本承諾。當一個客戶端和一個web服務端使用HTTPS進行通訊，咱們期待：1.全部承載在HTTPS上的數據均不會被網絡上的惡意主機截獲 2. 服務端和證書中的身份匹配 3. 網絡上沒有惡意主機能夠仿冒認證用戶鏈接服務器。 只要終端系統（例如瀏覽器和服務器）可信任，這些屬性都應該保持。

In other words, the adversary model of HTTPS is simple and clear: the network is completely owned by the adversary, meaning that no network device on the network is assumed trustworthy. The protocol is rigorously designed, implemented and validated using this adversary model. If HTTPS is not robust against this adversary, it is broken by definition.

換句話說，HTTPS的對手模型就很清晰了：對手徹底擁有網絡，表示網絡上的全部設備都是不可信任的。這個協議是嚴格根據這種對手模型設計實現並通過驗證的。若是在針對這個對手的時候HTTPS不是健壯的，那麼它從定義上就被破壞了。

This paper is motivated by our curiosity about whether the same adversary that is carefully considered in the design of HTTPS is also rigorously examined when HTTPS is integrated into the browser. In particular, we focus on an adversary called 「Pretty-Bad-Proxy」 (PBP), which is a man-in-the-middle attacker that specifically targets the browser’s rendering modules above the HTTP/HTTPS layer in order to break the end-to-end security of HTTPS. Figure 1 illustrates this adversary: PBP can access the raw traffic of the browser (encrypted and unencrypted), but it is unable to decrypt the encrypted data on the network. Instead, the PBP’s strategy is to send malicious contents through the unencrypted channel into the rendering modules, attempting to access/forge sensitive data (which flow in the encrypted channel on the network) above the target cryptography of HTTPS.

這篇論文是因爲咱們好奇當HTTPS整合入瀏覽器的時候，這種在HTTPS協議設計時就被仔細考慮過的攻擊方式是否也被嚴格驗證過。特別的，咱們聚焦在一種被稱爲PBP的攻擊手段上，它是一種中間人攻擊方式，特別會把基於HTTP/HTTPS層上的瀏覽器渲染模塊做爲攻擊對象來破壞HTTPS的端到端安全性。圖1說明了這種攻擊手段：PBP能截取瀏覽器上的原始傳輸流（包括加密和未加密的）， 可是它不能在網絡上解密加密數據。相反，PBP的策略是經過不加密通道發送惡意內容到渲染模型，試圖接近/僞造在HTTPS上加密的敏感數據（在網絡加密通道中傳輸的）。

With a focused examination of the PBP adversary against various browser behaviors, we realize that PBP is indeed a threat to the effectiveness of HTTPS deployments. We have discovered a set of PBP-exploitable vulnerabilities in IE, Firefox, Opera, Chrome browsers and many websites. They are due to a number of subtle behaviors of the HTML engine, the scripting engine, the HTTP proxying, and the cookie management. By exploiting the vulnerabilities, a PBP can obtain the sensitive data from the HTTPS server. It can also certify malicious web pages and impersonate authenticated users to access the HTTPS server. Although all attacks fool the HTTP/HTTPS layer and above, the manifestations of the vulnerabilities are diversified: some require the scripting capability of the browser while others use static HTML contents entirely; some require the HTTP-proxy mechanism enabled in the browser while others do not need this requirement. The existence of the vulnerabilities clearly undermines the endto-end security guarantees of HTTPS. 

在對PBP針對普遍瀏覽器操做的攻擊進行集中檢查以後，咱們發現PBP對HTTPS的開發者的有效性確實是一個威脅。在IE，FireFox，Opera，Chrome瀏覽器和不少網站，咱們發現了一系列利用PBP的漏洞。它們歸咎於HTML引擎，腳本引擎，HTTP代理和cookie管理中的許多細微的操做。利用這些漏洞，一個PBP攻擊者能夠從HTTPS服務端獲取到敏感信息。它也能夠證實惡意網頁並假冒認證用戶鏈接HTTPS服務器。雖然全部的攻擊都只欺騙HTTP/HTTPS和以上層，但漏洞的表現形式是多樣的：一些須要瀏覽器的腳本能力，而另外一些則徹底只利用靜態HTML網頁內容；一些須要在瀏覽器裏設置HTTP代理可用，而另外一些則沒有這個需求。漏洞的存在很明顯破壞了HTTPS上端到端的安全可靠性。

People who are less familiar with HTTPS sometimes argue that the HTTPS security inherently depended on the trust on the proxy, and thus the assumption about a malicious proxy was inappropriate. This argument is conceptually incorrect since HTTPS’ goal is to achieve the end-to-end security. Also, we show that in practice the trust on the proxy is too brittle for HTTPS to depend on. We constructed two versions of attack programs to show two levels of threats: (1) the first level, which is already serious, is due to the wide use of proxies for web access. The integrity of proxies is generally difficult to ensure. For instance, malware and attackers may take over legitimate proxies in hotels and Internet cafes, because they are not well managed. Many free third-party open proxies are also essentially unaccountable, etc; (2) the second level, which is more severe, is due to the fact that browsers’ proxyconfiguration mechanisms and browsers’ communications with proxies are often unencrypted in many network environments. This makes a user vulnerable even when he/she is not knowingly connected to an untrusted proxy, as long as an attacker has the MAC layer access to the victim’s network. In our Ethernet and WiFi experiments, the attacker simply needs to connect to the same Ethernet local area network (LAN) or wireless access point (AP) to launch the attacks. The damages of such attacks are the same as those caused by physically taking over a legitimate proxy. With the PBP vulnerabilities in browsers, the end-to-end security guarantees promised by HTTPS are lost because users basically need to trust the network in order to trust HTTPS. 

不太熟悉HTTPS的人有時候會爭論HTTPS安全須要依賴於代理的可靠性，因此假設一個惡意代理是不合適的。這種爭論從概念上就是不許確的，由於HTTPS的目標就是達成端到端的安全性。另外，咱們能夠展現，在實際中HTTPS所依賴的對代理的信任實在是太脆弱了。咱們構建兩個版本的攻擊程序來展現兩種威脅的級別：1. 第一種是嚴重級別，歸咎於網絡鏈接中普遍使用的代理。代理的可靠性很可貴到確保。好比，惡意軟件和攻擊者可能利用酒店和網絡咖啡店裏可發的代理，由於他們並無被很好的管理。不少免費三方代理也從本質上是不可依賴的，諸如此類。2. 第二種是更嚴重的級別，歸咎於瀏覽器的代理配置機制以及瀏覽器使用代理的通訊機制在不少網絡環境下每每是不加密的。當一個用戶不知道本身鏈接到了一個不可信任的代理，只要一個攻擊者獲取了和受害者網絡MAC層的鏈接，這個用戶就很容易受到攻擊。在咱們的以太網和wifi實驗中，攻擊者只須要簡單的鏈接到同一個LAN域或者無線熱點就能夠發起攻擊。這種攻擊的危害和在物理上接管一臺合法代理形成的危害同樣。使用瀏覽器裏的PBP漏洞，HTTPS失去了所承諾的端到端安全保障，由於用戶基本上須要信任網絡才能信任HTTPS。

We have reported the discovered vulnerabilities to browser vendors. They have acknowledged the attack scenarios. The status of vendor responses is given later in the paper in Table III. Most of the vendors have patched or planned on patching their browsers.

咱們向瀏覽器供應商報告了已發現的漏洞。他們被知悉了攻擊場景。供應商的反應在本論文表三中給出（譯者注：根據不一樣的場景不一樣瀏覽器產商響應程度不同，在下文解釋了攻擊場景以後再詳細給出）。大部分供應商已經或者計劃給他們的瀏覽器打上補丁。

A note about this paper: This work was finished in July 2007, except for the paper writing and the vulnerability testing on the Google Chrome browser released in beta in Sept. 2008. The paper submission has been withheld until this conference. To present this work in a necessary context, we will describe how our effort is related to some of the efforts from other researchers in this time frame.

關於本論文的一個註解：這項工做基本完成於2007年七月，到2008年九月正式完成論文書寫和在chrome beta瀏覽器上的漏洞測試。論文一直保留到此次會議才提交。爲了以一種必要的形式呈現這份研究，咱們將描述在這個時間框架內咱們的努力是如何和其餘研究者的努力聯繫起來的。

The rest of the paper is organized as follows. Section II introduces the basic concepts about the browser security model and the HTTPS protocol. Section III and Section IV describe various PBP attacks. In section V, we demonstrate the feasibility of exploiting these vulnerabilities and study their security implications in real-world settings. Section VI discusses possible fixes and mitigations. Section VII covers related work and Section VIII concludes.

這份論文如下內容結構以下：第二部分介紹了瀏覽器安全模型和HTTPS協議的基本概念，第三部分和第四部分描述了多種PBP攻擊方式，第五部分咱們證實了利用這些漏洞的可能性並研究他們對真實世界設置的安全啓示。第六部分討論可能的修復或緩解方案。第七部分覆蓋了相關研究，第八部分結尾。