和HTTPS握個手 正經一點 HTTPS 密碼學 HTTPS通信過程 解析上面的8個步驟 數字證書 總結

“姑娘們，起來喫毓婷啦！”
520剛過去，5月21號早上這句話就突然火了，像我這種單純的小寶寶根本不知道是什麼意思。

正經一點

好吧，今天要講的是HTTPS，很多人對HTTPS的概念一直是模模糊糊的，知道一些概念，但是真要詳細說又說不出多少東西來。（PS：這裏的很多人指的就是我自己）所以這篇文章就來解析下HTTPS到底是個什麼東東。

HTTPS

HTTPS並不是和HTTP對立的一種新的傳輸協議，而是升級版的HTTP，這裏的升級就體現在S。
HTTPS協議 = HTTP協議 + SSL/TLS協議，在HTTPS數據傳輸的過程中，需要用SSL/TLS對數據進行加密和解密，需要用HTTP對加密後的數據進行傳輸，由此可以看出HTTPS是由HTTP和SSL/TLS一起合作完成的。

SSL的全稱是Secure Sockets Layer，即安全套接層協議，是爲網絡通信提供安全及數據完整性的一種安全協議。SSL協議在1994年被Netscape發明，後來各個瀏覽器均支持SSL，其最新的版本是3.0

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

HTTPS爲了兼顧安全與效率，同時使用了對稱加密和非對稱加密。數據是被對稱加密傳輸的，對稱加密過程需要客戶端的一個密鑰，爲了確保能把該密鑰安全傳輸到服務器端，採用非對稱加密對該密鑰進行加密傳輸，總的來說，對數據進行對稱加密，對稱加密所要使用的密鑰通過非對稱加密傳輸。

密碼學

說到這就不得不先講一下密碼學的基礎概念

1、密碼

密碼學中的“密碼”術語與網站登錄時用的密碼（password）是不一樣的概念，password 翻譯過來其實是“口令”，它是用於認證用途的一組文本字符串。
而密碼學中的密碼（cipher）是一套算法(algorithm)，這套算法用於對消息進行加密和解密，從明文到密文的過程稱之爲加密，密文反過來生成明文稱之爲解密，加密算法與解密算法合在一起稱爲密碼算法。

2、密鑰

密鑰（key）是在使用密碼算法過程中輸入的一段參數。同一個明文在相同的密碼算法和不同的密鑰計算下會產生不同的密文。很多知名的密碼算法都是公開的，密鑰纔是決定密文是否安全的重要參數，通常密鑰越長，破解的難度越大，比如一個8位的密鑰最多有256種情況，使用窮舉法，能非常輕易的破解。根據密鑰的使用方法，密碼可分爲對稱加密和公鑰加密。

3、對稱加密

對稱密鑰（Symmetric-key algorithm）又稱爲共享密鑰加密，加密和解密使用相同的密鑰。常見的對稱加密算法有DES、3DES、AES、RC5、RC6。對稱密鑰的優點是計算速度快，但是它有缺點，接收者需要發送者告知密鑰才能解密，因此密鑰如何安全的發送給接收者成爲了一個問題。

A 給 B 發送數據時，把數據用對稱加密後發送給 B，發送過程中由於對數據進行了加密，因此即使有人竊取了數據也沒法破解，因爲它不知道密鑰是什麼。但是同樣的問題是 B 收到數據後也一籌莫展，因爲它也不知道密鑰是什麼，那麼 A 是不是可以把數據和密鑰一同發給 B 呢。當然不行，一旦把密鑰和密鑰一起發送的話，那就跟發送明文沒什麼區別了，因爲一旦有人把密鑰和數據同時獲取了，密文就破解了。所以對稱加密的密鑰配是個問題。如何解決呢，公鑰加密是一個辦法。

4、非對稱加密

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

• B 生成公鑰和私鑰對，私鑰自己保存，不能透露給任何人。
• B 把公鑰發送給 A，發送過程中即使被人竊取也沒關係
• A 用公鑰把數據進行加密，併發送給 B，發送過程中被人竊取了同樣沒關係，因爲沒有配對的私鑰是沒法解密的
• B 用配對的私鑰解密。

HTTPS通信過程

理解了上面的概念，就要來說說最重要的HTTPS的通信過程，一個HTTPS請求實際上包含了兩次HTTP傳輸，可以細分爲8步：

• 1、客戶端向服務器發起HTTPS請求，連接到服務器的443端口。

• 2、服務器端有一個密鑰對，即公鑰和私鑰，是用來進行非對稱加密使用的，服務器端保存着私鑰，不能將其泄露，公鑰可以發送給任何人，然後將自己的公鑰直接發送給客戶端。

• 3、客戶端收到服務器端的公鑰之後，會對公鑰進行檢查，驗證其合法性，如果發現發現公鑰有問題，那麼HTTPS傳輸就無法繼續。嚴格的說，這裏應該是驗證服務器發送的數字證書的合法性，關於客戶端如何驗證數字證書的合法性，下文會進行說明。

