一、HTTP為什么不安全？

HTTP協(xié)議沒有任何的加密以及身份驗證的機制，非常容易遭到竊聽、劫持、篡改等。不安全的原因主要包含以下三個方面：

• 1. 通信使用明文，內(nèi)容可能被竊聽。
• 2. 不驗證通信方的身份，因此有可能遭到偽裝。
• 3. 無法驗證報文的完整性，所以有可能被篡改。

下面會逐條分析：

1. 通信使用明文，內(nèi)容可能被竊聽。
   

   由于HTTP本身不具備加密的功能，所以也無法做到對通信整體進行加密，HTTP報文使用明文方式發(fā)送。
   通信使用明文.png

2. 不驗證通信方的身份，因此有可能遭到偽裝。
   HTTP協(xié)議的實現(xiàn)本身非常簡單，不論是誰發(fā)送過來的請求都會返回響應(yīng)，因此不確認通信方，會存在以下各種隱患：

   • a. 無法確定請求發(fā)送至目標的Web服務(wù)器是否是按真實意圖返回響應(yīng)的那臺服務(wù)器。有可能是已偽裝的Web服務(wù)器。
   • b. 無法確定響應(yīng)返回到的客戶端是否是按真實意圖接收響應(yīng)的那個客戶端。有可能是已偽裝的客戶端。
   • c. 無法確定正在通信的對方是否具備訪問權(quán)限。因為某些Web服務(wù)器上保存著重要的信息，只想發(fā)給特定用戶通信的權(quán)限。
   • d. 無法判定請求是來自何方、出自誰手。
     即使是無意義的請求也會照單全收。無法阻止海量請求下的DoS攻擊（Denial of Service，拒絕服務(wù)攻擊）。

3. 無法驗證報文的完整性，所以有可能被篡改。
   所謂完整性是指信息的準確度。若無法證明其完整性，通常也就意味著無法判斷信息是否準確。

• 接收到的內(nèi)容可能有誤
  • 由于HTTP協(xié)議無法證明通信的報文完整性，因此，在請求或響應(yīng)送出之后直到對方接收之前的這段時間內(nèi)，即使請求或響應(yīng)的內(nèi)容遭到篡改，也沒有辦法獲悉。

  • 換句話說，沒有任何辦法確認，發(fā)出的請求/響應(yīng)和接收到的請求/響應(yīng)是前后相同的。

    
    
    無法驗證報文的完整性01.png

• 中間人攻擊
  如“從某個Web網(wǎng)站上下載內(nèi)容，是無法確定客戶端下載的文件和服務(wù)器上存放的文件是否前后一致的。文件內(nèi)容在傳輸途中可能已經(jīng)被篡改為其他的內(nèi)容。即使內(nèi)容真的已改變，作為接收方的客戶端也是覺察不到的。

  
  
  無法驗證報文的完整性02.png
• 如果防止篡改
  雖然有使用HTTP協(xié)議確定報文完整性的方法，但事實上并不便捷、可靠。其中常用的MD5和SHA-1等散列值校驗的方法，以及用來確認文件的數(shù)字簽名方法。
  • 提供文件下載服務(wù)的Web網(wǎng)站也會提供相應(yīng)的以PGP（Pretty Good Privacy，完美隱私）創(chuàng)建的數(shù)字簽名及MD5算法生成的散列值。PGP是用來證明創(chuàng)建文件的數(shù)字簽名，MD5是由單向函數(shù)生成的散列值。不論使用哪一種方法，都需要操縱客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務(wù)器上的文件。瀏覽器無法自動幫用戶檢查。
  • 可惜的是，用這些方法也依然無法百分百保證確認結(jié)果正確。因為PGP和MD5本身被改寫的話，用戶是沒有辦法意識到的。

二、HTTPS如何保證安全

如果在HTTP協(xié)議通信過程中使用未經(jīng)加密的明文，比如在Web頁面中輸入信用卡號，如果這條通信線路遭到竊聽，那么信用卡號就暴露了。

