安全HTTP

HTTPS介紹

　　人們會用Web事務來處理一些很重要的事情。如果沒有強有力的安全保證，人們就無法安心地進行網絡購物或使用銀行業務。如果無法嚴格限制訪問權限，公司就不能將重要的文檔放在Web服務器上。Web需要一種安全的HTTP形式

　　前面的博客討論了一些提供認證(基本認證和摘要認證)和報文完整性檢査(摘要qop="auth-int")的輕量級方法。對很多網絡事務來說，這些方法都是很好用的，但對大規模的購物、銀行事務，或者對訪問機密數據來說，并不足夠強大。這些更為重要的事務需要將HTTP和數字加密技術結合起來使用，才能確保安全

　　HTTP的安全版本要高效、可移植且易于管理，不但能夠適應不斷變化的情況而且還應該能滿足社會和政府的各項要求。我們需要一種能夠提供下列功能的HTTP安全技術：服務器認證(客戶端知道它們是在與真正的而不是偽造的服務器通話)；客戶端認證(服務器知道它們是在與真正的而不是偽造的客戶端通話)；完整性(客戶端和服務器的數據不會被修改)；加密(客戶端和服務器的對話是私密的，無需擔心被竊聽)；效率(一個運行的足夠快的算法，以便低端的客戶端和服務器使用)；普適性(基本上所有的客戶端和服務器都支持這些協議)；管理的可擴展性(在任何地方的任何人都可以立即進行安全通信)；適應性(能夠支持當前最知名的安全方法)；在社會上的可行性(滿足社會的政治文化需要)

　　HTTPS是最流行的HTTP安全形式。它是由網景公司首創的，所有主要的瀏覽器和服務器都支持此協議。HTTPS方案的URL以https://，而不是http://開頭，據此就可以分辨某個Web頁面是通過HTTPS而不是HTTP訪問的

　　使用HTTPS時，所有的HTTP請求和響應數據在發送到網絡之前，都要進行加密。HTTPS在HTTP下面提供了一個傳輸級的密碼安全層—可以使用SSL，也可以使用其后繼者——傳輸層安全(Transport Layer Security，TLS)。由于SSL和TLS非常類似，所以一般地，不太嚴格地用術語SSL來表示SSL和TLS

　　大部分困難的編碼及解碼工作都是在SSL庫中完成的，所以Web客戶端和服務器在使用安全HTTP時無需過多地修改其協議處理邏輯。在大多數情況下，只需要用SSL的輸入/輸出調用取代TCP的調用，再增加其他幾個調用來配置和管理安全信息就行了

數字加密

　　在詳細探討HTTPS之前，先介紹一些SSL和HTTPS用到的加密編碼技術的背景知識。主要包括密碼——對文本進行編碼，使偷窺者無法識別的算法；密鑰——改變密碼行為的數字化參數；對稱密鑰加密系統——編/解碼使用相同密鑰的算法；不對稱密鑰加密系統——編/解碼使用不間密鑰的算法；公開密鑰加密系統——一種能夠使數百萬計算機便捷地發送機密報文的系統；數字簽名——用來驗證報文未被偽造或篡改的校驗和；數字證書——由一個可信的組織驗證和簽發的識別信息

　　密碼學是對報文進行編/解碼的機制與技巧。人們用加密的方式來發送秘密信息已經有數千年了。但密碼學所能做的還不僅僅是加密報文以防止好事者的讀取，我們還可以用它來防止對報文的篡改，甚至還可以用密碼學來證明某條報文或某個事務確實出自你手，就像支票的手寫簽名或信封上的壓紋封蠟一樣

【密碼】

　　密碼學基于一種名為密碼(cipher)的秘密代碼。密碼是一套編碼方案——一種特殊的報文編碼方式和一種稍后使用的相應解碼方式的結合體。加密之前的原始報文通常被稱為明文(plaintext或cleartext)。使用了密碼之后的編碼報文通常被稱作密文(ciphertext)

　　用密碼來生成保密信息已經有數千年了。傳說尤利烏斯凱撒(Julius Caesar)曾使用過一種三字符旋轉密碼，報文中的每個字符都由字母表中三個位置之后的字符來取代。在現代的字母表中，“A”就應該由“D”來取代，“B”就應該由“E”來取代，以此類推

　　用rot3(旋轉3字符)密碼將報文“meet me at the pier at midnight”編碼為密文“phhwphdwwkhslhudwplgqljkw”。通過解碼，在字母表中旋轉移位3個字符，可以將密文解密回原來的明文報文

