TCP/IP基礎總結性學習（7）

確保 Web 安全的 HTTPS

• 在 HTTP 協議中有可能存在信息竊聽或身份假裝等安全問題。使用 HTTPS 通訊機制能夠有效地防止這些問題。

---

一. HTTP 的缺點

HTTP 主要有這些不足，例舉以下：

• 通訊使用明文（不加密），內容可能會被竊聽
• 不驗證通訊方的身份，所以有可能遭遇假裝
• 沒法證實報文的完整性，因此有可能已遭篡改

1. HTTP 的缺點:

通訊使用明文可能會被竊聽因爲 HTTP 自己不具有加密的功能，因此也沒法作到對通訊總體（使用 HTTP 協議通訊的請求和響應的內容）進行加密。即，HTTP 報文使用明文（指未通過加密的報文）方式發送。

• TCP/IP 是可能被竊聽的網絡

  若是要問爲何通訊時不加密是一個缺點，這是由於，按 TCP/IP 協議族的工做機制，通訊內容在全部的通訊線路上都有可能遭到窺視。所謂互聯網，是由能連通到全世界的網絡組成的。不管世界哪一個角落的服務器在和客戶端通訊時，在此通訊線路上的某些網絡設備、光纜、計算機等都不多是我的的私有物，因此不排除某個環節中會遭到惡意窺視行爲。即便已通過加密處理的通訊，也會被窺視到通訊內容，這點和未加密的通訊是相同的。只是說若是通訊通過加密，就有可能讓人沒法破解報文信息的含義，但加密處理後的報文信息自己仍是會被看到的。

圖：互聯網上的任何角落都存在通訊內容被竊聽的風險

竊聽相同段上的通訊並不是難事。只須要收集在互聯網上流動的數據包（幀）就好了。對於收集來的數據包的解析工做，可交給那些抓包（Packet Capture）或嗅探器（Sniffer）工具。 下面的圖片示例就是被普遍使用的抓包工具 Wireshark。它能夠獲取 HTTP 協議的請求和響應的內容，並對其進行解析。像使用 GET 方法發送請求、響應返回了 200 OK，查看 HTTP 響應報文的所有內容等一系列的事情均可以作到。

• 加密處理防止被竊聽
  在目前你們正在研究的如何防止竊聽保護信息的幾種對策中，最爲普及的就是加密技術。加密的對象能夠有這麼幾個。

通訊線路的加密
一種方式就是將通訊加密。HTTP 協議中沒有加密機制，但能夠經過和 SSL（Secure Socket Layer，安全套接層）或 TLS（Transport Layer Security，安全層傳輸協議）的組合使用， 加密 HTTP 的通訊內容。 用 SSL 創建安全通訊線路以後，就能夠在這條線路上進行 HTTP 通訊了。與 SSL 組合使用的 HTTP 被稱爲 HTTPS（HTTP Secure，超文本傳輸安全協議）或 HTTP over SSL。
內容的加密
還有一種將參與通訊的內容自己加密的方式。因爲 HTTP 協議中沒有加密機制，那麼就對 HTTP 協議傳輸的內容自己加密。即把 HTTP 報文裏所含的內容進行加密處理。在這種狀況下，客戶端須要對 HTTP 報文進行加密處理後再發送請求。

誠然，爲了作到有效的內容加密，前提是要求客戶端和服務器同時具有加密和解密機制。主要應用在 Web 服務中。有一點必須引發注意，因爲該方式不一樣於 SSL 或 TLS 將整個通訊線路加密 處理，因此內容仍有被篡改的風險。

2.不驗證通訊方的身份就可能遭遇假裝

HTTP 協議中的請求和響應不會對通訊方進行確認。也就是說存在「服務器是否就是發送請求中 URI 真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端」等相似問題。

• 任何人均可發起請求