另外，對于HTTP來說，服務(wù)器也好，客戶端也好，都是沒有辦法確認通信方的。因為很有可能并不是和原本預(yù)想的通信方在實際通信。并且還需要考慮到接收到的報文在通信途中已經(jīng)遭到篡改這一可能性。

為了統(tǒng)一解決上述這些問題，需要在HTTP上再加入加密處理和認證等機制。我們把添加了加密及認證機制的HTTP稱為HTTPS（HTTP Secure）。

經(jīng)常會在Web的登錄頁面和購物結(jié)算界面等使用HTTPS通信。使用HTTPS通信時，不再用http://，而是改用https://。另外，當瀏覽器訪問HTTPS通信有效的Web網(wǎng)站時，瀏覽器的地址欄內(nèi)會出現(xiàn)一個帶鎖的標記。對HTTPS的顯示方式會因瀏覽器的不同而有所改變。

在采用了SSL后，HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能。
SSL是獨立于HTTP的協(xié)議，所以不光是HTTP協(xié)議，其他運行在應(yīng)用層的SMTP和Telnet等協(xié)議均可配合SSL協(xié)議使用。可以說SLL事當今世界上應(yīng)用最為廣泛的網(wǎng)絡(luò)安全技術(shù)。

1. HTTPS是身披SSL外殼的HTTP

HTTPS并非是應(yīng)用層的一種新協(xié)議。只是HTTP通信接口部分用SSL 和TLS協(xié)議替代而已。通常，HTTP直接和TCP通信。當使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信。

想要講清楚為什么使用SSL協(xié)議，必須要了解一下加密演化進程，下面介紹一下如今使用比較廣泛的幾種加密方式。

2. 加密方法簡介

近代的加密方法中加密算法是公開的，而密鑰卻是保密的。通過這種方式得以保持加密方法的安全性。
加密和解密都會用到密鑰。沒有密鑰就無法對密碼解密，反過來說，任何人只要持有密鑰就能解密了。如果密鑰被攻擊者獲得，那加密也就失去了意義。

2.1. 對稱秘鑰加密

共享密鑰加密的困境 .png

以共享密鑰方式加密時必須將密鑰也發(fā)給對方?？删烤乖鯓硬拍馨踩剞D(zhuǎn)交？在互聯(lián)網(wǎng)上轉(zhuǎn)發(fā)密鑰時，如果通信被監(jiān)聽那么密鑰就可會落入攻擊者之手，同時也就失去了加密的意義。另外還得設(shè)法安全地保管接收到的密鑰。

對稱加密又分為兩種模式：流加密和分組加密。

• 流加密: 將消息作為位流對待，并且使用數(shù)學(xué)函數(shù)分別作用在每一個位上，使用流加密時，每加密一次，相同的明文位會轉(zhuǎn)換成不同的密文位。流加密使用了密鑰流生成器，它生成的位流與明文位進行異或，從而生成密文?，F(xiàn)在常用的就是RC4，不過RC4已經(jīng)不再安全，微軟也建議網(wǎng)絡(luò)盡量不要使用RC4流加密。
• 分組加密: 將消息劃分為若干位分組，這些分組隨后會通過數(shù)學(xué)函數(shù)進行處理，每次一個分組。假設(shè)需要加密發(fā)生給對端的消息，并且使用的是64位的分組密碼，此時如果消息長度為640位，就會被劃分成10個64位的分組，每個分組都用一系列數(shù)學(xué)公式公式進行處理，最后得到10個加密文本分組。然后，將這條密文消息發(fā)送給對端。對端必須擁有相同的分組密碼，以相反的順序?qū)?0個密文分組使用前面的算法解密，最終得到明文的消息。比較常用的分組加密算法有DES、3DES、AES。其中DES是比較老的加密算法，現(xiàn)在已經(jīng)被證明不安全。而3DES是一個過渡的加密算法，相當于在DES基礎(chǔ)上進行三重運算來提高安全性，但其本質(zhì)上還是和DES算法一致。而AES是DES算法的替代算法，是現(xiàn)在最安全的對稱加密算法之一。分組加密算法除了算法本身外還存在很多種不同的運算方式，比如ECB、CBC、CFB、OFB、CTR等，這些不同的模式可能只針對特定功能的環(huán)境中有效，所以要了解各種不同的模式以及每種模式的用途。