　　最初，人們需要自己進行編碼和解碼，所以起初密碼是相當簡單的算法。因為密碼很簡單，所以人們通過紙筆和密碼書就可以進行編解碼了，但聰明人也可以相當容易地“破解”這些密碼

　　隨著技術的進步，人們開始制造一些機器，這些機器可以用復雜得多的密碼來快速、精確地對報文進行編解碼。這些密碼機不僅能做一些簡單的旋轉，它們還可以替換字符、改變字符順序，將報文切片切塊，使代碼的破解更加困難

　　編碼算法和編碼機都可能會落入壞人的手中，所以大部分機器上都有一些號盤，可以將其設置為大量不同的值以改變密碼的工作方式。即使機器被盜，沒有正確的號盤設置(密鑰值)，×××也無法工作

　　這些密碼參數被稱為密鑰(key)。要在密碼機中輸入正確的密鑰，解密過程才能正確進行。密碼密鑰會讓一個密碼機看起來好像是多個虛擬密碼機一樣，每個密碼機都有不同的密鑰值，因此其行為都會有所不同

　　下圖顯示了使用密鑰的密碼實例。加密算法就是普通的“循環移位N字符”密碼。N的值由密鑰控制。將同一條輸入報文“meet me at the pier at midnight”通過同一臺編碼機進行傳輸，會隨密鑰值的不同產生不同的輸出。現在，基本上所有的加密算法都會使用密鑰

【數字密碼】

　　隨著數字計算的出現，出現了以下兩個主要的進展：從機械設備的速度和功能限制中解放出來，使復雜的編/解碼算法成為可能；支持超大密鑰成為可能，這樣就可以從一個加密算法中產生出數萬億的虛擬加密算法，由不同的密鑰值來區分不同的算法。密鑰越長，編碼組合就越多，通過隨機猜測密鑰來破解代碼就越困難

　　與金屬鑰匙或機械設備中的號盤設置相比，數字密鑰只是一些數字。這些數字密鑰值是編/解碼算法的輸入。編碼算法就是一些函數，這些函數會讀取一塊數據，并根據算法和密鑰值對其進行編/解碼

　　給定一段明文報文P、一個編碼函數E和一個數字編碼密鑰e，就可以生成一段經過編碼的密文C。通過解碼函數D和解碼密鑰d，可以將密文C解碼為原始的明文P。當然，編/解碼函數都是互為反函數的，對P的編碼進行解碼就會回到原始報文P上去

對稱密鑰

　　很多數字加密算法都被稱為對稱密鑰(symmetric-key)加密技術，這是因為它們在編碼時使用的密鑰值和解碼時一樣(e=d)。我們就將其統稱為密鑰k

　　在對稱密鑰加密技術中，發送端和接收端要共享相同的密鑰k才能進行通信。發送端用共享的密鑰來加密報文，并將得到的密文發送給接收端。接收端收到密文，并對其應用解密函數和相同的共享密鑰，恢復出原始的明文

　　流行的對稱密鑰加密算法包括：DES、Triple-DES、RC2和RC4

　　保持密鑰的機密狀態是很重要的。在很多情況下，編/解碼算法都是眾所周知的，因此密鑰就是唯一保密的東西了

　　好的加密算法會迫使***者試遍每一個可能的密鑰，才能破解代碼。用暴力去嘗試所有的密鑰值稱為枚舉***(emmieration attack)。如果只有幾種可能的密鑰值，居心不良的人通過暴力遍歷所有值，就能最終破解代碼了。但如果有大量可能的密鑰值，他可能就要花費數天、數年，甚至無限長的時間來遍歷所有的密鑰，去査找能夠破解密碼的那一個

　　可用密鑰值的數量取決于密鑰中的位數，以及可能的密鑰中有多少是有效的。就對稱密鑰加密技術來說，通常所有的密鑰值都是有效的。8位的密鑰只有256個可能的密鑰值，40位的密鑰可以有2的40次個可能的密鑰值(大約是一萬億個密鑰)

　　在傳統的對稱密鑰加密技術中，對小型的、不太重要的事務來說，40位的密鑰就足夠安全了。但現在的高速工作站就可以將其破解，這些工作站每秒可以進行數十億次計算

　　相比之下，對于對稱密鑰加密技術，128位的密鑰被認為是非常強大的。實際上，長密鑰對密碼安全有著非常重要的影響，美國政府甚至對使用長密鑰的加密軟件實施了出口控制，以防止潛在的敵對組織創建出美國國家安全局(National Security Agency, NSA)自己都無法破解的秘密代碼

