“姑娘們，起來(lái)吃毓婷啦！”
520剛過(guò)去，5月21號(hào)早上這句話就突然火了，像我這種單純的小寶寶根本不知道是什么意思。

正經(jīng)一點(diǎn)

好吧，今天要講的是HTTPS，很多人對(duì)HTTPS的概念一直是模模糊糊的，知道一些概念，但是真要詳細(xì)說(shuō)又說(shuō)不出多少東西來(lái)。（PS：這里的很多人指的就是我自己）所以這篇文章就來(lái)解析下HTTPS到底是個(gè)什么東東。

HTTPS

HTTPS并不是和HTTP對(duì)立的一種新的傳輸協(xié)議，而是升級(jí)版的HTTP，這里的升級(jí)就體現(xiàn)在S。
HTTPS協(xié)議 = HTTP協(xié)議 + SSL/TLS協(xié)議，在HTTPS數(shù)據(jù)傳輸?shù)倪^(guò)程中，需要用SSL/TLS對(duì)數(shù)據(jù)進(jìn)行加密和解密，需要用HTTP對(duì)加密后的數(shù)據(jù)進(jìn)行傳輸，由此可以看出HTTPS是由HTTP和SSL/TLS一起合作完成的。

SSL的全稱是Secure Sockets Layer，即安全套接層協(xié)議，是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。SSL協(xié)議在1994年被Netscape發(fā)明，后來(lái)各個(gè)瀏覽器均支持SSL，其最新的版本是3.0

TLS的全稱是Transport Layer Security，即安全傳輸層協(xié)議，最新版本的TLS（Transport Layer Security，傳輸層安全協(xié)議）是IETF（Internet Engineering Task Force，Internet工程任務(wù)組）制定的一種新的協(xié)議，它建立在SSL 3.0協(xié)議規(guī)范之上，是SSL 3.0的后續(xù)版本。在TLS與SSL3.0之間存在著顯著的差別，主要是它們所支持的加密算法不同，所以TLS與SSL3.0不能互操作。雖然TLS與SSL3.0在加密算法上不同，但是在我們理解HTTPS的過(guò)程中，我們可以把SSL和TLS看做是同一個(gè)協(xié)議。

HTTPS為了兼顧安全與效率，同時(shí)使用了對(duì)稱加密和非對(duì)稱加密。數(shù)據(jù)是被對(duì)稱加密傳輸?shù)模瑢?duì)稱加密過(guò)程需要客戶端的一個(gè)密鑰，為了確保能把該密鑰安全傳輸?shù)椒?wù)器端，采用非對(duì)稱加密對(duì)該密鑰進(jìn)行加密傳輸，總的來(lái)說(shuō)，對(duì)數(shù)據(jù)進(jìn)行對(duì)稱加密，對(duì)稱加密所要使用的密鑰通過(guò)非對(duì)稱加密傳輸。

密碼學(xué)

說(shuō)到這就不得不先講一下密碼學(xué)的基礎(chǔ)概念

1、密碼

密碼學(xué)中的“密碼”術(shù)語(yǔ)與網(wǎng)站登錄時(shí)用的密碼（password）是不一樣的概念，password 翻譯過(guò)來(lái)其實(shí)是“口令”，它是用于認(rèn)證用途的一組文本字符串。
而密碼學(xué)中的密碼（cipher）是一套算法(algorithm)，這套算法用于對(duì)消息進(jìn)行加密和解密，從明文到密文的過(guò)程稱之為加密，密文反過(guò)來(lái)生成明文稱之為解密，加密算法與解密算法合在一起稱為密碼算法。

2、密鑰

密鑰（key）是在使用密碼算法過(guò)程中輸入的一段參數(shù)。同一個(gè)明文在相同的密碼算法和不同的密鑰計(jì)算下會(huì)產(chǎn)生不同的密文。很多知名的密碼算法都是公開(kāi)的，密鑰才是決定密文是否安全的重要參數(shù)，通常密鑰越長(zhǎng)，破解的難度越大，比如一個(gè)8位的密鑰最多有256種情況，使用窮舉法，能非常輕易的破解。根據(jù)密鑰的使用方法，密碼可分為對(duì)稱加密和公鑰加密。

3、對(duì)稱加密

對(duì)稱密鑰（Symmetric-key algorithm）又稱為共享密鑰加密，加密和解密使用相同的密鑰。常見(jiàn)的對(duì)稱加密算法有DES、3DES、AES、RC5、RC6。對(duì)稱密鑰的優(yōu)點(diǎn)是計(jì)算速度快，但是它有缺點(diǎn)，接收者需要發(fā)送者告知密鑰才能解密，因此密鑰如何安全的發(fā)送給接收者成為了一個(gè)問(wèn)題。

