HTTPS（全稱： Hypertext Transfer Protocol Secure，超文本傳輸安全協(xié)議），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。本文，就來深入介紹下其原理。1 為什么需要https 使用https的原因其實很簡單，就是因為http的不安全。 當我們往服務(wù)器發(fā)送比較隱私的數(shù)據(jù)（比如說你的銀行卡，身份證）時，如果使用http進行通信。那么安全性將得不到保障。 首先數(shù)據(jù)在傳輸?shù)倪^程中，數(shù)據(jù)可能被中間人抓包拿到，那么數(shù)據(jù)就會被中間人竊取。 其次數(shù)據(jù)被中間人拿到后，中間人可能對數(shù)據(jù)進行修改或者替換，然后發(fā)往服務(wù)器。 最后服務(wù)器收到數(shù)據(jù)后，也無法確定數(shù)據(jù)有沒有被修改或替換，當然，如果服務(wù)器也無法判斷數(shù)據(jù)就真的是來源于客戶端。 總結(jié)下來，http存在三個弊端：
https就是為了解決上述問題應(yīng)運而生的。 2 基本概念 為了解決http中存在的問題，https采用了一些加解密，數(shù)字證書，數(shù)字簽名的技術(shù)來實現(xiàn)。下面先介紹一下這些技術(shù)的基本概念 對稱加密與非對稱加密為了保證消息的保密性，就需要用到加密和解密。加解密算法目前主流的分為對稱加密和非對稱加密。 1.對稱加密（共享密匙加密）：客戶端和服務(wù)器公用一個密匙用來對消息加解密，這種方式稱為對稱加密。客戶端和服務(wù)器約定好一個加密的密匙?？蛻舳嗽诎l(fā)消息前用該密匙對消息加密，發(fā)送給服務(wù)器后，服務(wù)器再用該密匙進行解密拿到消息。 對稱加密的優(yōu)點：
對稱加密的缺點：
2.非對稱加密（公有密匙加密）：既然對稱加密中，密匙那么容易泄露，那么我們可以采用一種非對稱加密的方式來解決。 采用非對稱加密時，客戶端和服務(wù)端均擁有一個公有密匙和一個私有密匙。公有密匙可以對外暴露，而私有密匙只有自己可見。 使用公有密匙加密的消息，只有對應(yīng)的私有密匙才能解開。反過來，使用私有密匙加密的消息，只有公有密匙才能解開。這樣客戶端在發(fā)送消息前，先用服務(wù)器的公匙對消息進行加密，服務(wù)器收到后再用自己的私匙進行解密。 非對稱加密的優(yōu)點：
非對稱加密的缺點：
數(shù)字證書與數(shù)字簽名 為了解決非對稱加密中公匙來源的不安全性。我們可以使用數(shù)字證書和數(shù)字簽名來解決。 1.數(shù)字證書的申請 在現(xiàn)實中，有一些專門的權(quán)威機構(gòu)用來頒發(fā)數(shù)字證書，我們稱這些機構(gòu)為認證中心（CA Certificate Authority）。 我們（服務(wù)器）可以向這些CA來申請數(shù)字證書。 申請的過程大致是： 自己本地先生成一對密匙，然后拿著自己的公匙以及其他信息（比如說企業(yè)名稱啊什么的）去CA申請數(shù)字證書。 CA在拿到這些信息后，會選擇一種單向Hash算法（比如說常見的MD5）對這些信息進行加密，加密之后的東西我們稱之為摘要。 單向Hash算法有一種特點就是單向不可逆的，只要原始內(nèi)容有一點變化，加密后的數(shù)據(jù)都將會是千差萬別（當然也有很小的可能性會重復(fù)，有興趣的小伙伴鴿巢原理了解一下），這樣就防止了信息被篡改。 生成摘要后還不算完，CA還會用自己的私匙對摘要進行加密，摘要加密后的數(shù)據(jù)我們稱之為數(shù)字簽名。 最后，CA將會把我們的申請信息（包含服務(wù)器的公匙）和數(shù)字簽名整合在一起，由此而生成數(shù)字證書。然后CA將數(shù)字證書傳遞給我們。 2.數(shù)字證書怎么起作用 服務(wù)器在獲取到數(shù)字證書后，服務(wù)器會將數(shù)字證書發(fā)送給客戶端，客戶端就需要用CA的公匙解密數(shù)字證書并驗證數(shù)字證書的合法性。那我們?nèi)绾文苣玫紺A的公匙呢？我們的電腦和瀏覽器中已經(jīng)內(nèi)置了一部分權(quán)威機構(gòu)的根證書，這些根證書中包含了CA的公匙。 之所以是根證書，是因為現(xiàn)實生活中，認證中心是分層級的，也就是說有頂級認證中心，也有下面的各個子級的認證中心，是一個樹狀結(jié)構(gòu)，計算機中內(nèi)置的是最頂級機構(gòu)的根證書，不過不用擔心，根證書的公匙在子級也是適用的。 客戶端用CA的公匙解密數(shù)字證書，如果解密成功則說明證書來源于合法的認證機構(gòu)。解密成功后，客戶端就拿到了摘要。 此時，客戶端會按照和CA一樣的Hash算法將申請信息生成一份摘要，并和解密出來的那份做對比，如果相同則說明內(nèi)容完整，沒有被篡改。最后，客戶端安全的從證書中拿到服務(wù)器的公匙就可以和服務(wù)器進行安全的非對稱加密通信了。服務(wù)器想獲得客戶端的公匙也可以通過相同方式。 下圖用圖解的方式說明一般的證書申請及其使用過程。 1 https原理 通過上面的學習，我們了解對稱加密與非對稱加密的特點和優(yōu)缺點，以及數(shù)字證書的作用。https沒有采用單一的技術(shù)去實現(xiàn)，而是根據(jù)他們的特點，充分的將這些技術(shù)整合進去，以達到性能與安全最大化。這套整合的技術(shù)我們稱之為SSL（Secure Scoket Layer 安全套接層）。所以https并非是一項新的協(xié)議，它只是在http上披了一層加密的外殼。 https的建立 先看一下建立的流程圖： 這里把https建立到斷開分為6個階段，12過程。下面將對12個過程一 一做解釋 1.客戶端通過發(fā)送Client Hello報文開始SSL通信。報文中包含客戶端支持的SSL的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密匙長度等）。 2.服務(wù)器可進行SSL通信時，會以Server Hello報文作為應(yīng)答。和客戶端一樣，在報文中包含SSL版本以及加密組件。服務(wù)器的加密組件內(nèi)容時從接收到的客戶端加密組件內(nèi)篩選出來的。 3.服務(wù)器發(fā)送證書報文。報文中包含公開密匙證書。 4.最后服務(wù)器發(fā)送Server Hello Done報文通知客戶端，最初階段的SSL握手協(xié)商部分結(jié)束。 5.SSL第一次握手結(jié)束之后，客戶端以Client Key Exchange報文作為回應(yīng)。報文包含通信加密中使用的一種被稱為Pre-master secret的隨機密碼串。該報文已用步驟3中的公開密匙進行加密。 6.接著客戶端繼續(xù)發(fā)送Change Cipher Spec報文。該報文會提示服務(wù)器，在此報文之后的通信會采用Pre-master secret密匙加密。 7.客戶端發(fā)送Finished報文。該報文包含連接至今全部報文的整體校驗值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解密該報文作為判定標準。 8.服務(wù)器同樣發(fā)送Change Cipher Spec報文 9.服務(wù)器同樣發(fā)送Finished報文 10.服務(wù)器和客戶端的Finished報文交換完畢之后，SSL連接就算建立完成。當然，通信會收到SSL的保護。從此處開始進行應(yīng)用層協(xié)議的通信，即發(fā)送HTTP請求。 11.應(yīng)用層協(xié)議通信，即發(fā)送HTTP相應(yīng)。 12.最后由客戶端斷開連接。斷開連接時，發(fā)送close_notify報文。上圖做了一些省略，這步之后再發(fā)送TCP FIN報文來關(guān)閉與TCP的通信。 另外，在以上流程圖中，應(yīng)用層發(fā)送數(shù)據(jù)時會附加一種叫做MAC（Message Authentication Code）的報文摘要。MAC能夠查知報文是否遭到篡改，從而保證報文的完整性。 下面再用圖解來形象的說明一下，此圖比上面數(shù)字證書的圖更加的詳細一些（圖片來源于《圖解HTTP》）
經(jīng)過上面的介紹，我們可以看出https先是利用數(shù)字證書保證服務(wù)器端的公匙可以安全無誤的到達客戶端。然后再用非對稱加密安全的傳遞共享密匙，最后用共享密匙安全的交換數(shù)據(jù)。 1 https的使用 https那么的安全，是不是我們在什么場景下都要去使用https進行通信呢？答案是否定的。 1.https雖然提供了消息安全傳輸?shù)耐ǖ?，但是每次消息的加解密十分耗時，消息系統(tǒng)資源。所以，除非在一些對安全性比較高的場景下，比如銀行系統(tǒng)，購物系統(tǒng)中我們必須要使用https進行通信，其他一些對安全性要求不高的場景，我們其實沒必要使用https。 2.使用https需要使用到數(shù)字證書，但是一般權(quán)威機構(gòu)頒發(fā)的數(shù)字證書都是收費的，而且價格也是不菲的，所以對于一些個人網(wǎng)站特別是學生來講，如果對安全性要求不高，也沒必要使用https。 參考資料 https://www.jianshu.com/p/4932cb1499bf https://mp.weixin.qq.com/s/StqqafHePlBkWAPQZg3NrA 《圖解HTTP》 PS：我在GitChat上面創(chuàng)建了一個免費的Chat——解讀《阿里巴巴Java開發(fā)手冊》背后的思考，站在使用者的角度試圖'揣測'部分規(guī)定背后的思考，大家對這個話題感興趣的可以掃碼一起交流學習！
|
|
|