　　對稱密鑰加密技術的缺點之一就是發送者和接收者在互相對話之前，一定要有一個共享的保密密鑰

　　如果想要與Joe進行保密的對話，可能是在看了公共電視臺的家裝節目之后，想要訂構一些木工工具，那么在安全地訂購任何東西之前，要先在你和www.joes-hardware.com之間建立一個私有的保密密鑰。你需要一種產生保密密鑰并將其記住的方式。你和Joe的五金商店，以及因特網上所有其他人，都要產生并記住數千個密鑰

　　比如Alice(A)、Bob(B)和Chris(C)都想與Joe的五金商店(J)對話。A、B和C都要建立自己與J之間的保密密鑰。A可能需要密鑰Ka，B可能需要密鑰Kb，C可能需要密鑰Kc。每對通信實體都需要自己的私有密鑰。如果有N個節點，每個節點都要和其他所有個節點進行安全對話，總共大概會有N*N個保密密鑰：這將是一個管理噩夢

公開密鑰

　　公開密鑰加密技術沒有為每對主機使用單獨的加密/解密密鑰，而是使用了兩個非對稱密鑰：一個用來對主機報文編碼，另一個用來對主機報文解碼。編碼密鑰是眾所周知的(這也是公開密鑰加密這個名字的由來)，但只有主機才知道私有的解密密鑰。這樣，每個人都能找到某個特定主機的公開密鑰，密鑰的建立變得更加簡單。但解碼密鑰是保密的，因此只有接收端才能對發送給它的報文進行解碼

　　[注意]大部分公開密鑰査找工作實際上都是通過數字證書來實現

　　下圖中，節點X可以將其加密密鑰ex公之于眾。現在，任何想向節點X發送報文的人都可以使用相同的公開密鑰了，因為每臺主機都分配了一個所有人均可使用的編碼密鑰，所以公開密鑰加密技術避免了對稱密鑰加密技術中成對密鑰數目的N*N擴展問題

　　盡管每個人都可以用同一個密鑰對發給X的報文進行編碼，但除了X，其他人都無法對報文進行解碼，因為只有X才有解碼的私有密鑰dx。將密鑰分隔開來可以讓所有人都能夠對報文進行編碼，但只有其所有者才能對報文進行解碼。這樣，各節點向服務器安全地發送報文就更加容易，因為它們只要査找到服務器的公開密鑰就行了

　　通過公開密鑰加密技術，全球所有的計算機用戶就都可以使用安全協議了。制定標準化的公開密鑰技術包是非常重要的，因此，大規模的公開密鑰架構(Public-Key Infrastructure, PKI)標準創建工作已經開展許多年了

【RSA】

　　所有公開密鑰非對稱加密系統所面臨的共同挑戰是，要確保即便有人擁有了下面所有的線索，也無法計算出保密的私有密鑰：公開密鑰(是公有的，所有人都可以獲得)；一小片攔截下來的密文(可通過對網絡的嗅探獲取)；一條報文及與之相關的密文(對任意一段文本運行加密器就可以得到)

　　RSA算法就是一個滿足了所有這些條件的流行的公開密鑰加密系統，它是在MIT發明的，后來由RSA數據安全公司將其商業化。即使有了公共密鑰、任意一段明文、用公共密鑰對明文編碼之后得到的相關密文、RSA算法自身，甚至RSA實現的源代碼，破解代碼找到相應的私有密鑰的難度仍相當于對一個極大的數進行質因數分解的困難程度，這種計算被認為是所有計算機科學中最難的問題之一。因此，如果發現了一種能夠快速地將一個極大的數字分解為質因數的方法，就不僅能夠***瑞士銀行的賬戶系統，而且還可以獲得圖靈獎了

　　RSA加密技術的細節中包括很多繁瑣的數學問題。你不需要擁有數論方面的博士學位，有大量的庫可以用來執行RSA算法

　　任何人只要知道了其公開密鑰，就可以向一臺公共服務器發送安全報文，所以非對稱的公開密鑰加密系統是很好用的。兩個節點無須為了進行安全的通信而先交換私有密鑰

　　但公開密鑰加密箅法的計算可能會很慢。實際上它混合使用了對稱和非對稱策略。比如，比較常見的做法是在兩節點間通過便捷的公開密鑰加密技術建立起安全通信，然后再用那條安全的通道產生并發送臨時的隨機對稱密鑰，通過更快的對稱加密技術對其余的數據進行加密