A 給 B 發(fā)送數(shù)據(jù)時(shí)，把數(shù)據(jù)用對(duì)稱加密后發(fā)送給 B，發(fā)送過(guò)程中由于對(duì)數(shù)據(jù)進(jìn)行了加密，因此即使有人竊取了數(shù)據(jù)也沒(méi)法破解，因?yàn)樗恢烂荑€是什么。但是同樣的問(wèn)題是 B 收到數(shù)據(jù)后也一籌莫展，因?yàn)樗膊恢烂荑€是什么，那么 A 是不是可以把數(shù)據(jù)和密鑰一同發(fā)給 B 呢。當(dāng)然不行，一旦把密鑰和密鑰一起發(fā)送的話，那就跟發(fā)送明文沒(méi)什么區(qū)別了，因?yàn)橐坏┯腥税衙荑€和數(shù)據(jù)同時(shí)獲取了，密文就破解了。所以對(duì)稱加密的密鑰配是個(gè)問(wèn)題。如何解決呢，公鑰加密是一個(gè)辦法。

4、非對(duì)稱加密

公開(kāi)密鑰加密（public-key cryptography）簡(jiǎn)稱公鑰加密，這套密碼算法包含配對(duì)的密鑰對(duì)，分為加密密鑰和解密密鑰。發(fā)送者用加密密鑰進(jìn)行加密，接收者用解密密鑰進(jìn)行解密。加密密鑰是公開(kāi)的，任何人都可以獲取，因此加密密鑰又稱為公鑰（public key），解密密鑰不能公開(kāi)，只能自己使用，因此它又稱為私鑰（private key）。常見(jiàn)的公鑰加密算法有 RSA。
還是以A 給 B 發(fā)送數(shù)據(jù)為例，公鑰加密算法由接收者 B 發(fā)起

• B 生成公鑰和私鑰對(duì)，私鑰自己保存，不能透露給任何人。
• B 把公鑰發(fā)送給 A，發(fā)送過(guò)程中即使被人竊取也沒(méi)關(guān)系
• A 用公鑰把數(shù)據(jù)進(jìn)行加密，并發(fā)送給 B，發(fā)送過(guò)程中被人竊取了同樣沒(méi)關(guān)系，因?yàn)闆](méi)有配對(duì)的私鑰是沒(méi)法解密的
• B 用配對(duì)的私鑰解密。

HTTPS通信過(guò)程

理解了上面的概念，就要來(lái)說(shuō)說(shuō)最重要的HTTPS的通信過(guò)程，一個(gè)HTTPS請(qǐng)求實(shí)際上包含了兩次HTTP傳輸，可以細(xì)分為8步：

• 1、客戶端向服務(wù)器發(fā)起HTTPS請(qǐng)求，連接到服務(wù)器的443端口。

• 2、服務(wù)器端有一個(gè)密鑰對(duì)，即公鑰和私鑰，是用來(lái)進(jìn)行非對(duì)稱加密使用的，服務(wù)器端保存著私鑰，不能將其泄露，公鑰可以發(fā)送給任何人，然后將自己的公鑰直接發(fā)送給客戶端。

• 3、客戶端收到服務(wù)器端的公鑰之后，會(huì)對(duì)公鑰進(jìn)行檢查，驗(yàn)證其合法性，如果發(fā)現(xiàn)發(fā)現(xiàn)公鑰有問(wèn)題，那么HTTPS傳輸就無(wú)法繼續(xù)。嚴(yán)格的說(shuō)，這里應(yīng)該是驗(yàn)證服務(wù)器發(fā)送的數(shù)字證書的合法性，關(guān)于客戶端如何驗(yàn)證數(shù)字證書的合法性，下文會(huì)進(jìn)行說(shuō)明。

• 4、如果公鑰合格，那么客戶端會(huì)生成一個(gè)隨機(jī)值，這個(gè)隨機(jī)值就是用于進(jìn)行對(duì)稱加密的密鑰，我們將該密鑰稱之為client key，即客戶端密鑰，這樣在概念上和服務(wù)器端的密鑰容易進(jìn)行區(qū)分。然后用服務(wù)器的公鑰對(duì)客戶端密鑰進(jìn)行非對(duì)稱加密，這樣客戶端密鑰就變成密文了，至此，HTTPS中的第一次HTTP請(qǐng)求結(jié)束。

• 5、客戶端會(huì)發(fā)起HTTPS中的第二個(gè)HTTP請(qǐng)求，將加密之后的客戶端密鑰發(fā)送給服務(wù)器。