對稱加密算法的優(yōu)、缺點：

• 優(yōu)點：算法公開、計算量小、加密速度快、加密效率高。

• 缺點：

  • 1.交易雙方都使用同樣鑰匙，安全性得不到保證
  • 2.每對用戶每次使用對稱加密算法時，都需要使用其他人不知道的惟一鑰匙，這會使得發(fā)收信雙方所擁有的鑰匙數(shù)量呈幾何級數(shù)增長，密鑰管理成為用戶的負擔。
  • 3.能提供機密性，但是不能提供驗證和不可否認性。

2.2. 非對稱密鑰加密

非對稱密鑰加密有兩把秘鑰：一把叫做私有密鑰（private key），另一把叫做公開密鑰（public key），公鑰加密，私鑰解密。

在非對稱密鑰交換算法出現(xiàn)以前，對稱加密一個很大的問題就是不知道如何安全生成和保管密鑰。非對稱密鑰交換過程主要就是為了解決這個問題，使得對稱密鑰的生成和使用更加安全。

密鑰交換算法本身非常復(fù)雜，密鑰交換過程涉及到隨機數(shù)生成，模指數(shù)運算，空白補齊，加密，簽名等操作。

常見的密鑰交換算法有RSA，ECDHE，DH，DHE等算法。涉及到比較復(fù)雜的數(shù)學(xué)問題，下面就簡單介紹下最經(jīng)典的RSA算法。

• RSA：算法實現(xiàn)簡單，誕生于1977年，歷史悠久，經(jīng)過了長時間的破解測試，安全性高。缺點就是需要比較大的素數(shù)也就是質(zhì)數(shù)（目前常用的是2048位）來保證安全強度，很消耗CPU運算資源。RSA是目前唯一一個既能用于密鑰交換又能用于證書簽名的算法。RSA可以算是最經(jīng)典的非對稱加密算法了。

非對稱加密相比對稱加密更加安全，但也存在兩個明顯缺點：

• 1. CPU計算資源消耗非常大。一次完全TLS握手，密鑰交換時的非對稱解密計算量占整個握手過程的90%以上。而對稱加密的計算量只相當于非對稱加密的0.1%，如果應(yīng)用層數(shù)據(jù)也使用非對稱加解密，性能開銷太大，無法承受。
• 2. 非對稱加密算法對加密內(nèi)容的長度有限制，不能超過公鑰長度。比如現(xiàn)在常用的公鑰長度是2048位，意味著待加密內(nèi)容不能超過256個字節(jié)。

所以公鑰加密（極端消耗CPU資源）目前只能用來作密鑰交換或者內(nèi)容簽名，不適合用來做應(yīng)用層傳輸內(nèi)容的加解密。

另外，要想根據(jù)密文和公鑰，恢復(fù)到信息原文是異常困難的，因為解密過程就是在對離散對數(shù)進行求值，這并非輕而易舉就能辦到。退一步講，如果能對一個非常大的整數(shù)做到快速地因式分解，那么密碼破解還是存在希望的。但就目前的技術(shù)來看是不太現(xiàn)實的。

2.3. 混合加密機制

由于使用非對稱加密能夠保證安全，但是效率卻大大降低，所以為了改進這個問題，可以采用混合加密機制：“非對稱加密”與“對稱加密”混合使用。

既：使用非對稱密鑰傳輸“對稱密鑰”，后續(xù)安全獲得到“對稱密鑰”后，再使用“對稱密鑰”加密通信。

存在的問題：中間人攻擊。中間人劫持公鑰后，發(fā)送給對方偽造公鑰，對方用偽造公鑰進行加密傳輸，再次被攔截，用中間人用自己的私鑰進行解密，此刻中間人得到了“對稱加密密鑰”

2.4. SSL & TLS

HTTPS使用SSL（Secure Socket Layer）和TLS（Transport Layer Security）這兩個協(xié)議。SSL技術(shù)最初是由瀏覽器開發(fā)商網(wǎng)景通信公司率先倡導(dǎo)的，開發(fā)過SSL3.0之前的版本。目前主導(dǎo)權(quán)已轉(zhuǎn)移到IETF（Internet Engineering Task Force,Internet工程任務(wù)組）的手中。