數字簽名

　　到目前為止，我們已經討論了各種使用對稱和非對稱密鑰加/解密保密報文的密鑰加密技術

　　除了加/解密報文之外，還可以用加密系統對報文進行簽名(sign)，以說明是誰編寫的報文，同時證明報文未被篡改過。這種技術被稱為數字簽名(digital signing)

　　數字簽名是附加在報文上的特殊加密校驗碼。使用數字簽名有以下兩個好處：1、簽名可以證明是作者編寫了這條報文。只有作者才會有最機密的私有密鑰，因此，只有作者才能計算出這些校驗和。校驗和就像來自作者的個人“簽名” 一樣；2、簽名可以防止報文被篡改。如果有惡意***者在報文傳輸過程中對其進行了修改，校驗和就不再匹配了。由于校驗和只有作者保密的私有密鑰才能產生，所以***者無法為篡改了的報文偽造出正確的校驗碼

　　數字簽名通常是用非對稱公開密鑰技術產生的。因為只有所有者才知道其私有密鑰，所以可以將作者私有密鑰當作一種“指紋”使用

　　下圖說明了節點A是如何向節點B發送一條報文，并對其進行簽名的

　　首先，節點A將變長報文提取為定長的摘要；然后，節點A對摘要應用了一個“簽名”函數，這個函數會將用戶的私有密鑰作為參數。因為只有用戶才知道私有密鑰，所以正確的簽名函數會說明簽名者就是其所有者；一旦計算出簽名，節點A就將其附加在報文的末尾，并將報文和簽名都發送給B；在接收端，如果節點B需要確定報文確實是節點A寫的，而且沒有被篡改過，節點B就可以對簽名進行檢査。節點B接收經私有密鑰擾碼的簽名，并應用了使用公開密鑰的反函數。如果拆包后的摘要與節點B自己的摘要版本不匹配，要么就是報文在傳輸過程中被篡改了，要么就是發送端沒有節點A的私有密鑰，也就是說它不是節點A

數字證書

　　數字證書被稱為因特網上的“ID卡”，它包含一組信息，所有這些信息都是由一個官方的“證書頒發機構”以數字方式簽發的。基本的數字證書中通常包含一些紙質ID中常見的內容，比如：對象的名稱(人、服務器、組織等)；過期時間；證書發布者(由誰為證書擔保)；來自證書發布者的數字簽名

　　數字證書通常還包括對象的公開密鑰，以及對象和所用簽名算法的描述性信息。任何人都可以創建一個數字證書，但并不是所有人都能夠獲得受人尊敬的簽發權，從而為證書信息擔保，并用其私有密鑰簽發證書。典型的證書結構如下圖所示

【X.509V3證書】

　　數字證書沒有單一的全球標準。就像不是所有印刷版ID卡都在同樣的位置包含了同樣的信息一樣，數字證書也有很多略有不同的形式。現在使用的大多數證書都以一種標準格式——X.509V3，來存儲它們的信息。X.509V3證書提供了一種標準的方式，將證書信息規范至一些可解析字段中。不同類型的證書有不同的字段值，但大部分都遵循X.509 v3結構。下表中介紹了X.509證書中的字段信息

　　基于X.509證書的簽名有好幾種，其中包括Web服務器證書、客戶端電子郵件證書、軟件代碼簽名證書和證書頒發機構證書

【認證】

　　通過HTTPS建立了一個安全Web事務之后，現代的瀏覽器都會自動獲取所連接服務器的數字證書。如果服務器沒有證書，安全連接就會失敗。服務器證書中包含很多字段，其中包括：Web站點的名稱和主機名；Web站點的公開密鑰；簽名頒發機構的名稱；來自簽名頒發機構的簽名

　　瀏覽器收到證書時會對簽名頒發機構進行檢査。如果這個機構是個很有權威的公共簽名機構，瀏覽器可能已經知道其公開密鑰了， 因為瀏覽器會預先安裝很多簽名頒發機構的證書。下圖中說明了如何通過其數字簽名來驗證證書的完整性

　　如果對簽名頒發機構一無所知，瀏覽器就無法確定是否應該信任這個簽名頒發機構，它通常會向用戶顯示一個對話框，看看他是否相信這個簽名發布者。簽名發布者可能是本地的IT部門或軟件廠商

HTTPS細節