• 6、服務(wù)器接收到客戶端發(fā)來(lái)的密文之后，會(huì)用自己的私鑰對(duì)其進(jìn)行非對(duì)稱解密，解密之后的明文就是客戶端密鑰，然后用客戶端密鑰對(duì)數(shù)據(jù)進(jìn)行對(duì)稱加密，這樣數(shù)據(jù)就變成了密文。

• 7、然后服務(wù)器將加密后的密文發(fā)送給客戶端。

• 8、客戶端收到服務(wù)器發(fā)送來(lái)的密文，用客戶端密鑰對(duì)其進(jìn)行對(duì)稱解密，得到服務(wù)器發(fā)送的數(shù)據(jù)。這樣HTTPS中的第二個(gè)HTTP請(qǐng)求結(jié)束，整個(gè)HTTPS傳輸完成。

解析上面的8個(gè)步驟

• 服務(wù)器給客戶端下發(fā)公鑰，這一步?jīng)]有什么加密保護(hù)，因?yàn)榧幢惚蝗双@取了也無(wú)所謂，公鑰本身就是誰(shuí)都可以獲取的。

• 客戶端每次生成一個(gè)隨機(jī)對(duì)稱加密密鑰，這個(gè)密鑰用戶接下來(lái)整個(gè)通話過(guò)程，這個(gè)密鑰用服務(wù)器公鑰加密，只有服務(wù)器的私鑰才能解密，所以別人即使攔截下來(lái)也不可能知道密鑰是什么。

• 服務(wù)器接受到客戶端的密鑰之后就用這個(gè)密鑰和客戶端通信，通信過(guò)程就用對(duì)稱密鑰加密，至此就和傳統(tǒng)的HTTP通信差不多了，不同的是密鑰分發(fā)過(guò)程是安全的，非對(duì)稱加密的作用就是用于第一次分發(fā)密鑰。

• 為什么不全程都用非對(duì)稱加密通信呢？原因是效率，畢竟對(duì)稱加密的速度要快很多，如果每一步通信都用非對(duì)稱加密，都要校驗(yàn)證書簽名，那效率實(shí)在太低，用戶是不能忍受的。

數(shù)字證書

通過(guò)觀察HTTPS的傳輸過(guò)程，我們知道，當(dāng)服務(wù)器接收到客戶端發(fā)來(lái)的請(qǐng)求時(shí)，會(huì)向客戶端發(fā)送服務(wù)器自己的公鑰，但是黑客有可能中途篡改公鑰，將其改成黑客自己的，所以有個(gè)問(wèn)題，客戶端怎么信賴這個(gè)公鑰是自己想要訪問(wèn)的服務(wù)器的公鑰而不是黑客的呢？ 這時(shí)候就需要用到數(shù)字證書。

在講數(shù)字證書之前，先說(shuō)一個(gè)小例子。假設(shè)一個(gè)鎮(zhèn)里面有兩個(gè)人A和B，A是個(gè)富豪，B想向A借錢，但是A和B不熟，怕B借了錢之后不還。這時(shí)候B找到了鎮(zhèn)長(zhǎng)，鎮(zhèn)長(zhǎng)給B作擔(dān)保，告訴A說(shuō)：“B人品不錯(cuò)，不會(huì)欠錢不還的，你就放心借給他吧?！?A聽(tīng)了這話后，心里想：“鎮(zhèn)長(zhǎng)是全鎮(zhèn)最德高望重的了，他說(shuō)B沒(méi)問(wèn)題的話那就沒(méi)事了，我就放心了”。 于是A相信B的為人，把錢借給了B。

與此相似的，要想讓客戶端信賴公鑰，公鑰也要找一個(gè)擔(dān)保人，而且這個(gè)擔(dān)保人的身份必須德高望重，否則沒(méi)有說(shuō)服力。這個(gè)擔(dān)保人的就是證書認(rèn)證中心（Certificate Authority），簡(jiǎn)稱CA。 也就是說(shuō)CA是專門對(duì)公鑰進(jìn)行認(rèn)證，進(jìn)行擔(dān)保的，也就是專門給公鑰做擔(dān)保的擔(dān)保公司。 全球知名的CA也就100多個(gè)，這些CA都是全球都認(rèn)可的，比如VeriSign、DigiCert、GlobalSign等，國(guó)內(nèi)知名的CA有WoSign。

