前面幾篇博客聊了HTTP的相關東西，今天就來聊一聊HTTPS的東西。因為HTTP協(xié)議本身存在著明文傳輸、不能很好的驗證通信方的身份和無法驗證報文的完整性等一些安全方面的確點，所以才有了HTTPS的缺陷。HTTPS確切的的說不是一種協(xié)議，而是HTTP + SSL (TSL)的結合體。HTTP報文經(jīng)過SSL層加密后交付給TCP層進行傳輸。SSL(安全套節(jié)層)主要采取的是RSA(非對稱加密)與AES(對稱加密)結合的加密方式。先通過RSA交互AES的密鑰，然后通過AES進行報文加密和解密。本篇博客主要聊的就是HTTPS具體的工作過程。

一、RSA與AES簡述

在本篇博客的開頭部分呢，先聊一下RAS與AES這兩個加密策略，如果你在公司做過支付相關的東西，對數(shù)據(jù)傳輸?shù)陌踩砸蟊容^高，這時候就得采取一些加密措施將傳輸?shù)膱笪倪M行加密，必要時再進行MD5驗簽。當然本部分聊的RAS與AES是比較簡潔的，關于這兩者具體的內(nèi)容，請自行Google吧。因為HTTPS在傳輸?shù)倪^程中使用到了RSA與AES加密算法，所以在聊HTTP+SSL之前呢，我們先簡單的聊一下AES與RSA。

1、Advanced Encryption Standard (AES: 高級加密標準)

AES，全稱：Advanced Encryption Standard----高級加密標準。該加密算法有一個密鑰，該密鑰可以用來加密，也可以用來解密，所以AES是對稱加密算法。下方這個就是AES加密和解密的過程。Client端與Server端有一個共同的Key, 這個Key是用來加密和解密的。如果報文在傳輸?shù)倪^程中被竊取了，沒有這個key, 對加密的內(nèi)容進行破解是非常困難的，當然竊取者如果有key的話，也是可以輕而易舉的解密的。所以在AES中，key是關鍵。這也就相當于你們家的門鑰匙，誰拿到鑰匙后都可以打開你們家的門。即使門鎖再結實，再安全，在鑰匙面前也是不行呢。

所以對于AES加密策略來說這個Key的保密措施要做足一些，如果之后有時間的話可以分享一些具體的AES加密策略。比如每次加密的Key都是從一個密碼本中動態(tài)生成的，而這個密碼本服務端和客戶端都有同一本，每次傳輸?shù)氖且恍﹨?shù)。這些參數(shù)在經(jīng)過一些算法的映射，從密碼本中取出相應的key用來解密。這樣一來，就相當于給AES加了一層防盜門，加大了破解的難度。這樣做的好處是每次加密的key都是不同的，而且需要密碼本以及映射算法的支持。 

2、RSA 公鑰加密算法

RAS這個名字，就是該算法三位發(fā)明者的名字的首字母的組合。RAS是非對稱加密，其在加密和解密的過程中，需要兩個Key，一個公鑰(public key)，一個是私鑰(private key)。公鑰負責加密，而私鑰負責解密。從名字就可以看出，公鑰是可以開放出去的，任何人都可以持有公鑰進行加密。而私鑰必須得進行保護，因為是用來解密的。

這樣一來，加密和解密就可以用不同的鑰匙來處理。對于加密放來說，即使你可以對報文進行加密，如果沒有私有的話也是不可以對你加密的內(nèi)容進行解密的。這就相當于一個盒子，盒子上有把鎖。你可以把東西放進去，然后再鎖上盒子。但是如果你沒有鑰匙的話，也是打不開這把鎖的。

下方這個簡圖就是服務端單向驗證的RAS非對稱加密算法，Client內(nèi)置了一個公鑰，該公鑰與Server端的私鑰是配對的，所以Client端可以使用這個內(nèi)置的Public key加密，而服務端就可以使用這個private key進行解密。目前最常用的是服務端單向認證機制。

二、CA證書

如果你自己通過RAS算法生成了一個私鑰和公鑰，在公鑰發(fā)送給客戶端的過程中有可能被篡改成其他的公鑰，而客戶端在沒有其他措施的保護下是不知道該公鑰是否就是服務器那邊的私鑰對應的公鑰的。這種自己做的RAS的公鑰和私鑰有可能在公鑰分發(fā)的過程中被篡改。下方就是Client從Server端獲取公鑰時被中間者篡改了，將public換成了自己的偽public key, 同樣這個中間者持有這個偽public key所對應的偽private key。如果客戶端使用的偽public key進行加密傳輸?shù)脑挘敲粗虚g者是可以使用自己的private key進行解密的。

舉個例子來類比一下這個問題。

假設你在古代，你出門在外，妻子在家養(yǎng)子。你們家有個箱子，箱子上有把鎖，這就是你和你妻子互通的工具。你媳婦兒負責往箱子里放東西，然后上鎖。你有把獨特的鑰匙，你負責開鎖，取東西。可是你再將箱子給鏢局托運的的過程中，被鏢局的“小黑”掉包了，箱子的外表一致，鎖看起來也一樣，可是已經(jīng)不是你的箱子了。因為路途遙遠，古代又沒有什么iPhone啥的，你媳婦沒辦法來辨別該箱子是否是原裝的。然后就將一些東西放在了箱子里邊，然后上鎖交給了鏢局的“小黑”。