IETF以SSL3.0為基準，后又制定了TLS1.0、TLS1.1和TLS1.2。TSL是以SSL為原型開發(fā)的協(xié)議，有時會統(tǒng)一稱該協(xié)議為SSL。當前主流的版本是SSL3.0和TLS1.0。由于SSL1.0協(xié)議在設(shè)計之初被發(fā)現(xiàn)出了問題，就沒有實際投入使用。SSL2.0也被發(fā)現(xiàn)存在問題，所以很多瀏覽器直接廢除了該協(xié)議版本。

SSL速度慢嗎？

SSL的慢分兩種。一種是指通信慢。另一種是指由于大量消耗CPU及內(nèi)存等資源，導(dǎo)致處理速度變慢。

和使用HTTP相比，網(wǎng)絡(luò)負載可能會變慢2到100倍。除去和TCP連接、發(fā)送HTTP請求·響應(yīng)以外，還必須進行SSL通信，因此整體上處理通信量不可避免會增加。

另一點是SSL必須進行加密處理。在服務(wù)器和客戶端都需要進行加密和解密的運算處理。因此從結(jié)果上講，比起HTTP會更多地消耗服務(wù)器和客戶端的硬件資源，導(dǎo)致負載增強。

針對速度變慢這一問題，并沒有根本性的解決方案，我們會使用SSL加速器這種（專用服務(wù)器）硬件來改善該問題。該硬件為SSL通信專用硬件，相對軟件來講，能夠提高數(shù)倍SSL的計算速度。僅在SSL處理時發(fā)揮SSL加速器的功效，以分擔負載。

2.4.1. 身份認證

HTTPS協(xié)議中身份認證的部分是由數(shù)字證書來完成的，證書由公鑰、證書主體和數(shù)字簽名等內(nèi)容組成。

在客戶端發(fā)起SSL請求后，服務(wù)端會將數(shù)字證書發(fā)給客戶端，客戶端會對證書進行驗證（驗證查看這張證書是否是偽造的，也就是公鑰是否是偽造的），并獲取公鑰。

數(shù)字證書有兩個作用：

• 1.身份授權(quán)：確保瀏覽器訪問的網(wǎng)站是經(jīng)過CA驗證的可信任的網(wǎng)站。
• 2.分發(fā)公鑰：每個數(shù)字證書都包含了注冊者生成的公鑰（驗證確保是合法的，非偽造的公鑰）。在SSL握手時會通過certificate消息傳輸給客戶端。

證書申請流程：

• 1.服務(wù)器的運營人員向數(shù)字證書認證機構(gòu)提出公鑰的申請（信息包括：域名唯一標識和非對稱秘鑰的公鑰等）。
• 2.RA（證書注冊及審核機構(gòu)）檢查實體的合法性。如果個人或者小網(wǎng)站，這一步不是必須的。
• 3.CA（證書簽發(fā)機構(gòu)）數(shù)字證書認證機構(gòu)在判明提出申請者的身份之后，會對已申請的公開密鑰做數(shù)字簽名，然后分配這個已簽名的公開密鑰，并將該公開密鑰放入公鑰證書后綁定在一起。
• 4.證書更新到repository（負責數(shù)字證書及CRL內(nèi)容存儲和分發(fā)），終端后續(xù)從repository更新證書，查詢證書狀態(tài)等。

證書認證流程：

• 1.服務(wù)器會將這份由數(shù)字證書認證機構(gòu)頒發(fā)的公鑰證書發(fā)送給客戶端，以進行公開密鑰加密方式通信。公鑰證書也可叫做數(shù)字證書或直接稱為證書。
• 2.接到證書的客戶端可使用數(shù)字證書認證機構(gòu)的公開密鑰，對那張證書上的數(shù)字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事：一，認證服務(wù)器的公開密鑰的是真實有效的數(shù)字證書認證機構(gòu)。二，服務(wù)器的公開密鑰是值得信賴的。
• 3.此處認證機關(guān)的公開密鑰必須安全地轉(zhuǎn)交給客戶端。使用通信方式時，如何安全轉(zhuǎn)交是一件很困難的事，因此，多數(shù)瀏覽器開發(fā)商發(fā)布版本時，會事先在內(nèi)部植入常用認證機關(guān)的公開密鑰。