那CA怎么對(duì)公鑰做擔(dān)保認(rèn)證呢？CA本身也有一對(duì)公鑰和私鑰，CA會(huì)用CA自己的私鑰對(duì)要進(jìn)行認(rèn)證的公鑰進(jìn)行非對(duì)稱加密，此處待認(rèn)證的公鑰就相當(dāng)于是明文，加密完之后，得到的密文再加上證書的過(guò)期時(shí)間、頒發(fā)給、頒發(fā)者等信息，就組成了數(shù)字證書。

不論什么平臺(tái)，設(shè)備的操作系統(tǒng)中都會(huì)內(nèi)置100多個(gè)全球公認(rèn)的CA，說(shuō)具體點(diǎn)就是設(shè)備中存儲(chǔ)了這些知名CA的公鑰。當(dāng)客戶端接收到服務(wù)器的數(shù)字證書的時(shí)候，會(huì)進(jìn)行如下驗(yàn)證：

• 首先客戶端會(huì)用設(shè)備中內(nèi)置的CA的公鑰嘗試解密數(shù)字證書，如果所有內(nèi)置的CA的公鑰都無(wú)法解密該數(shù)字證書，說(shuō)明該數(shù)字證書不是由一個(gè)全球知名的CA簽發(fā)的，這樣客戶端就無(wú)法信任該服務(wù)器的數(shù)字證書。

• 如果有一個(gè)CA的公鑰能夠成功解密該數(shù)字證書，說(shuō)明該數(shù)字證書就是由該CA的私鑰簽發(fā)的，因?yàn)楸凰借€加密的密文只能被與其成對(duì)的公鑰解密。

• 除此之外，還需要檢查客戶端當(dāng)前訪問(wèn)的服務(wù)器的域名是與數(shù)字證書中提供的“頒發(fā)給”這一項(xiàng)吻合，還要檢查數(shù)字證書是否過(guò)期等。

通過(guò)瀏覽器直接獲取服務(wù)器的公鑰很容易，各個(gè)瀏覽器操作大同小異。百度現(xiàn)在已經(jīng)實(shí)現(xiàn)了全站點(diǎn)HTTPS，我們就以github為例如何從Chrome中獲取其公鑰。

• 用Chrome打開(kāi)github首頁(yè)，在https左側(cè)我們會(huì)發(fā)現(xiàn)有一個(gè)綠色的鎖頭。

  
  

• 點(diǎn)擊綠鎖區(qū)域，出現(xiàn)彈窗，點(diǎn)擊證書

  
  

• 點(diǎn)開(kāi)后就可以看到github網(wǎng)站的證書了

  
  

在常規(guī)頁(yè)面可以看到證書的頒發(fā)者，頒發(fā)對(duì)象和有效期

• 切換到詳細(xì)信息頁(yè)面，可以看到證書的版本號(hào)、序列號(hào)、簽名算法等等

  
  

• 點(diǎn)擊右下角的“復(fù)制到文件”，導(dǎo)出證書

  
  

• 導(dǎo)出到桌面后，看到就是這樣一個(gè)文件

  
  

• 切換到“證書路徑”面板，可以查看證書的證書鏈。

  
  

這里先解釋一下什么是證書鏈。前面說(shuō)到過(guò)，DigiCert是一個(gè)全球知名的CA，但是一般情況下，CA不會(huì)用自己的私鑰去直接簽名某網(wǎng)站的數(shù)字證書，一般CA會(huì)首先簽發(fā)一種證書，然后用這種證書再去簽發(fā)百度等的數(shù)字證書。在此例中，DigiCert簽發(fā)了下屬的DigiCert SHA2 Extended Validation Server CA證書，然后下屬證書又簽發(fā)了github.om，DigiCert位于最頂端，類似于根結(jié)點(diǎn)，因此叫做根CA，中間有可能有多個(gè)下屬CA，這樣從根CA到下屬CA，再到最終的網(wǎng)站的證書，這樣自上而下形成了一條證書鏈。如果想要查看證書鏈中的某個(gè)證書，只需要選中它，比如選中了DigiCert，然后點(diǎn)擊下面的“查看證書”按鈕就會(huì)彈出另一個(gè)對(duì)話框，在其中可以查看DigiCert的數(shù)字證書，當(dāng)然也可以將其導(dǎo)出成證書文件保存在硬盤上。

總結(jié)

以上就是HTTPS的相關(guān)內(nèi)容，下一篇文章再講下Android中如何使用HTTPS。

說(shuō)到這，我想起一個(gè)很久前的故事，某日我寫了一篇博客，一個(gè)心懷夢(mèng)想的年輕人看了我的博客，并給我打了2塊錢的賞，今后幾年他事業(yè)順利，婚姻幸福，身體健康，越來(lái)越帥，從此走上人生巔峰。