在 HTTP 協議通訊時，因爲不存在確認通訊方的處理步驟，任何人均可以發起請求。另外，服務器只要接收到請求，無論對方是誰都會返回一個響應（但也僅限於發送端的 IP 地址和端口號沒 有被 Web 服務器設定限制訪問的前提下）。

HTTP 協議的實現自己很是簡單，不管是誰發送過來的請求都會返回響應，所以不確認通訊方，會存在如下各類隱患:

沒法肯定請求發送至目標的 Web 服務器是不是按真實意圖返回響應的那臺服務器。有多是已假裝的 Web 服務器。
沒法肯定響應返回到的客戶端是不是按真實意圖接收響應的那個客戶端。有多是已假裝的客戶端。
沒法肯定正在通訊的對方是否具有訪問權限。由於某些 Web 服務器上保存着重要的信息，只想發給特定用戶通訊的權限。
沒法斷定請求是來自何方、出自誰手。
即便是無心義的請求也會照單全收。沒法阻止海量請求下的 DoS 攻擊（Denial of Service，拒絕服務攻擊）。

• 查明對手的證書

雖然使用 HTTP 協議沒法肯定通訊方，但若是使用 SSL 則能夠。 SSL 不只提供加密處理，並且還使用了一種被稱爲證書的手段，可用於肯定方。
證書由值得信任的第三方機構頒發，用以證實服務器和客戶端是實際存在的。另外，僞造證書從技術角度來講是異常困難的一件事。因此只要可以確認通訊方（服務器或客戶端）持有的證書， 便可判斷通訊方的真實意圖。

經過使用證書，以證實通訊方就是意料中的服務器。這對使用者我的來說，也減小了我的信息泄露的危險性。另外，客戶端持有證書便可完成我的身份的確認，也可用於對 Web 網站的認證環節。

3.沒法證實報文完整性，可能已遭篡改

所謂完整性是指信息的準確度。若沒法證實其完整性，一般也就意味着沒法判斷信息是否準確。
接收到的內容可能有誤。因爲 HTTP 協議沒法證實通訊的報文完整性，所以，在請求或響應送出以後直到對方接收以前的這段時間內，即便請求或響應的內容遭到篡改，也沒有辦法獲悉。換句話說，沒有任何辦法確認，發出的請求 / 響應和接收到的請求 / 響應是先後相同的。

• 好比，從某個 Web 網站上下載內容，是沒法肯定客戶端下載的文件和服務器上存放的文件是否先後一致的。文件內容在傳輸途中可能已經被篡改成其餘的內容。即便內容真的已改變，做爲接 收方的客戶端也是覺察不到的。像這樣，請求或響應在傳輸途中，遭攻擊者攔截並篡改內容的攻 擊稱爲中間人攻擊（Man-in-the-Middle attack，MITM）。

4.如何防止篡改

• 雖然有使用 HTTP 協議肯定報文完整性的方法，但事實上並不便捷、可靠。其中經常使用的是 MD5 和 SHA-1 等散列值校驗的方法， 以及用來確認文件的數字簽名方法。
• 提供文件下載服務的 Web 網站也會提供相應的以 PGP（Pretty Good Privacy，完美隱私）建立的數字簽名及 MD5 算法生成的散列值。PGP 是用來證實建立文件的數字簽名，MD5 是由單向函數生成的散列值。不論使用哪種方法，都須要操縱客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務器上的文件。 瀏覽器沒法自動幫用戶檢查。惋惜的是，用這些方法也依然沒法百分百保證確認結果正確。由於 PGP 和 MD5 自己被改寫的話，用戶是沒有辦法意識到的。 爲了有效防止這些弊端，有必要使用 HTTPS。SSL 提供認證和加密處理及摘要功能。僅靠 HTTP 確保完整性是很是困難的，所以經過和其餘協議組合使用來實現這個目標。

---

二.HTTP+ 加密 + 認證 + 完整性保護 =HTTPS

1.HTTP 加上加密處理和認證以及完整性保護後便是 HTTPS