數(shù)字簽名的制作和驗證過程如下：

• 數(shù)字簽名的簽發(fā)：首先是使用哈希函數(shù)對待簽名內(nèi)容進行安全哈希，生成消息摘要，然后使用CA自己的私鑰對消息摘要進行加密。
• 數(shù)字簽名的校驗：使用CA的公鑰解密簽名，然后使用相同的簽名函數(shù)對待簽名證書內(nèi)容進行簽名并和服務(wù)端數(shù)字簽名里的簽名內(nèi)容進行比較，如果相同就認為校驗成功。

需要注意的是：

• 1.數(shù)字簽名簽發(fā)和校驗使用的密鑰對是CA自己的公私密鑰，跟證書申請者提交的公鑰沒有關(guān)系。
• 2.數(shù)字簽名的簽發(fā)過程跟公鑰加密的過程剛好相反，即是用私鑰加密，公鑰解密。
• 3.現(xiàn)在大的CA都會有證書鏈，證書鏈的好處一是安全，保持根CA的私鑰離線使用。第二個好處是方便部署和撤銷，即如果證書出現(xiàn)問題，只需要撤銷相應(yīng)級別的證書，根證書依然安全。
• 4.根CA證書都是自簽名，即用自己的公鑰和私鑰完成了簽名的制作和驗證。而證書鏈上的證書簽名都是使用上一級證書的密鑰對完成簽名和驗證的。
• 5.怎樣獲取根CA和多級CA的密鑰對？它們是否可信？當然可信，因為這些廠商跟瀏覽器和操作系統(tǒng)都有合作，它們的公鑰都默認裝到了瀏覽器或者操作系統(tǒng)環(huán)境里。

可證明組織真實性的EV SSL證書

作用：用來證明作為通信一方的服務(wù)器是否規(guī)范，另外一個作用是可確認對方服務(wù)器背后運營的企業(yè)是否真實存在。擁有該特性的證書就是EV SSL證書（Extended Validation SSL Certificate）。
EV SSL證書是基于國際標準的認證指導(dǎo)方針頒發(fā)的證書。其嚴格規(guī)定了對運營組織是否真實的確認方針，因此，通過認證的Web網(wǎng)站能夠獲得更高的認可度。
持有EV SSL證書的Web網(wǎng)站的瀏覽器地址欄處有綠色的鎖頭標識，從視覺上就能一眼辨別出。

EV SSL證書標識.jpg

上述機制的愿意圖是為了防止用戶被釣魚攻擊，但就效果上來講，還要打一個問號。很多用戶可能不了解EV SSL證書相關(guān)的知識，因此也不會留意它。

用以確認客戶端身份的客戶端證書

HTTPS中還可以使用客戶端證書。以客戶端證書進行客戶端認證，證明服務(wù)器正在通信的對方始終是預(yù)料之內(nèi)的客戶端，其作用跟服務(wù)器證書如出一轍。

但客戶端證書仍存在幾處問題點。其中的一個問題點是證書的獲取及發(fā)布。
想獲取證書時，用戶得自行安裝客戶端證書。但由于客戶端證書是要付費購買的，且每張證書對應(yīng)到每位用戶也就意味著需支付和用戶數(shù)對等的費用。另外，要讓知識層次不同的用戶們自行安裝證書，這件事本身也充滿了各種挑戰(zhàn)。

現(xiàn)狀是，安全性極高的認證機構(gòu)可頒發(fā)客戶端證書但僅用于特殊用途的業(yè)務(wù)。比如那些可支撐客戶端證書支出費用的業(yè)務(wù)。
例如，銀行的網(wǎng)上銀行就采用了客戶端證書。在登錄網(wǎng)銀時不僅要求用戶確認輸入ID和密碼，還會要求用戶的客戶端證書，以確認用戶是否從特定的終端訪問網(wǎng)銀。