因為“小黑”掉包的箱子，所以小黑有箱子的鑰匙呢，然后就可以打開這個箱子，取東西了。原來的箱子又在小黑那，小黑就可以往原來的箱子里邊隨便往箱子放點沒有價值的東西給你就行了。當你發(fā)現(xiàn)箱子里的東西不是你想要的時候，完了，小黑從鏢局辭職了，找不到人了。找鏢局的人討說法，可是鏢局的人說“小黑”是鏢局的臨時工，這個責任鏢局說了，我們不能擔。鑒于你無權無勢，這事兒也就此罷了。(故事純屬虛構，如有雷同純屬巧合)

關于更多騙子的故事請移步網(wǎng)絡劇《毛騙》一二三季。

為了防止“小黑”再次作案，所以頒布一個公正機構來證明你媳婦收到的箱子就是你發(fā)出的箱子。在RAS加密中也有一個第三方機構來充當這個角色，負責證明客戶端收到的證書就是你發(fā)送的證書，中間沒有被篡改。這個中間認證機構，就是數(shù)組證書認證機構, 其頒發(fā)的證書也就是我們常說的CA證書(CA , Certificate Authority)。

下面我們就來詳細的敘述一下證書簽名，證書分發(fā)以及證書驗證的整個過程。

1、服務端人員使用RSA算法生成兩個密鑰，一個用來加密一個用來解密。將負責加密的那個密鑰公布出去，所以我們稱之為公鑰(Public Key)，而用來解密的那個密鑰，不能對外公布，只有服務端持有，所以我們稱之為私鑰(Private Key)。服務端在將Public Key進行分發(fā)證書之前需要向CA機構申請給將要分發(fā)的公鑰進行數(shù)字簽名。(服務器公鑰負責加密，服務器私鑰負責解密)

2、生成數(shù)字簽名公鑰證書：對于CA機構來說，其也有兩個密鑰，我們暫且稱之為CA私鑰和CA公鑰。CA機構將服務端的Public Key作為輸入?yún)?shù)將其轉換為一個特有的Hash值。然后使用CA私鑰將這個Hash值進行加密處理，并與服務端的Public Key綁定在一起，生成數(shù)字簽名證書。其實數(shù)字簽名證書的本質就是服務端的公鑰+CA私鑰加密的Hash值。(CA私鑰負責簽名，CA公鑰負責驗證)

3、服務器獲取到這個已經(jīng)含有數(shù)字簽名并帶有公鑰的證書，將該證書發(fā)送給客戶端。當客戶端收到該公鑰數(shù)字證書后，會驗證其有效性。大部分客戶端都會預裝CA機構的公鑰，也就是CA公鑰。客戶端使用CA公鑰對數(shù)字證書上的簽名進行驗證，這個驗證的過程就是使用CA公鑰對CA私鑰加密的內(nèi)容進行解密，將解密后的內(nèi)容與服務端的Public Key所生成的Hash值進行匹配，如果匹配成功，則說明該證書就是相應的服務端發(fā)過來的。否則就是非法證書。

4、驗證完服務端公鑰的合法性后，就可以使用該公鑰進行加密通信了。

下方這個截圖就是蘋果的根證書的一些信息，從下方可以看出，CA證書內(nèi)容中包括加密算法，公共密鑰以及數(shù)字簽名。

下方就是公鑰以及數(shù)字簽名的具體內(nèi)容，當對下方公共密鑰進行驗證時，需要使用內(nèi)置的CA公鑰將數(shù)字簽名進行解密。然后將解密后的內(nèi)容，與公鑰生成的Hash值進行比較，如果匹配成功，那么該證書就是CA機構頒布的合法證書。 

三、HTTPS安全通信機制的建立

上面我們聊完AES與RSA加密策略，然后又聊了帶有數(shù)字簽名的公共密鑰。上面這兩部分內(nèi)容都是為HTTPS做鋪墊的，接下來就看一看HTTP+SSL是如何進行數(shù)據(jù)傳輸?shù)摹?/p>

1、HTTPS簡介

在開頭的部分也說了，HTTPS不是一個新的通信協(xié)議，而是HTTP與SSL(或TSL)的組合。SSL--安全套節(jié)層(Secure Socket Layer), TSL(Transport Layer Security 安全傳輸層)是以SSL為原型開發(fā)的協(xié)議，IETF以SSL3.0為基準后又制定了TLS1.0、TLS1.1和TLS1.2，當前主流版本為SSL3.0與TLS1.0。

HTTPS就是在HTTP與TCP層中間添加了一個SSL層。因為HTTPS被HTTP多了這層加密的流程，所以HTTPS的速度要比HTTP慢的多。

2、HTTPS的通信過程

SSL的加密過程是RSA與AES混合進行的。簡單概括一下，就是通過RSA加密方式來交換AES加解密的密鑰，然后使用AES加密的方式來傳輸報文。下方是SSL建立連接以及傳輸數(shù)據(jù)的圖解。在下圖中大體可以分為四步：

第一步：有客戶端發(fā)起的第一次握手，此次握手過程的主要目的是從服務端獲取數(shù)字簽名證書，服務端在發(fā)送數(shù)字簽名證書之前要先確認客戶端的SSL版本、加密算法等信息。

第二步：完成第一次握手后，接著進行第二次握手。第二次握手是在客戶端收到證書后發(fā)起的，主要目的是將AES加解密使用的Key (Pre-master secret)發(fā)送給服務端。當然這個AES_KEY是使用第一次握手獲取的公鑰進行加密的。客戶端收到這個使用公鑰加密后的AES_KEY，使用服務端的私鑰進行解密。這樣客戶端和服務端經(jīng)過二次握手后都持有了AES加解密的KEY。

第三步：當Client與Server端都持有AES_KEY后，就可以對HTTP報文進行加解密了。

END: 就是斷開連接了。具體如下圖所示：