• 若是在 HTTP 協議通訊過程當中使用未經加密的明文，好比在 Web 頁面中輸入信用卡號，若是這條通訊線路遭到竊聽，那麼信用卡號就暴露了。另外，對於 HTTP 來講，服務器也好，客戶端也好，都是沒有辦法確認通訊方的。由於頗有可能並非和本來預想的通訊方在實際通訊。 而且還須要考慮到接收到的報文在通訊途中已經遭到篡改這一可能性。爲了統一解決上述這些問題，須要在 HTTP 上再加入加密處理和認證等機制。咱們把添加了加密及認證機制的 HTTP 稱爲 HTTPS（HTTP Secure）。

• 常常會在 Web 的登陸頁面和購物結算界面等使用 HTTPS 通訊。使用 HTTPS 通訊時，再也不用 http://，而是改用 https://。另外，當瀏覽器訪問 HTTPS 通訊有效的 Web 網站時，瀏覽器的地址欄內會出現一個帶鎖的標記。對 HTTPS 的顯示方式會因瀏覽器的不一樣而有所改變。

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 是當今世界上應用最爲普遍的網絡安全技術。

3.相互交換密鑰的公開密鑰加密技術

• 在對 SSL 進行講解以前，咱們先來了解一下加密方法。SSL 採用一種叫作公開密鑰加密（Public-key cryptography）的加密處理方式。近代的加密方法中加密算法是公開的，而密鑰倒是保密的。經過這種方式得以保持加密方法的安全性。加密和解密都會用到密鑰。沒有密鑰就沒法對密碼解密，反過來講，任何人只要持有密鑰就能解密了。若是密鑰被攻擊者得到，那加密也就失去了意義。

共享密鑰加密的困境
加密和解密同用一個密鑰的方式稱爲共享密鑰加密（Common key crypto system），也被叫作對稱密鑰加密。

以共享密鑰方式加密時必須將密鑰也發給對方。可究竟怎樣才能安全地轉交？在互聯網上轉發密鑰時，若是通訊被監聽那麼密鑰就可會落入攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰。

使用兩把密鑰的公開密鑰加密
公開密鑰加密方式很好地解決了共享密鑰加密的困難。公開密鑰加密使用一對非對稱的密鑰。一把叫作私有密鑰 （private key），另外一把叫作公開密鑰（public key）。顧名思義，私有密鑰不能讓其餘任何人知道，而公開密鑰則能夠隨意發佈，任何人均可以得到。使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息後，再使用本身的私有密鑰進行解密。利用這種方式，不須要發送用來解密的私有密鑰，也沒必要擔憂密鑰被攻擊者竊聽而盜走。另外，要想根據密文和公開密鑰，恢復到信息原文是異常困難 的，由於解密過程就是在對離散對數進行求值，這並不是垂手可得就能辦到。退一步講，若是能對一個很是大的整數作到快速地因式分解，那麼密碼破解仍是存在但願的。但就目前的技術來看是不太現實的。

HTTPS 採用混合加密機制
HTTPS 採用共享密鑰加密和公開密鑰加密二者並用的混合加密機制。若密鑰可以實現安全交換，那麼有可能會考慮僅使用公開密鑰加密來通訊。可是公開密鑰加密與共享密鑰加密相比，其處理速度要慢。因此應充分利用二者各自的優點，將多種方法組合起來用於通訊。在交換密鑰環節使用公開密鑰加密方式，以後的創建通訊交換報文階段則使用共享密鑰加密方式。

4.證實公開密鑰正確性的證書