客戶端證書存在的另一個問題點是，客戶端證書畢竟只能用來證明客戶端實際存在，而不能用來證明用戶本人的真實有效性。也就是說，只要獲得了安裝有客戶端證書的計算機的使用權(quán)限，也就意味著同時擁有了客戶端證書的使用權(quán)限。

2.4.2.數(shù)據(jù)完整性

數(shù)據(jù)傳輸過程中的完整性使用MAC算法來保證。為了避免網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)被非法篡改，SSL利用基于MD5或SHA的MAC（Message Autahentication Code）算法來保證消息的完整性。

MAC（Message Autahentication Code）算法是在密鑰參與下的數(shù)據(jù)摘要算法，能將密鑰和任意長度的數(shù)據(jù)轉(zhuǎn)換為固定長度的數(shù)據(jù)。發(fā)送者在密鑰的參與下，利用MAC算法計算出消息的MAC值，并將其加在消息之后發(fā)送給接收者。接收者利用同樣的密鑰和MAC算法計算出消息的MAC值，并與接收到的MAC值比較。如果二者相同，則報文沒有改變；否則，報文在傳輸過程中被修改，接收者將丟棄該報文。

由于MD5在實際應(yīng)用中存在沖突的可能性比較大，所以盡量別采用MD5來驗證內(nèi)容一致性。SHA也不能使用SHA0和SHA1，中國山東大學(xué)的王小云教授在2005年就宣布破解了 SHA-1完整版算法。微軟和google都已經(jīng)宣布16年及17年之后不再支持sha1簽名證書。MAC算法涉及到很多復(fù)雜的數(shù)學(xué)問題，這里就不多講細節(jié)了。

三、HTTPS的安全通信機制

HTTPS的安全通信機制01.png

步驟1： 客戶端通過發(fā)送Client Hello報文開始SSL通信。

報文中包含：1.隨機數(shù)。2.sessionID。3.密文族。

1.隨機數(shù)

在客戶端問候中，有四個字節(jié)以Unix時間格式記錄了客戶端的協(xié)調(diào)世界時間（UTC）。協(xié)調(diào)世界時間是從1970年1月1日開始到當前時刻所經(jīng)歷的秒數(shù)。在這個例子中，0x2516b84b就是協(xié)調(diào)世界時間。在他后面有28字節(jié)的隨機數(shù)（ random_C ），在后面的過程中我們會用到這個隨機數(shù)。

2.Session ID

如果出于某種原因，對話中斷，就需要重新握手。為了避免重新握手而造成的訪問效率低下，這時候引入了session ID的概念， session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且服務(wù)器有這個編號的記錄，雙方就可以重新使用已有的"對話密鑰"，而不必重新生成一把。
session ID是目前所有瀏覽器都支持的方法，但是它的缺點在于session ID往往只保留在一臺服務(wù)器上。所以，如果客戶端的請求發(fā)到另一臺服務(wù)器，就無法恢復(fù)對話。session ticket就是為了解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支持。

3 密文族（Cipher Suites）：

RFC2246中建議了很多中組合，一般寫法是"密鑰交換算法-對稱加密算法-哈希算法，以“TLS_RSA_WITH_AES_256_CBC_SHA”為例：

• TLS為協(xié)議。
• RSA為密鑰交換的非對稱算法。
• AES_256_CBC是對稱加密算法（其中256是密鑰長度，CBC是分組方式）
• SHA是哈希的算法。
  瀏覽器支持的加密算法一般會比較多，而服務(wù)端會根據(jù)自身的業(yè)務(wù)情況選擇比較適合的加密組合發(fā)給客戶端。（比如綜合安全性以及速度、性能等因素）
• Server_name擴展：一般瀏覽器也支持 SNI（Server Name Indication）
  當我們?nèi)ピL問一個站點時，一定是先通過DNS解析出站點對應(yīng)的ip地址，通過ip地址來訪問站點，由于很多時候一個ip地址是給很多的站點公用，因此如果沒有server_name這個字段，server是無法給與客戶端相應(yīng)的數(shù)字證書的，Server_name擴展則允許服務(wù)器對瀏覽器的請求授予相對應(yīng)的證書。