　　HTTPS是最常見的HTTP安全版本。它得到了很廣泛的應用，所有主要的商業瀏覽器和服務器上都提供HTTPS。HTTPS將HTTP協議與一組強大的對稱、非對稱和基于證書的加密技術結合在一起，使得HTTPS不僅很安全，而且很靈活，很容易在處于無序狀態的、分散的全球互聯網上進行管理

　　HTTPS加速了因特網應用程序的成長，已經成為基于Web的電子商務快速成長的主要推動力。在廣域網中對分布式Web應用程序的安全管理方面，HTTPS也是非常重要的

　　HTTPS就是在安全的傳輸層上發送的HTTP。HTTPS沒有將未加密的HTTP報文發送給TCP，并通過世界范圍內的因特網進行傳輸，而是在將HTTP報文發送給TCP之前，先將其發送給了一個安全層，對其進行加密

　　HTTP安全層是通過SSL及其現代替代協議TLS來實現的。我們遵循常見的用法，用術語SSL來表示SSL或者TLS

　　安全HTTP是可選的。因此，對Web服務器發起請求時，我們需要有一種方式來告知Web服務器去執行HTTP的安全協議版本，這是在URL的方案中實現的。
通常情況下，非安全HTTP的URL方案前綴為http，如下所示：

http://www.joes-hardware.com/index.html

　　在安全HTTPS協議中，URL的方案前綴為https，如下所示：

https://cajun-shop.securesites.com/Merchant2/merchant.mv?Store_Code=AGCGS

　　請求一個客戶端(比如Web瀏覽器)對某Web資源執行某事務時，它會去檢査 URL的方案：如果URL的方案為http，客戶端就會打開一條到服務器端口80(默認情況下)的連接，并向其發送老的HTTP命令；如果URL的方案為https，客戶端就會打開一條到服務器端口443(默認情況下)的連接，然后與服務器“握手”，以二進制格式與服務器交換一些SSL安全參數，附上加密的HTTP命令

　　SSL是個二進制協議，與HTTP完全不同，其流量是承載在另一個端口上的(SSL通常是由端口443承載的)。如果SSL和HTTP流量都從端口80到達，大部分Web服務器會將二進制SSL流量理解為錯誤的HTTP并關閉連接。將安全服務進一步整合到HTTP層中去就無需使用多個目的端口了，在實際中這樣不會引發嚴重的問題

　　下面來詳細介紹下SSL是如何與安全服務器建立連接的

　　在未加密HTTP中，客戶端會打開一條到Web服務器端口80的TCP連接，發送一條請求報文，接收一條響應報文，關閉連接

　　由于SSL安全層的存在，HTTPS中這個過程會略微復雜一些。在HTTPS中，客戶端首先打開一條到Web服務器端口443(安全HTTP的默認端口)的連接。一且建立了TCP連接，客戶端和服務器就會初始化SSL層，對加密參數進行溝通，并交換密鑰。握手完成之后，SSL初始化就完成了，客戶端就可以將請求報文發送給安全層了。在將這些報文發送給TCP之前，要先對其進行加密

　　在發送已加密的HTTP報文之前，客戶端和服務器要進行一次SSL握手，在這個握手過程中，它們要完成以下工作：交換協議版本號；選擇一個兩端都了解的密碼；對兩端的身份進行認證；生成臨時的會話密鑰，以便加密信道

　　在通過網絡傳輸任何已加密的HTTP數據之前，SSL已經發送了一組握手數據來建立通信連接了

　　下圖是SSL握手的簡化版本。根據SSL的使用方式，握手過程可能會復雜一些，但總的思想就是這樣

【服務器證書】

　　SSL支持雙向認證，將服務器證書承載回客戶端，再將客戶端的證書回送給服務器。而現在，瀏覽時并不經常使用客戶端證書，大部分用戶甚至都沒有自己的客戶端證書。服務器可以要求使用客戶端證書，但實際中很少出現這種情況

　　另一方面，安全HTTPS事務總是要求使用服務器證書的。在一個Web服務器上執行安全事務，比如提交信用卡信息時，你總是希望是在與你所認為的那個組織對話。由知名權威機構簽發的服務器證書可以幫助你在發送信用卡或私人信息之前評估你對服務器的信任度

　　服務器證書是一個顯示了組織的名稱、地址、服務器DNS域名以及其他信息的X.509 v3派生證書。你和你所用的客戶端軟件可以檢査證書，以確保所有的信息都是可信的

　　SSL自身不要求用戶檢査Web服務器證書，但大部分現代瀏覽器都會對證書進行簡單的完整性檢査，并為用戶提供進行進一步徹査的手段。網景公司提出的一種Web服務器證書有效性算法是大部分瀏覽器有效性驗證技術的基礎。驗證步驟如下所述：