• 遺憾的是，公開密鑰加密方式仍是存在一些問題的。那就是沒法證實公開密鑰自己就是貨真價實的公開密鑰。好比，正準備和某臺服務器創建公開密鑰加密方式下的通訊時，如何證實收到的公開密鑰就是本來預想的那臺服務器發行的公開密鑰。或許在公開密鑰傳輸途中，真正的公開密鑰已經被攻擊者替換掉了。爲了解決上述問題，可使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書。
• 數字證書認證機構處於客戶端與服務器雙方均可信賴的第三方機構的立場上。威瑞信（VeriSign）就是其中一家很是有名的數字證書認證機構。咱們來介紹一下數字證書認證機構的業務流程。首先，服務器的運營人員向數字證書認證機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份以後，會對已申請的公開密鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一塊兒。服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端，以進行公開密鑰加密方式通訊。公鑰證書也可叫作數字證書或直接稱爲證書。接到證書的客戶端可以使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證經過，客戶端即可明確兩件事： 一，認證服務器的公開密鑰的是真實有效的數字證書認證機構。二，服務器的公開密鑰是值得信賴的。此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通訊方式時，如何安全轉交是一件很困難的事，所以，多數瀏覽器開發商發佈版本時，會事先在內部植入經常使用認證機關的公開密鑰。

可證實組織真實性的 EV SSL 證書
證書的一個做用是用來證實做爲通訊一方的服務器是否規範，另一個做用是可確認對方服務器背後運營的企業是否真實存在。擁有該特性的證書就是 EV SSL 證書（Extended Validation SSL Certificate）。 EV SSL 證書是基於國際標準的認證指導方針頒發的證書。其嚴格規定了對運營組織是否真實的確認方針，所以，經過認證的 Web 網站可以得到更高的承認度。 持有 EV SSL 證書的 Web 網站的瀏覽器地址欄處的背景色是綠色的，從視覺上就能一眼辨別出。並且在地址欄的左側顯示了 SSL 證書中記錄的組織名稱以及頒發證書的認證機構的名稱。上述機制的原意圖是爲了防止用戶被釣魚攻擊（Phishing），但就效果上來說，還得打一個問號。不少用戶可能不瞭解 EV SSL 證書相關的知識，所以也不太會留意它。
用以確認客戶端的客戶端證書
HTTPS 中還可使用客戶端證書。以客戶端證書進行客戶端認證，證實服務器正在通訊的對方始終是預料以內的客戶端，其做用跟服務器證書一模一樣。但客戶端證書仍存在幾處問題點。其中的一個問題點是證書的獲取及發佈。想獲取證書時，用戶得自行安裝客戶端證書。但因爲客戶端證書是要付費購買的，且每張證書對應到每位用戶也就意味着需支付和用戶數對等的費用。另外，要讓知識層次不一樣的用戶們自行安 裝證書，這件事自己也充滿了各類挑戰。現狀是，安全性極高的認證機構可頒發客戶端證書但僅用於特殊用途的業務。好比那些可支撐客戶端證書支出費用的業務。例如，銀行的網上銀行就採用了客戶端證書。在登陸網銀時不只要求用戶確認輸入 ID 和密碼，還會要求用戶的客戶端證書，以確認用戶是否從特定的終端訪問網銀。客戶端證書存在的另外一個問題點是，客戶端證書畢竟只能用來證實客戶端實際存在，而不能用來證實用戶本人的真實有效性。也就是說，只要得到了安裝有客戶端證書的計算機的使用權限，也就意味着同時擁有了客戶端證書的使用權限。
認證機構信譽第一
SSL 機制中介入認證機構之因此可行，是由於創建在其信用絕對可靠這一大前提下的。然而，2011 年 7 月，荷蘭的一家名叫 DigiNotar 的認證機構曾遭黑客不法入侵，頒佈了 google.com 和 twitter.com 等網站的僞造證書事件。這一事件從根本上撼動了 SSL 的可信度。由於僞造證書上有正規認證機構的數字簽名，因此瀏覽器會斷定該證書是正當的。當僞造的證書被用作服務器假裝之時，用戶根本沒法察覺到。雖然存在可將證書無效化的證書吊銷列表（Certificate Revocation List，CRL）機制，以及從客戶端刪除根證書頒發機構（Root Certificate Authority，RCA）的對策，可是距離生效還須要一段時間，而在這段時間內，到底會有多少用戶的利益蒙受損失就不得而知了。
由自認證機構頒發的證書稱爲自簽名證書
若是使用 OpenSSL 這套開源程序，每一個人均可以構建一套屬於本身的認證機構，從而本身給本身頒發服務器證書。但該服務器證書在互聯網上不可做爲證書使用，彷佛沒什麼幫助。獨立構建的認證機構叫作自認證機構，由自認證機構頒發的「無用」證書也被戲稱爲自簽名證書。瀏覽器訪問該服務器時，會顯示「沒法確認鏈接安全性」或「該網站的安全證書存在問題」等警告消息。由自認證機構頒發的服務器證書之因此不起做用，是由於它沒法消除假裝的可能性。自認證機構可以產生的做用頂多也就是本身對外宣稱「我是○○」的這種程度。即便採用自簽名證書，經過 SSL 加密以後，可能偶爾還會看見通訊處在安全狀態的提示，可那也是有問題的。由於 就算加密通訊，也不能排除正在和已通過僞 裝的假服務器保持通訊。值得信賴的第三方機構介入認證，才能讓已植入在瀏覽器內的認證機構頒佈的公開密鑰發揮做用，並藉此證實服務器的真實性。中級認證機構的證書可能會變成自認證證書。多數瀏覽器內預先已植入備受信賴的認證機構的證書，但也有一小部分瀏覽器會植入中級認證機構的證書。對於中級認證機構頒發的服務器證書，某些瀏覽器會以正規的證書來對待，可有的瀏覽器會看成自簽名證書。

