裸奔
當前HTTP的局面，客戶端和服務器進行通信互動資訊都是明文的，這無疑是相當于“裸奔”，黑客輕而易舉的可以從此互動中截獲資訊，
對稱加密
那么既然是“裸奔”那就穿條褲子唄(對資料進行加密)，此時有朋友就提出了一種手段叫做“對稱加密”，簡單來說下“對稱加密”，首先需要準備一個密鑰，在對資料進行加密和解密時都使用同一個密鑰，
那么使用該方式進行加密，則需要客戶端和服務器之間進行協商確定好密鑰，雙方則對對資料進行加密和解密，就在雙方進行通信協商密鑰的程序中，依然會被黑客截取獲得密鑰從而對傳遞的資料進行解密，
非對稱加密
基于“對稱加密”存在的問題，有朋友又提出了一個加密方法叫“非對稱加密”，非對稱加密有一對密鑰分別是：公鑰和私鑰，公鑰加密的內容需要私鑰解密，私鑰加密的內容需要公鑰解密，其特點和名稱一樣，
私鑰由服務器進行存盤，不對外傳送；公鑰發送給客戶端用于加密傳送資訊和解密接收資訊，這樣的加密方式改良了一點：因為私鑰是不對外開放的，所以黑客沒有渠道獲取，則確保了客戶端發送給服務器的資料是安全的，但是由于公鑰在需要通過網路進行傳輸，黑客依然可以截獲公鑰，并將服務器發送給客戶端的資料進行破解，
對稱加密+非對稱加密
根據以上的安全改良后發現，“對稱加密”和“非對稱加密”都存在著安全隱患，“對稱加密”實際上在加密性能上是優于“非對稱加密”的，但是“非對稱加密”可以保證客戶端傳輸給服務器的加密資料是無法被破解的，那么此時又有朋友提出了“完美”的方案，也就是將二者加密演算法進行結合，實作一套加密互動機制，
結合的使用目的：第一次由服務器向客戶端發送“非對稱加密”的公鑰，然后客戶端生成一個用于進行“對稱加密”的對稱密鑰，并使用“非對稱加密”的公鑰對對稱密鑰進行加密，然后在由客戶端將加密后的對稱密鑰發送給客戶端，客戶端存盤對稱密鑰并告知客戶端收到，雙方自此針對后續通信互動的資料均使用“對稱密鑰”進行加密，如圖：
“中間人”問題(李代桃僵)
看似“完美”的方案已經抵擋了黑客“兇猛的攻擊”，但是對于這種情況黑客依然有方式來攻破你的安全防御，安全領域有一個形象的比喻叫“中間人”，黑客在于客戶端和服務器之間互動的程序中充當了一個“中間人”的角色，也就是說黑客相對于客戶端他可以偽裝成服務器，相對于服務器他可以偽裝成與之來往的客戶端，那么對于這種情況，就目前對稱加密+非對稱加密的方式依然無計可施，“中間人”通過偽裝可以截獲客戶端資訊并偽造資訊發送服務器，密鑰依然會被泄露，如圖：
數字證書
“中間人”問題其實本質偽裝身份進行冒充，那我們是不是可以通過某種東西去作為唯一身份的標識，就好居民身份證一樣，有非常權威的機構(公安機關)派發證明身份的憑據，這種情況的確就誕生了一個東西叫做數字證書，它不同于生活中的證件是看得見摸得著的實物，而是以資料形式展現的一種證書，所以叫數字證書，我們可以簡單理解，它就是網路中服務器的身份證，如圖：
CA機構
CA全稱為：certificate authority，譯為憑證管理中心，上面說了服務器在網路需要身份證(數字證書)，那么有身份證就有發證的機構，CA就是網路中派發數字證書的機構，并且同我們派發身份證的公安局一樣有著權威的合法性，PS：為服務器派發數字證書的CA往往都是需要收取一定費用的，
在你準備了荷包或者找到了免費的渠道向CA機構獲取證書時，往往需要進行申請并提交一些關鍵的資訊，如：域名、企業名、公鑰等，CA在審核無誤后就會向你下發數字證書，
數字簽名
有了權威的機構為服務器頒發了證明自己身份的數字證書，但是該證書依然需要傳遞給客戶端，讓客戶端了解“自己”(服務器)是個有身份的人，那么在這個傳書程序中，黑客依然有頒發截獲，并且篡改證書的公鑰進行偽裝，導致后續的安全問題，此時為了防止偽造和篡改就引出了一個新的手動，叫做“數字簽名”，
數字簽名怎么去理解呢，類比到生活中它就像你們公司門禁的打卡錄入了你的指紋，那么此時不可能有第二個人可以去冒充你進入公司，它就像指紋一樣具有絕對的唯一標識性，并且不可模仿修改，
我們可以試想下這樣的一個場景，你爸爸有天要出差，此時你們只能通過寫信進行溝通，你爸爸在走之前預先將指紋的樣子留下來，以后在寫信時會在信上按上他的指紋，以免有人冒充身份給你寫信，在接到信件時，你第一時間就是拿著信件上的指紋和你老婆走之前留下的指紋進行對比，如果紋路一樣則表示信件時來自你爸爸寫的，反之則有人冒充，
那么基于上訴的特點在回到數字簽名中，其實數字簽名的方式就類似于上面比喻的場景，數字證書就像上面傳遞的信件重要無比，那么此時同樣也需要一個指紋，那么這里的指紋指的就是根據Hash演算法計算出的哈希值也叫摘要，CA在頒發證書之前會對“數字證書”進行哈希運算得出摘要，并且在通過CA的私鑰對摘要進行加密得出的資料就是“數字簽名”，最后將數字證書和摘要頒發給服務器，
本質上可以總結為：數字簽名就是數字證書的摘要并且同過CA私鑰進行了加密，其主要目的是用于給客戶端做比對作業，防止篡改，
服務器向CA申請證書，CA對證書簽名并頒發流程如圖：
客戶端與CA機構
上面講述在數字簽名主要是用來防篡改的，那么在其中CA在處理數字簽名時有一個細節需要思考，就是CA最侄訓對數字證書的摘要使用CA自己的私鑰進行加密，這個時候就有疑問了，加密后客戶端收到簽名后如何獲取CA機構的公鑰對簽名進行解密？在解密后獲取了摘要，客戶端通過什么演算法進行計算出摘要從而進行比對？
針對上訴的問題解釋：其實在作業系統或瀏覽器中以及內置了大量的CA機構資訊以免通過傳遞泄露，客戶端在接收服務器的證書時會在本地找到與之匹配的CA機構從而獲取CA公鑰和哈希演算法，
下圖是查看瀏覽器中內置的CA機構資訊：
最終形態
在使用“對稱加密”+“非對稱加密”的方案時加入數字證書和數字簽名，到目前為止實際上就已經形成了SSL的安全機制，也就是HTTPS的原理，至少可以抵御大部分的安全問題，為什么不是全部？安全永遠是相對的，HTTP+SSL至少在一定層面上避免了客戶端和服務器在互動之間資料泄露、篡改的問題，
下面用文字分析和描述SSL安全機制：
-
服務器首先會向CA機構申請證書，CA機構審核后會頒發“數字證書”和“數字簽名”；
-
客戶端發送請求獲取服務器的“數字證書”和“數字簽名”；
-
客戶端根據“數字證書”的資訊在作業系統或者瀏覽器找到內置CA機構的資訊，其中主要的就是CA機構的公鑰和摘要的演算法；
-
客戶端使用CA機構的公鑰和對“數字簽名”解密獲取了摘要資訊；
-
客戶端使用對于CA機構的哈希演算法將客戶端發送的“數字證書”進行哈希運算得到摘要；
-
客戶端將自己算的摘要和客戶端發來進行解密得到的摘要進行比對，如果比對一致則證明沒有被篡改，反正篡改，
-
客戶端生成用于對傳輸資料進行加密的“對稱密鑰”；
-
客戶端從數字證書中取出服務器的公鑰將“對稱密鑰”進行加密并發送給服務器；
-
服務器接收到客戶端發送的加密資訊，并使私鑰對加密資料解密獲取到“對稱密鑰”，此時雙發已經完成密鑰協商作業；
-
在后續的通信中客戶端和服務器使用“對稱密鑰”對互動資料進行加密和解密，
整個安全機制中的關鍵在于CA機構的私鑰由絕對的安全性，黑客無法改變摘要，即使黑客拿到傳輸的資訊，如拿到證書和簽名進行了改動，此時客戶端通過摘要對比就可以發現是否有篡改，即使黑客截獲了客戶端的資料沒有私鑰，是無法解密“對稱密鑰”的，故只能知道加密后的資料無從下手，
另外，在整個安全機制中會出現兩個公鑰，我們需要注意區分和理解，
其中一個是CA的公鑰這是屬于機構的，一般會內置在作業系統或瀏覽器中，用于對數字簽名解密獲取摘要；
另一個是服務器的公鑰，該公鑰會在申請數字證書時遞交給CA，CA也會向其包含在數字證書中，主要用于客戶端和服務器之間“協商對稱密鑰”，
總結
HTTPS其實就是是一個安全版的HTTP，在HTTP基礎上加入了SSL(安全套接字協議)或TLS來保證資料傳輸的安全，SSL的安全機制和原理就是使用了：對稱加密+非對稱加密+CA(數字證書、數字簽名)來實作的，
參考文獻：https://www.17coding.info/article/22
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/3053.html
標籤：Html/Css