1. 什么是HTTP

超文本傳輸協(xié)議，是一個(gè)基于請(qǐng)求與響應(yīng)，無(wú)狀態(tài)的，應(yīng)用層的協(xié)議，常基于TCP/IP協(xié)議傳輸數(shù)據(jù)，互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議,所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)。設(shè)計(jì)HTTP的初衷是為了提供一種發(fā)布和接收HTML頁(yè)面的方法。
說(shuō)起HTTP請(qǐng)求，我們幾乎每天都在發(fā)出這樣的請(qǐng)求，例如我們?cè)跒g覽器中輸入http://www.baidu.com時(shí)，就是向百度的服務(wù)器發(fā)出一個(gè)http請(qǐng)求，而百度的服務(wù)器同時(shí)會(huì)給我們返回該請(qǐng)求的一個(gè)回應(yīng)。再例如，我們?cè)谝粋€(gè)登錄的場(chǎng)景下，輸入用戶名=“123”，密碼=“666666”，然后按下登錄按鈕，此時(shí)http請(qǐng)求中將攜帶著用戶名和密碼兩個(gè)信息提交到服務(wù)器，然后服務(wù)器從http請(qǐng)求的報(bào)文中提取到用戶名和密碼等信息。如下圖所示：

很明顯，http請(qǐng)求存在著一個(gè)很?chē)?yán)重的問(wèn)題，http協(xié)議傳輸?shù)氖敲魑模绻虚g有個(gè)黑客攔截到該請(qǐng)求，就攔截到了我們的數(shù)據(jù)，就能將我們的用戶名和密碼看得一清二楚，這樣隱私的數(shù)據(jù)就非常容易泄露出去

因此，我們很容易想到，我們可以對(duì)數(shù)據(jù)加密去解決該問(wèn)題呀！這就引出了我們今天的主題：HTTPS，于是，有了下圖的場(chǎng)景。

可以看出，黑客即使截取到了我們請(qǐng)求的數(shù)據(jù)，他看到也只是一串亂碼，根本不知道是啥子玩意，所以，HTTPS就是一種將數(shù)據(jù)加密后再傳輸?shù)膮f(xié)議。

2. HTTP和HTTPS的對(duì)比

從上圖可以看到，HTTP和HTTPS協(xié)議底層都是基于TCP的協(xié)議，只是HTTPS協(xié)議中間多了一層SSL或者TLS，因此，很簡(jiǎn)單，HTTPS就是HTTP協(xié)議加上SSL/TLS。TLS是SSL的升級(jí)版，它們的作用都是進(jìn)行加密的連接。

3. 對(duì)稱加密

特點(diǎn)：靠一個(gè)**來(lái)加密數(shù)據(jù)，使用相同的一個(gè)**來(lái)解密數(shù)據(jù)。首先用戶需要把自己的一把鑰匙給送給服務(wù)器，用戶用這把鑰匙加密數(shù)據(jù)，然后服務(wù)器待會(huì)拿這把相同的鑰匙去解密用戶接下來(lái)發(fā)送的數(shù)據(jù)。

那么，這樣的加密算法有什么不妥呢？首先，如果用戶擁有相同的**的話，我的**能解你的數(shù)據(jù)，你的**能解密我的數(shù)據(jù)，這樣，別有用心的用戶就能截取和**你的數(shù)據(jù)了，所以，每個(gè)用戶都必須擁有一把只屬于自己的**，那每個(gè)用戶的**都要先發(fā)給服務(wù)器，那有5000萬(wàn)個(gè)用戶服務(wù)器就有5000萬(wàn)把**，這明顯給服務(wù)器增加了太多太多的負(fù)荷，這是顯然不符合我們的需求的；其次，如果在客戶端第一次發(fā)送**給服務(wù)器的時(shí)候，此次發(fā)送是明文發(fā)送的，黑客此刻在中間截取到了我們的**，那接下來(lái)的數(shù)據(jù)黑客也能**掉，這明顯也是不符合我們的需求。但是，該加密方式計(jì)算量小，加密和解密的速度比較快，適合加密比較大的數(shù)據(jù)。好了，講完對(duì)稱加密，我們知道對(duì)稱加密存在著一些缺點(diǎn)，由此產(chǎn)生了第二種的加密方式，就是非對(duì)稱加密。

4. 非對(duì)稱加密

特點(diǎn)：有一個(gè)公鑰和一個(gè)私鑰，公鑰加密只能私鑰解密，私鑰加密只能公鑰解密。因?yàn)榻饷芎图用苁褂貌煌蔫€匙，所以稱為非對(duì)稱加密。公鑰和私鑰都放在服務(wù)器上，公鑰是可以隨便傳輸?shù)模借€是絕對(duì)不會(huì)暴露的，數(shù)據(jù)傳輸是安全的。
說(shuō)了這么多抽象的東東，我們看一個(gè)具體的例子。

