一、HTTP為什么不安全？

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

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

下面會(huì)逐條分析：

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

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

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

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

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

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

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

    
    
    無法驗(yàn)證報(bào)文的完整性01.png

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

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

二、HTTPS如何保證安全

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

另外，對(duì)于HTTP來說，服務(wù)器也好，客戶端也好，都是沒有辦法確認(rèn)通信方的。因?yàn)楹苡锌赡懿⒉皇呛驮绢A(yù)想的通信方在實(shí)際通信。并且還需要考慮到接收到的報(bào)文在通信途中已經(jīng)遭到篡改這一可能性。

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

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

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

1. HTTPS是身披SSL外殼的HTTP

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

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

2. 加密方法簡介

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

2.1. 對(duì)稱秘鑰加密

共享密鑰加密的困境 .png

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

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

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

對(duì)稱加密算法的優(yōu)、缺點(diǎn)：

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

• 缺點(diǎn)：

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

2.2. 非對(duì)稱密鑰加密

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

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

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

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

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

非對(duì)稱加密相比對(duì)稱加密更加安全，但也存在兩個(gè)明顯缺點(diǎn)：

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

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

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

2.3. 混合加密機(jī)制

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

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

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

2.4. SSL & TLS

HTTPS使用SSL（Secure Socket Layer）和TLS（Transport Layer Security）這兩個(gè)協(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為基準(zhǔn)，后又制定了TLS1.0、TLS1.1和TLS1.2。TSL是以SSL為原型開發(fā)的協(xié)議，有時(shí)會(huì)統(tǒng)一稱該協(xié)議為SSL。當(dāng)前主流的版本是SSL3.0和TLS1.0。由于SSL1.0協(xié)議在設(shè)計(jì)之初被發(fā)現(xiàn)出了問題，就沒有實(shí)際投入使用。SSL2.0也被發(fā)現(xiàn)存在問題，所以很多瀏覽器直接廢除了該協(xié)議版本。

SSL速度慢嗎？

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

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

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

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

2.4.1. 身份認(rèn)證

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

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

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

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

證書申請(qǐng)流程：

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

證書認(rèn)證流程：

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

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

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

需要注意的是：

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

可證明組織真實(shí)性的EV SSL證書

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

EV SSL證書標(biāo)識(shí).jpg

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

用以確認(rèn)客戶端身份的客戶端證書

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

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

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

客戶端證書存在的另一個(gè)問題點(diǎn)是，客戶端證書畢竟只能用來證明客戶端實(shí)際存在，而不能用來證明用戶本人的真實(shí)有效性。也就是說，只要獲得了安裝有客戶端證書的計(jì)算機(jī)的使用權(quán)限，也就意味著同時(shí)擁有了客戶端證書的使用權(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算法計(jì)算出消息的MAC值，并將其加在消息之后發(fā)送給接收者。接收者利用同樣的密鑰和MAC算法計(jì)算出消息的MAC值，并與接收到的MAC值比較。如果二者相同，則報(bào)文沒有改變；否則，報(bào)文在傳輸過程中被修改，接收者將丟棄該報(bào)文。

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

三、HTTPS的安全通信機(jī)制

HTTPS的安全通信機(jī)制01.png

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

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

1.隨機(jī)數(shù)

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

2.Session ID

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

3 密文族（Cipher Suites）：

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

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

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

步驟2： Server Hello

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

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

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

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

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

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

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

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

步驟3：Certificate

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

步驟4： Server Hello Done

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

步驟5: ClientKeyExchange

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

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

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

秘鑰交換

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

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

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

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

步驟6： ChangeCipherSpec

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

步驟7： Finished

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

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

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

步驟10：Application Data(HTTP)

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

步驟11： Application Data(HTTP)

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

步驟12： Close notify

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

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

HTTPS的安全通信機(jī)制02.png

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

四、為什么不一直使用HTTPS

其中一個(gè)原因是，因?yàn)榕c純文本通信相比，加密通信會(huì)消耗更多的CPU及內(nèi)存資源。如果每次通信都加密，會(huì)消耗相當(dāng)多的資源，平攤到一臺(tái)計(jì)算機(jī)上時(shí)，能夠處理的請(qǐng)求數(shù)量必定也會(huì)隨之減少。

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

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

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

資料參考：圖解HTTP