在 HTTP 協定中有可能存在資訊竊聽或身份僞裝等安全問題。使用 HTTPS 通信機制可以有效的防止這些問題。本章我們就了解一下 HTTPS 。
7.1、HTTP 的缺點
到現在為止，我們已了解到 HTTP 具有相當優秀和友善的一面，然而 HTTP 并非隻有好的一面，事物皆具有兩面性，它也是有很多不足之處的。
HTTP 主要有這些不足，舉例如下。
這些問題不僅在 HTTP 上出現，其他未加密的協定中也會存在這類問題。
除此之外，HTTP 本身還有很多缺點。而且，還有像某些特定的 Web 伺服器和特定的 Web 浏覽器在實際應用中存在的不足（也可以說成是脆弱性或安全漏洞），另外，用 Java 和 PHP 等程式設計語言開發的 Web 應用也可能存在安全漏洞。
7.1.1、通信使用明文可能會被竊聽
由于 HTTP 本身不具備加密的功能，是以也無法做到對通信整體（使用 HTTP 協定通信的請求和響應的内容）進行加密。即，HTTP 封包使用明文（指未經過加密的封包）方式發送。
TCP/IP 是可能被竊聽的網絡
如果要問為什麼通信時不加密是一個缺點，這是因為，按 TCP/IP 協定族的工作機制，通信内容在所有的通信線路上都有可能遭到窺視。
所謂網際網路，是由能連通到全世界的網絡組成的。無論世界那個角落的伺服器在和用戶端通信時，在此通信線路上的某些網絡裝置、光纜、計算機等都不可能是個人的私有物，所有不排除某個環節中會遭到惡意窺視行為。
即使已經過加密處理的通信，也會被窺視到通信内容，這點和未加密的通信是相同的。隻是說如果通信經過加密，就有可能讓人無法破解封包資訊的含義，但加密處理後的封包資訊本身還是會被看到的。
竊聽相同段上的通信并非難事。隻需要收集在網際網路上流動的資料包（幀）就行了。對于收集的資料包的解析工作，可以交那些抓包（Packet Capture）或者嗅探器（Sniffer）工具。
加密處理防止被竊聽
在目前大家正在研究的如何防止竊聽保護資訊的幾種對策中，最為普及的就是加密技術。加密的對象可以有這麼幾個。
通信的加密
一種方式就是将通信加密。HTTP 協定中沒有加密機制，但可以通過和 SSL （Secure Socket Layer，安全套接層）或 TLS（Transport Layer Security，安全層傳輸協定）的組合使用，加密 HTTP 的通信内容。
用 SSL 建立安全通信線路之後，就可以在這條線路上進行 HTTP 通信了。與 SSL 組合使用的 HTTP 被稱為 HTTPS （HTTP Secure，超文本傳輸安全協定【注意：HTTP 是超文本傳輸協定】）或 HTTP over SSL。
内容的加密
還有一種将參與通信的内容本身加密的方式。由于 HTTP 協定中沒有加密機制，那麼就對 HTTP 協定傳輸的内容本身加密。即把 HTTP 封包裡含有的内容進行加密處理。
在這種情況下，用戶端需要對 HTTP 封包進行加密處理後再發送請求。
誠然，為了做到有效的内容加密，前提是要求用戶端和服務端同時具備加密和解密機制。主要應用在 Web 服務中。有一點必須引起注意，由于該方式不同于 SSL 或 TLS 将整個通信線路加密處理，是以内容仍有被篡改的風險。稍後我們會加以說明。
7.1.2、不驗證通信方的身份就可能遭遇僞裝
HTTP 協定中的請求不會對通信方進行确認。也就是說存在“伺服器是否就是發送請求中 URI 真正指定的主機，傳回的響應是否真的傳回到實際提出請求的用戶端”等類似問題。
任何人都可以發起請求
在 HTTP 協定通信時，由于不存在确認通信方的處理步驟，任何人都可以發起請求。另外，伺服器隻要接收到請求，不管對方是誰都會傳回一個響應（但也僅限于發送端的 IP 位址和端口号沒有被 Web 伺服器設定限制通路的前提下）。
HTTP 協定的實作本身非常簡單，不論是誰發送過來的請求都會傳回響應，是以不确認通信方，會存在以下各種隐患。
查明對手的證書
雖然使用 HTTP 協定無法确定通信方，但如果使用 SSL 則可以。SSL 不僅提供加密處理，而且還使用一種被稱為證書的手段，可用于确認方。
證書由值的信任的第三方機構頒發，用以證明伺服器和用戶端是實際存在的（防止黑客利用虛拟 IP）。另外，僞造證書從技術角度來說是異常困難的一件事。是以隻要能夠确認通信方（伺服器和用戶端）持有證書，即可判斷通信方的真實意圖。
通過使用證書，以證明通信方就是意料之中的伺服器。這對使用者個人來講，也減少了個人資訊洩露的危險性。
另外，用戶端持有證書即可完成個人身份的确認，也可用于對 Web 網站的認證環節。
7.1.3、無法證明封包完整性，可能已遭篡改
所謂完整性是指資訊的準确度。若無法證明其完整性，通常也就意味着無法判斷資訊是否準确。
接收到内容可能有誤
由于 HTTP 協定無法證明通信的封包完整性，是以，在請求或響應送出之後直到對方接收之前的這段時間内，即使請求或響應的内容遭到篡改，也沒有辦法獲悉。
換句話說，沒有任何辦法确認，發出的請求 / 響應和接收到的請求 / 響應是前後相同的。
比如，從某個 Web 網站上下載下傳内容，是無法确定用戶端下載下傳的檔案和伺服器上存放的檔案是否前後一緻的。檔案内容在傳輸途中可能已經被篡改為其他的内容。即使内容真的已經改變，作為接收方的用戶端也是察覺不到的。
像這樣，請求或響應在傳輸途中，遭攻擊者攔截并篡改内容的攻擊稱為中間人攻擊（Man-in-the-Middle attack，MITM）。
如何防止篡改
雖然有使用 HTTP 協定确定封包完整性的方法，但事實上并不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校驗的方法，以及用來确認檔案的數字簽名方法。
提供檔案下載下傳服務的 Web 網站也會提供相應的以 PGP（Pretty Good Privacy，完美隐私）建立的數字簽名及 MD5 算法生成的散列值。PGP 是用來證明建立檔案的數字簽名，MD5 是由單調函數生成的散列值。無論使用哪一種方法，都需要操縱用戶端的使用者本人親自檢查驗證下載下傳的檔案是否就是原來伺服器上的檔案。浏覽器無法自動幫使用者檢查。
可惜的是，用這些方法也依然無法百分百保證确認結果正确。因為 PGP 和 MD5 本身被改寫的話，使用者是沒辦法意識到的。
為了有效防止這些弊端，有必要使用 HTTPS。SSL 提供認證和加密處理及摘要功能。僅靠 HTTP 確定完整性是非常困難的，是以通過和其他協定組合使用來實作這個目标。
7.2、http + 加密 + 認證 + 完整性保護 = https
7.2.1、http 加上加密處理和認證以及完整性保護後即是 https
如果在 HTTP 協定通信過程中使用未加密的明文，比如在 Web 頁面中輸入信用卡号，如果這條通信線路遭到竊聽，那麼信用卡就暴露了。
另外，對于 HTTP 來說，伺服器也好，用戶端也好，都是沒有辦法确認通信方的。因為很有可能并不是和原來預想的通信方在實際通信。并且還需要考慮到接收到的封包在通信途中已經遭到篡改這一可能性。
為了統一解決上述這些問題，需要在 HTTP 上再加入加密處理和認證等機制。我們把添加了加密及認證機制的 HTTP 稱為 HTTPS （HTTP Secure）。
經常會在 Web 的登入頁面和購物結算等使用 HTTPS 通信。使用 HTTPS 通信時，不再用 http:// ，而是改用 https:// 。另外，當浏覽器通路 HTTPS 通信有效的 Web 網站時，浏覽器位址欄會出現一個帶鎖的标記。對 HTTPS 的顯示方式會因為浏覽器的不同而有所改變。
7.2.2、https 是身披 ssl 外殼的 http
HTTPS 并非是應用層的一種新協定。隻是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS （Transport Layer Security）協定代替而已。
通常，HTTP 直接和 TCP 通信。當使用 SSL 時，則演變成先和 SSL 通信，再由 SSL 和 TCP 通信了。簡而言之，所謂 HTTPS，其實就是身披 SSL 協定這層外殼的 HTTP。
在采用 SSL 後，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能。
SSL 是獨立于 HTTP 的協定，是以不光是 HTTP 協定，其他運作在應用層的 SMTP 和 Telnet 等協定均可配合 SSL 協定使用。可以說 SSL 是當今世界上應用最為廣泛的網絡安全技術。
7.2.3、互相交換密鑰的公開密鑰加密技術
在對 SSL 進行講解之前，我們先來了解一下加密方法。SSL 采用一種叫做公開密鑰加密（Public-key cryptography）的加密處理方式。
近代的加密方法中加密算法是公開的，而密鑰卻是保密的。通過這種方式得以保持加密方法的安全性。
加密和解密都會用到密鑰。沒有密鑰就無法對密碼解密，反過來說，任何人隻要持有密鑰就能解密了。如果密鑰被攻擊者獲得，那加密也就失去了意義。
共享密碼加密的困境
加密和解密同用一個密鑰的方式稱為共享密鑰加密（Common key crypto system）,也被叫做對稱密鑰加密。
以共享密鑰方式加密時必須将密鑰也發給對方。可究竟怎樣才能安全轉交？在網際網路上轉發密鑰時，如果通信被監聽那麼密鑰就可能會落入攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰。
使用兩把密鑰的公開密鑰加密
公開密鑰加密方式很好地解決了共享加密的困難。
公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰（private key），另一把叫做公開密鑰（public key）。顧名思義，私有密鑰不能讓任何人知道，而公開密鑰則可以随意釋出，任何人都可以獲得。
使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的資訊後，再使用自己私有密鑰進行解密。利用這種方式，不需要發送用來解密的私有密鑰，也不必擔心密鑰被攻擊者竊聽而盜走。
另外，要想根據密文和公開密鑰，恢複到資訊原文是異常困難的，因為解密過程就是在對離散對數進行求值，這并非輕而易舉就能辦到。退一步講，如果能對一個非常大的整數做到快速因式分解，那麼密碼破解還是存在希望的。但就目前的技術來看是不太現實的。
HTTPS 采用混合加密機制
HTTPS 采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機制。若密鑰能夠實作安全交換，那麼有可能會考慮僅使用公開密鑰加密來通信。但是公開密鑰加密與共享密鑰加密相比，其處理速度要慢。
是以應充分利用兩者各自的優勢，将多種方法組合起來用于通信。在交換密鑰環節使用公開密鑰加密方式，之後的建立通信交換封包階段則使用共享密鑰加密方式。
7.2.4、證明公開密鑰正确性的證書
遺憾的是，公開密鑰加密方式還是存在一些問題的。那就是無法證明公開密鑰本身就是貨真價實的公開密鑰。比如，正準備和某台伺服器建立公開密鑰加密方式下的通信時，如何證明收到的公開密鑰就是原本預想的那台伺服器發行的公開密鑰。或許在公開密鑰傳輸途中，真正的公開密鑰已經被攻擊者替換掉了。
在使用通信方式時，如何安全轉交是一件很困難的事，是以，多數浏覽器開發商釋出版本時，會事先在内植入常用認證機關的公開密鑰。
用以确認用戶端的用戶端證書
HTTPS 中還可以使用用戶端證書。以用戶端證書進行用戶端認證，證明伺服器正在通信的對方始終是預料之内的用戶端（因為存在攻擊者創造多個虛拟 IP 對伺服器進行海量請求，占用伺服器資源，造成伺服器 503 的情況），其作用跟伺服器證書如出一轍。
但用戶端證書仍存在幾處問題點。其中的一個問題點是證書擷取及釋出。想要擷取正式時，使用者得自行安裝用戶端證書。但由于用戶端證書是要付費購買的，且每張證書對應到每一位使用者也就意味着需支付和使用者數量對等的費用。另外，要讓知識層次不同的使用者自行安裝證書，這是件充滿挑戰的事。
現狀是，安全性極高的認證機構可頒發用戶端證書但僅用于特殊用途的業務。比如那些可支撐用戶端證書支出費用的業務。
例如，銀行的網上銀行就采用了用戶端證書。在登入網銀時，不僅要求使用者輸入 ID 和密碼，還會要求使用者的用戶端證書，以确認使用者是否從特定的終端通路網銀。
用戶端證書存在的另一個問題是，用戶端證書畢竟隻能用來證明用戶端真實存在，而不能用來證明使用者本人的真實有效性。也就是說，隻要獲得了安裝有用戶端證書的計算機的使用權限，也就意味着同時擁有了用戶端證書的使用權限。
7.2.5、https 的安全通信機制
為了更好地了解 HTTPS，我們來觀察一下 HTTPS 的通信步驟。
步驟1：
用戶端通過發送 Client Hello 封包開始 SSL 通信。封包中包含用戶端支援的 SSL 的指定版本、加密元件（Cipher Suite）清單（所使用的加密算法及密鑰長度等）。
步驟2：
服務端可進行 SSL 通信時，會以 Serve Hello 封包作為應答。和用戶端一樣，在封包的加密元件内容是從接收到的用戶端加密元件内篩選出來的。
步驟3：
之後伺服器發送 Certificate 封包。封包中包含公開密鑰證書。
步驟4：
最後伺服器發送 Server Hello Done 封包通知用戶端，最初階段的 SSL 握手協商部分結束。
步驟5：
SSL 第一次握手結束之後，用戶端以 Client Key Exchange 封包作為回應。封包中包含通信加密中使用的一種被稱為 Pre-master secret 的随機密碼串。該封包已用步驟3中的公開密鑰進行加密。
步驟6：
接着用戶端繼續發送 Change Cipher Spec 封包。該封包會提示伺服器，在此封包之後的通信會采用 Pre-master secret 密鑰加密。
步驟7：
用戶端發送 Finished 封包。該封包包含連接配接至今全部封包的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正确解密該封包作為判斷标準。
步驟8：
伺服器同樣發送 Change Cipher Spec 封包。
步驟9：
服務端同樣發送 Finished 封包。
步驟10：
伺服器和用戶端的 Finished 封包交換完畢之後，SSL 連接配接就算建立完成。當然，通信會受到 SSL 的保護。從此處開始進行應用層協定的通信，及發送 HTTP 請求。
步驟11：
應用層協定通信，即發送 HTTP 響應。
步驟12：
最後由用戶端斷開連接配接。斷開連接配接時，發送 close_notify 封包。上圖做了一些省略，這步之後再發送 TCP FIN 封包來關閉與 TCP 的通信。
在以上流程中，應用層發送資料時會附加一種叫做 MAC （message Authentication Code）的封包摘要。MAC 能夠查知封包是否遭到篡改，進而保護封包的完整性。
下面是對整個流程的圖解。圖中說明了僅從使用伺服器端的公開密鑰證書（伺服器證書）建立 HTTPS 通信的整個過程。
SSL 速度緩慢
HTTPS 也存在一些問題，那就是當使用 SSL 時，它的處理速度會變慢。
SSL 的慢兩分鐘。一種是指通信慢。另一種是指由于大量消耗 CPU 及記憶體等資源，導緻處理速度變慢。
和使用 HTTP 相比，網絡負載可能會變慢 2 到 100 倍。除去和 TCP 連接配接、發送 HTTP 請求（響應）之外，還必須進行 SSL 通信，是以整體上處理通信量不可避免會增加。
另外一點是 SSL 必須進行加密處理。在伺服器和用戶端都需要進行加密和解密的運算處理。是以從結果上講，比起 HTTP 會更多地消耗伺服器和用戶端的硬體資源，導緻負載增強。
針對速度變慢這一問題，并沒有根本性的解決方案，我們會使用 SSL 加速器這種（專用伺服器）硬體來改善該問題。該硬體為 SSL 通信專用硬體，相對軟體來講，能夠提高數倍 SSL 的計算速度。僅在 SSL 處理時發揮 SSL 加速器的功效，以分擔負載。
思考：為什麼不一直使用 HTTPS
既然 HTTPS 那麼安全可靠，那為何所有的 Web 網站不一直使用 HTTPS？
其中一個原因是，因為與純文字通信相比，加密通信會消耗更多的 CPU 及記憶體資源。如果每次通信都加密，會消耗相當多的資源，平攤到一台計算機上時，能夠處理的請求數量必定也會随之減少。
是以，如果是非敏感資訊則使用 HTTP 通信，隻有在包含個人資訊等敏感資料時，才利用 HTTPS 加密通信。
特别是當那些通路量較多的 Web 網站在進行加密處理時，它們所承受的負載不容小觑。在進行加密處理時，并非對所有的内容都進行加密處理，而是僅在那些需要資訊隐藏時才會加密，以節約資源。
除此之外，想要節約購買證書的開銷也是原因之一。