還有一個很好的功能： SNI（Server Name Indication）。這個的功能比較好，為了解決一個服務(wù)器使用多個域名和證書的SSL/TLS擴展。一句話簡述它的工作原理就是，在連接到服務(wù)器建立SSL連接之前先發(fā)送要訪問站點的域名（Hostname），這樣服務(wù)器根據(jù)這個域名返回一個合適的CA證書。目前，大多數(shù)操作系統(tǒng)和瀏覽器都已經(jīng)很好地支持SNI擴展，OpenSSL 0.9.8已經(jīng)內(nèi)置這一功能，據(jù)說新版的nginx也支持SNI。）

步驟2： Server Hello

服務(wù)器可進行SSL通信時，會以Server Hello報文作為應(yīng)答。和客戶端一樣，在報文中包含回復(fù)三個數(shù)據(jù)包,包括 Server Hello， Certificate， Certificate Status。服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的。下面分別看一下：

隨機數(shù)、sessionID和加密族

1.我們得到了服務(wù)器的以Unix時間格式記錄的UTC和28字節(jié)的隨機數(shù) （random_S）。

2.Seesion ID，服務(wù)端對于session ID 一般會有三種選擇 ：

• a.恢復(fù)的session ID：我們之前在client hello里面已經(jīng)提到，如果client hello里面的session ID在服務(wù)端有緩存，服務(wù)端會嘗試恢復(fù)這個session；
• b.新的session ID：這里又分兩種情況。
  • 第一種是client hello里面的session ID是空值，此時服務(wù)端會給客戶端一個新的session ID。
  • 第二種是client hello里面的session ID此服務(wù)器并沒有找到對應(yīng)的緩存，此時也會回一個新的session ID給客戶端；
• c.NULL：服務(wù)端不希望此session被恢復(fù)，因此session ID為空。

3.我們記得在client hello里面，客戶端給出了21種加密族，而在我們所提供的21個加密族中，服務(wù)端挑選了“TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”

• a. TLS為協(xié)議，ECDHE-RSA為密鑰交換的算法；
• b. AES_128_GCM是對稱加密算法（其中128是密鑰長度，GCM是分組方式）；
• c.SHA256是哈希的算法。

這就意味著服務(wù)端會使用ECDHE-RSA算法進行密鑰交換，通過AES_128_GCM對稱加密算法來加密數(shù)據(jù)，利用SHA256哈希算法來確保數(shù)據(jù)完整性。

步驟3：Certificate

之后服務(wù)器發(fā)送Certificate報文。報文中包含公開密鑰證書。
在前面的https原理研究中，我們知道為了安全的將公鑰發(fā)給客戶端，服務(wù)端會把公鑰放入數(shù)字證書中并發(fā)給客戶端（數(shù)字證書可以自簽發(fā)，但是一般為了保證安全會有一個專門的CA機構(gòu)簽發(fā)），所以這個報文就是數(shù)字證書。

步驟4： Server Hello Done

最后服務(wù)器發(fā)送Server Hello Done報文通知客戶端，最初階段的SSL握手協(xié)商部分結(jié)束。

步驟5: ClientKeyExchange

客戶端驗證證書真?zhèn)涡?/h5>

客戶端驗證證書的合法性，如果驗證通過才會進行后續(xù)通信，否則根據(jù)錯誤情況不同做出提示和操作，合法性驗證包括如下：

• 證書鏈的可信性trusted certificate path，方法如前文所述；
• 證書是否吊銷revocation，有兩類方式離線CRL與在線OCSP，不同的客戶端行為會不同；
• 有效期expiry date，證書是否在有效時間范圍；
• 域名domain，核查證書域名是否與當前的訪問域名匹配，匹配規(guī)則后續(xù)分析；

秘鑰交換

這個過程非常復(fù)雜，大概總結(jié)一下：