首先服務(wù)器端把公鑰傳給客戶端，客戶端拿到公鑰后對(duì)數(shù)據(jù)進(jìn)行加密，然后客戶端發(fā)送使用公鑰加密過(guò)的數(shù)據(jù)到服務(wù)器，服務(wù)器收到加密后的數(shù)據(jù)后使用私鑰對(duì)數(shù)據(jù)進(jìn)行解密。
此刻，黑客即使拿到公鑰和公鑰加密后的數(shù)據(jù)，也沒(méi)法解密，因?yàn)楣€加密的數(shù)據(jù)公鑰是解不了的，只有私鑰能解。

5. 證書(shū)如何安全傳輸

當(dāng)客戶端收到這個(gè)證書(shū)之后，使用本地配置的權(quán)威機(jī)構(gòu)的公鑰對(duì)證書(shū)進(jìn)行解密得到服務(wù)端的公鑰和證書(shū)的數(shù)字簽名，數(shù)字簽名經(jīng)過(guò)CA公鑰解密得到證書(shū)信息摘要。
然后證書(shū)簽名的方法計(jì)算一下當(dāng)前證書(shū)的信息摘要，與收到的信息摘要作對(duì)比，如果一樣，表示證書(shū)一定是服務(wù)器下發(fā)的，沒(méi)有被中間人篡改過(guò)。因?yàn)橹虚g人雖然有權(quán)威機(jī)構(gòu)的公鑰，能夠解析證書(shū)內(nèi)容并篡改，但是篡改完成之后中間人需要將證書(shū)重新加密，但是中間人沒(méi)有權(quán)威機(jī)構(gòu)的私鑰，無(wú)法加密，強(qiáng)行加密只會(huì)導(dǎo)致客戶端無(wú)法解密，如果中間人強(qiáng)行亂修改證書(shū)，就會(huì)導(dǎo)致證書(shū)內(nèi)容和證書(shū)簽名不匹配。
那第三方攻擊者能否讓自己的證書(shū)顯示出來(lái)的信息也是服務(wù)端呢？（偽裝服務(wù)端一樣的配置）顯然這個(gè)是不行的，因?yàn)楫?dāng)?shù)谌焦粽呷A那邊尋求認(rèn)證的時(shí)候CA會(huì)要求其提供例如域名的whois信息、域名管理郵箱等證明你是服務(wù)端域名的擁有者，而第三方攻擊者是無(wú)法提供這些信息所以他就是無(wú)法騙CA他擁有屬于服務(wù)端的域名。

6. HTTPS加密、解密及驗(yàn)證過(guò)程

假如服務(wù)器端存有一個(gè)公鑰777和一個(gè)私鑰888，首先，瀏覽器發(fā)出一個(gè)https請(qǐng)求，如https://www.baidu.com，服務(wù)器端響應(yīng)請(qǐng)求，返回一個(gè)SSL數(shù)字證書(shū)給客戶端，SSL數(shù)字證書(shū)包括了公鑰和服務(wù)器的身份標(biāo)識(shí)信息，客戶端收到SSL數(shù)字證書(shū)之后，驗(yàn)證該數(shù)字證書(shū)是否有效，如無(wú)效，則瀏覽器會(huì)發(fā)出不安全警告，如有效，就會(huì)先生成一個(gè)隨機(jī)碼如6666，然后使用公鑰777對(duì)這個(gè)隨機(jī)碼進(jìn)行加密，然后傳輸該加密后的隨機(jī)碼到服務(wù)器，服務(wù)器使用私鑰888進(jìn)行解密，得到客戶端的隨機(jī)碼為6666，以上該過(guò)程就是我們說(shuō)的非對(duì)稱加密。此時(shí)，客戶端和服務(wù)器都同時(shí)擁有了該隨機(jī)碼6666，然后，把這個(gè)隨機(jī)碼6666用作對(duì)稱加密的**，用**6666對(duì)userName和passWord的信息進(jìn)行加密，發(fā)送到服務(wù)器端，服務(wù)器端同樣使用相同的**6666對(duì)數(shù)據(jù)進(jìn)行解密，最后得到userName和passWord的信息。以上為整個(gè)HTTPS加密、解密及驗(yàn)證的過(guò)程。

7. 總結(jié)

本文從HTTP的不安全引出HTTPS，HTTPS就是在HTTP的基礎(chǔ)上增加了一層SSL的加密協(xié)議，然后進(jìn)一步講述了兩種不同的加密方式，分別是對(duì)稱加密和非對(duì)稱加密，然后講述了兩者的不同及各自的優(yōu)缺點(diǎn)，HTTPS綜合了兩種加密方式，最后，給出了完整的HTTPS加密、解密及驗(yàn)證過(guò)程。