　　1、日期檢測

　　首先，瀏覽器檢査證書的起始日期和結束日期，以確保證書仍然有效。如果證書過期了，或者還未被激活，則證書有效性驗證失敗，瀏覽器顯示一條錯誤信息

　　2、簽名頒發者可信度檢測

　　每個證書都是由某些證書頒發機構(CA)簽發的，它們負責為服務器擔保。證書有不同的等級，每種證書都要求不同級別的背景驗證。比如，如果申請某個電子商務服務器證書，通常需要提供一個營業的合法證明

　　任何人都可以生成證書，但有些CA是非常著名的組織，它們通過非常清晰的流程來驗證證書申請人的身份及商業行為的合法性。因此，瀏覽器會附帶一個簽名頒發機構的受信列表。如果瀏覽器收到了某未知(可能是惡意的)頒發機構簽發的證書，那它通常會顯示一條警告信息。有些證書會攜帶到受信CA的有效簽名路徑，瀏覽器可能會選擇接受所有此類證書。換句話說，如果某受信CA為“Sam的簽名商店”簽發了一個證書，而Sam的簽名商店也簽發了一個站點證書，瀏覽器可能會將其作為從有效CA路徑導出的證書接受

　　3、簽名檢測

　　一旦判定簽名授權是可信的，瀏覽器就要對簽名使用簽名頒發機構的公開密鑰，并將其與校驗碼進行比較，以査看證書的完整性

　　4、站點身份檢測

　　為防止服務器復制其他人的證書，或攔截其他人的流量，大部分瀏覽器都會試著去驗證證書中的域名與它們所對話的服務器的域名是否匹配。服務器證書中通常都包含一個域名，但有些CA會為一組或一群服務器創建一些包含了服務器名稱列表或通配域名的證書。如果主機名與證書中的標識符不匹配，面向用戶的客戶端要么就去通知用戶，要么就以表示證書不正確的差錯報文來終止連接

　　SSL是個復雜的二進制協議。除非你是密碼專家，否則就不應該直接發送原始的SSL流量。幸運的是，借助一些商業或開源的庫，編寫SSL客戶端和服務器并不十分困難

　　OpenSSL是SSL和TLS最常見的開源實現。OpenSSL項目由一些志愿者合作開發，目標是開發一個強壯的、具有完備功能的商業級工具集，以實現SSL和TLS協議以及一個全功能的通用加密庫

【代理】

　　客戶端通常會用Web代理服務器代表它們來訪問Web服務器。比如，很多公司都會在公司網絡和公共因特網的安全邊界上放置一個代理。代理是防火墻路由器唯一允許進行HTTP流量交換的設備，它可能會進行病毒檢測或其他的內容控制工作

　　但只要客戶端開始用服務器的公開密鑰對發往服務器的數據進行加密，代理就再也不能讀取HTTP首部了，從而代理就無法知道應該將請求轉向何處了

　　為了使HTTPS與代理配合工作，要進行幾處修改以告知代理連接到何處。一種常用的技術就是HTTPS SSL隧道協議。使用HTTPS隧道協議，客戶端首先要告知代理，它想要連接的安全主機和端口。這是在開始加密之前，以明文形式告知的，所以代理可以理解這條信息

　　HTTP通過新的名為CONNECT的擴展方法來發送明文形式的端點信息。CONNECT方法會告訴代理，打開一條到所期望主機和端口號的連接。這項工作完成之后，直接在客戶端和服務器之間以隧道形式傳輸數據。CONNECT方法就是一條單行的文本命令，它提供了由冒號分隔的安全原始服務器的主機名和端口號。host:port后面跟著一個空格和HTTP版本字符串，再后面是CRLF。接下來是零個或多個HTTP請求首部行，后面跟著一個空行。空行之后，如果建立連接的握手過程成功完成，就可以開始傳輸SSL數據了

CONNECT home.netscape.com:443 HTTP/1.0 User-agent: Mozilla/1.IN<raw SSL-encrypted data would follow here...>

　　在請求中的空行之后，客戶端會等待來自代理的響應。代理會對請求進行評估，確保它是有效的，而且用戶有權請求這樣一條連接。如果一切正常，代理會建立一條到目標服務器的連接。如果成功，就向客戶端發送一條200 Connection Established響應

HTTP/1.0 200 Connection established
Proxy-agent: Netscape-Proxy/1.1