• 4、如果公鑰合格，那麼客戶端會生成一個隨機值，這個隨機值就是用於進行對稱加密的密鑰，我們將該密鑰稱之爲client key，即客戶端密鑰，這樣在概念上和服務器端的密鑰容易進行區分。然後用服務器的公鑰對客戶端密鑰進行非對稱加密，這樣客戶端密鑰就變成密文了，至此，HTTPS中的第一次HTTP請求結束。

• 5、客戶端會發起HTTPS中的第二個HTTP請求，將加密之後的客戶端密鑰發送給服務器。

• 6、服務器接收到客戶端發來的密文之後，會用自己的私鑰對其進行非對稱解密，解密之後的明文就是客戶端密鑰，然後用客戶端密鑰對數據進行對稱加密，這樣數據就變成了密文。

• 7、然後服務器將加密後的密文發送給客戶端。

• 8、客戶端收到服務器發送來的密文，用客戶端密鑰對其進行對稱解密，得到服務器發送的數據。這樣HTTPS中的第二個HTTP請求結束，整個HTTPS傳輸完成。

解析上面的8個步驟

• 服務器給客戶端下發公鑰，這一步沒有什麼加密保護，因爲即便被人獲取了也無所謂，公鑰本身就是誰都可以獲取的。

• 客戶端每次生成一個隨機對稱加密密鑰，這個密鑰用戶接下來整個通話過程，這個密鑰用服務器公鑰加密，只有服務器的私鑰才能解密，所以別人即使攔截下來也不可能知道密鑰是什麼。

• 服務器接受到客戶端的密鑰之後就用這個密鑰和客戶端通信，通信過程就用對稱密鑰加密，至此就和傳統的HTTP通信差不多了，不同的是密鑰分發過程是安全的，非對稱加密的作用就是用於第一次分發密鑰。

• 爲什麼不全程都用非對稱加密通信呢？原因是效率，畢竟對稱加密的速度要快很多，如果每一步通信都用非對稱加密，都要校驗證書籤名，那效率實在太低，用戶是不能忍受的。

數字證書

通過觀察HTTPS的傳輸過程，我們知道，當服務器接收到客戶端發來的請求時，會向客戶端發送服務器自己的公鑰，但是黑客有可能中途篡改公鑰，將其改成黑客自己的，所以有個問題，客戶端怎麼信賴這個公鑰是自己想要訪問的服務器的公鑰而不是黑客的呢？ 這時候就需要用到數字證書。

在講數字證書之前，先說一個小例子。假設一個鎮裏面有兩個人A和B，A是個富豪，B想向A借錢，但是A和B不熟，怕B借了錢之後不還。這時候B找到了鎮長，鎮長給B作擔保，告訴A說：“B人品不錯，不會欠錢不還的，你就放心借給他吧。” A聽了這話後，心裏想：“鎮長是全鎮最德高望重的了，他說B沒問題的話那就沒事了，我就放心了”。 於是A相信B的爲人，把錢借給了B。

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

那CA怎麼對公鑰做擔保認證呢？CA本身也有一對公鑰和私鑰，CA會用CA自己的私鑰對要進行認證的公鑰進行非對稱加密，此處待認證的公鑰就相當於是明文，加密完之後，得到的密文再加上證書的過期時間、頒發給、頒發者等信息，就組成了數字證書。

不論什麼平臺，設備的操作系統中都會內置100多個全球公認的CA，說具體點就是設備中存儲了這些知名CA的公鑰。當客戶端接收到服務器的數字證書的時候，會進行如下驗證：

• 首先客戶端會用設備中內置的CA的公鑰嘗試解密數字證書，如果所有內置的CA的公鑰都無法解密該數字證書，說明該數字證書不是由一個全球知名的CA簽發的，這樣客戶端就無法信任該服務器的數字證書。

• 如果有一個CA的公鑰能夠成功解密該數字證書，說明該數字證書就是由該CA的私鑰簽發的，因爲被私鑰加密的密文只能被與其成對的公鑰解密。

• 除此之外，還需要檢查客戶端當前訪問的服務器的域名是與數字證書中提供的“頒發給”這一項吻合，還要檢查數字證書是否過期等。

通過瀏覽器直接獲取服務器的公鑰很容易，各個瀏覽器操作大同小異。百度現在已經實現了全站點HTTPS，我們就以github爲例如何從Chrome中獲取其公鑰。

• 用Chrome打開github首頁，在https左側我們會發現有一個綠色的鎖頭。

  
  

• 點擊綠鎖區域，出現彈窗，點擊證書

  
  

• 點開後就可以看到github網站的證書了

  
  

在常規頁面可以看到證書的頒發者，頒發對象和有效期

• 切換到詳細信息頁面，可以看到證書的版本號、序列號、簽名算法等等

  
  

• 點擊右下角的“複製到文件”，導出證書

  
  

• 導出到桌面後，看到就是這樣一個文件

  
  

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

  
  

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

總結

以上就是HTTPS的相關內容，下一篇文章再講下Android中如何使用HTTPS。

說到這，我想起一個很久前的故事，某日我寫了一篇博客，一個心懷夢想的年輕人看了我的博客，並給我打了2塊錢的賞，今後幾年他事業順利，婚姻幸福，身體健康，越來越帥，從此走上人生巔峯。