• 1.首先，其利用非對稱加密實現(xiàn)身份認證和密鑰協(xié)商，利用非對稱加密，協(xié)商好加解密數(shù)據(jù)的對稱秘鑰（外加CA認證，防止中間人竊取對稱秘鑰）
• 2.然后，對稱加密算法采用協(xié)商的密鑰對數(shù)據(jù)加密，客戶端和服務(wù)器利用 對稱秘鑰 進行通信；
• 3.最后，基于散列函數(shù)驗證信息的完整性，確保通信數(shù)據(jù)不會被中間人惡意篡改。

此時客戶端已經(jīng)獲取全部的計算協(xié)商密鑰需要的信息：兩個明文隨機數(shù)random_C和random_S與自己計算產(chǎn)生的Pre-master（由客戶端和服務(wù)器的 pubkey生成的一串隨機數(shù)），計算得到協(xié)商對稱密鑰;
enc_key=Fuc(random_C, random_S, Pre-Master)

SSL第一次握手結(jié)束之后，客戶端以Client Key Exchange報文作為回應(yīng)。報文中包含通信加密中使用的一種被稱為Pre-master secret的隨機密碼串。該報文已用步驟3中的公開密鑰進行加密。

步驟6： ChangeCipherSpec

接著客戶端繼續(xù)發(fā)送Change Cipher Spec報文。該報文會提示服務(wù)器，在此報文之后的通信會采用Pre-master secret密鑰加密。

步驟7： Finished

客戶端發(fā)送Finished報文。該報文包含連接至今全部報文的整體校驗值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解密該報文作為判定標準。

步驟8： 服務(wù)器同樣發(fā)送Change Cipher Spec報文。

步驟9： 服務(wù)器同樣發(fā)送Finished報文。

步驟10：Application Data(HTTP)

服務(wù)器和客戶端的Finished報文交換完畢之后，SSL連接就算建立完成。當然，通信會受到SSL的保護。從此處開始進行應(yīng)用層協(xié)議的通信，即發(fā)送HTTP請求。

步驟11： Application Data(HTTP)

應(yīng)用層協(xié)議通信，即發(fā)送HTTP響應(yīng)。

步驟12： Close notify

最后由客戶端斷開連接。斷開連接時，發(fā)送close_notify報文。上圖做了一些省略，這步之后再發(fā)送TCP FIN報文來關(guān)閉與TCP的通信。

在以上流程中，應(yīng)用層發(fā)送數(shù)據(jù)時會附加一種叫做MAC（Message Autahentication Code）的報文摘要。MAC能夠查知報文是否遭到篡改，從而保護報文的完整性。
下面是對整個流程的圖解。圖中說明了從僅使用服務(wù)器端的公開密鑰證書（服務(wù)器證書）建立HTTPS通信的整個過程。

HTTPS的安全通信機制02.png

① CBC模式（Cipher Block Chaining）又名密碼分組鏈接模式。在此模式下，將前一個明文塊加密處理后和下一個明文塊做XOR運算，使之重疊，然后再對運算結(jié)果做加密處理。對第一個明文塊做加密時，要么使用前一段密文的最后一塊，要么利用外部生成的初始向量（initial vector,IV）。

四、為什么不一直使用HTTPS

其中一個原因是，因為與純文本通信相比，加密通信會消耗更多的CPU及內(nèi)存資源。如果每次通信都加密，會消耗相當多的資源，平攤到一臺計算機上時，能夠處理的請求數(shù)量必定也會隨之減少。

因此，如果是非敏感信息則使用HTTP通信，只有在包含個人信息等敏感數(shù)據(jù)時，才利用HTTPS加密通信。

特別是每當那些訪問量較多的Web網(wǎng)站在進行加密處理時，它們所承擔著的負載不容小覷。在進行加密處理時，并非對所有內(nèi)容都進行加密處理，而是僅在那些需要信息隱藏時才會加密，以節(jié)約資源。

除此之外，想要節(jié)約購買證書的開銷也是原因之一。
要進行HTTPS通信，證書是必不可少的。而使用的證書必須向認證機構(gòu)（CA）購買。證書價格可能會根據(jù)不同的認證機構(gòu)略有不同。
那些購買證書并不合算的服務(wù)以及一些個人網(wǎng)站，可能只會選擇采用HTTP的通信方式。

資料參考：圖解HTTP