5.HTTPS 的安全通訊機制

HTTPS 的通訊步驟:

步驟 1： 客戶端經過發送 Client Hello 報文開始 SSL 通訊。報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
步驟 2： 服務器可進行 SSL 通訊時，會以 Server Hello 報文做爲應答。和客戶端同樣，在報文中包含 SSL 版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
步驟 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 和 TLS
HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport Layer Security）這兩個協議。 SSL 技術最初是由瀏覽器開發商網景通訊公司率先倡導的，開發過 SSL3.0 以前的版本。目前主導權已轉移到 IETF（Internet Engineering Task Force，Internet 工程任務組）的手中。 IETF 以 SSL3.0 爲基準，後又制定了 TLS1.0、TLS1.1 和 TLS1.2。TSL 是以 SSL 爲原型開發的協議，有時會統一稱該協議爲 SSL。當前主流的版本是 SSL3.0 和 TLS1.0。 因爲 SSL1.0 協議在設計之初被發現出了問題，就沒有實際投入 使用。SSL2.0 也被發現存在問題，因此不少瀏覽器直接廢除了該協議版本。

• 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 網站在進行加密處理時，它們所承擔着的負載不容小覷。在進行加密處理時，並不是對全部內容都進行加密處理，而是僅在那些須要信息隱藏時纔會加密，以節約資源。除此以外，想要節約購買證書的開銷也是緣由之一。要進行 HTTPS 通訊，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。證書價格可能會根據不一樣的認證機構略有不一樣。一般，一年的受權須要數萬日元（如今一萬日元大約摺合 600 人民幣）。那些購買證書並不合算的服務以及一些我的網站，可能只會選擇採用 HTTP 的通訊方式。

如下是往日學習總結，有須要的盆友能夠去看看噢~~
TCP/IP基礎總結性學習（1）：瞭解web和網絡基礎
https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（2）：簡單的HTTP協議
https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（3）：HTTP 報文內的 HTTP 信息
https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（4）：返回結果的 HTTP 狀態碼
https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（5）：與 HTTP 協做的 Web 服務器
https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（6）：與 HTTP 協做的 Web 服務器
https://segmentfault.com/a/11...
前端實習面試試題總結：
https://segmentfault.com/a/11...