資訊專欄INFORMATION COLUMN
摘要：王蒙沒那么淺地談談與二四加密算法和密鑰管理介紹密鑰交換機制之前先普及一些加密算法基本知識以及為什么要有密鑰管理機制。證書證書，顧名思義，就是頒發的證書。公鑰基礎設施公鑰基礎設施，簡稱是目前網絡安全建設的基礎與核心。
**玫瑰與荊棘共生，香菇與毒菇同長，真實與假冒比翼騰飛。——王蒙
**
介紹密鑰交換機制之前先普及一些加密算法基本知識以及為什么要有密鑰管理機制。
加密算法就是將普通信息（明文）轉換成難以理解的數據（密文）的過程；
加解密包含了這兩種算法，一般加密即同時指稱加密與解密的技術。
密鑰是一個用于加解密算法的秘密參數，通常只有通信者擁有。
對稱密鑰加密是密碼學中的一種加密法，是以轉換其中一個數字、字母或僅字符串隨機字母，一個秘密密鑰會以特定的方式變更消息里面的文字或字母，例如更換字母相對位置（例如hello變成lohel）。只要寄件者與收件者知道秘密密鑰，他們可以加密和解密并使用這個數據。
公開密鑰加密（也稱為非對稱加密）是密碼學中的一種加密法，非對稱密鑰，是指一對加密密鑰與解密密鑰，某用戶使用加密密鑰加密后所獲得的數據，只能用該用戶的解密密鑰才能夠解密。如果知道了其中一個，并不能計算出另外一個。因此如果公開了其中一個密鑰，并不會危害到另外一個。因此公開的密鑰為公鑰；不公開的密鑰為私鑰。
通信雙方使用加密算法之后，需要密鑰來解密和加密信息，而雙方如何得到、交換密鑰，并且不會被第三方竊取，或者說密鑰就算被竊取也不會導致密文被解密讀取呢？
如果“單純用對稱加密”，瀏覽器和網站之間勢必先要交換“對稱加密的密鑰”。
如果這個密鑰直接用【明文】傳輸，很容易就會被第三方（有可能是“攻擊者”）偷窺到；如果這個密鑰用密文傳輸，那就再次引入了“如何交換加密密鑰”的問題——這就變成“先有雞還是先有蛋”的循環邏輯了。
基于“加密和解密采用不同的密鑰”的特點，可以避開前面提到的“循環邏輯”的困境。大致的步驟如下：
第1步 網站服務器先基于“非對稱加密算法”，隨機生成一個“密鑰對”（為敘述方便，稱之為“k1 和 k2”）。因為是隨機生成的，目前為止，只有網站服務器才知道 k1 和 k2。
第2步 網站把 k1 保留在自己手中，把 k2 用【明文】的方式發送給訪問者的瀏覽器。 因為 k2 是明文發送的，自然有可能被偷窺。不過不要緊。即使偷窺者拿到 k2，也【很難】根據 k2 推算出 k1 （這一點是由“非對稱加密算法”從數學上保證的）。
第3步 瀏覽器拿到 k2 之后，先【隨機生成】第三個對稱加密的密鑰（簡稱 k）。 然后用 k2 加密 k，得到 k（k 是 k 的加密結果） 瀏覽器把 k 發送給網站服務器。 由于 k1 和 k2 是成對的，所以只有 k1 才能解密 k2 的加密結果。 因此這個過程中，即使被第三方偷窺，第三方也【無法】從 k 解密得到 k
第4步 網站服務器拿到 k 之后，用 k1 進行解密，得到 k 至此，瀏覽器和網站服務器就完成了密鑰交換，雙方都知道 k，而且【貌似】第三方無法拿到 k 然后，雙方就可以用 k 來進行數據雙向傳輸的加密。
乍看以上步驟很嚴密，即使被第三方偷窺，第三方也難以從 k 解密得到 k。
但這種方法有一個致命的缺陷，就是無法防止數據篡改，也無法識別假冒的身份。
攻擊方法如下：
第1步 這一步跟原先一樣——服務器先隨機生成一個“非對稱的密鑰對”k1 和 k2（此時只有網站知道 k1 和 k2）
第2步 當網站發送 k2 給瀏覽器的時候，攻擊者截獲 k2，保留在自己手上。 然后攻擊者自己生成一個【偽造的】密鑰對（以下稱為 pk1 和 pk2）。 攻擊者把 pk2 發送給瀏覽器。
第3步 瀏覽器收到 pk2，以為 pk2 就是網站發送的。 瀏覽器不知情，依舊隨機生成一個對稱加密的密鑰 k，然后用 pk2 加密 k，得到密文的 k 瀏覽器把 k 發送給網站。 （以下是關鍵）
發送的過程中，再次被攻擊者截獲。 因為 pk1 pk2 都是攻擊者自己生成的，所以攻擊者自然就可以用 pk1 來解密 k 得到 k 然后，攻擊者拿到 k 之后，用之前截獲的 k2 重新加密，得到 k，并把 k 發送給網站。
第4步 網站服務器收到了 k 之后，用自己保存的 k1 可以正常解密，所以網站方面不會起疑心。 至此，攻擊者完成了一次漂亮的偷梁換柱，而且讓雙方都沒有起疑心。
上述過程，即是傳說中的中間人攻擊（Man-In-The-Middle attack ）。
為什么以上方案會失敗？
除了提到的“攻擊者具備篡改數據的能力”，還有另一點關鍵點——“缺乏身份認證機制”。
正是因為“缺乏身份認證機制”，所以當攻擊者一開始截獲 k2 并把自己偽造的 pk2 發送給瀏覽器時，瀏覽器無法鑒別：自己收到的密鑰是不是真的來自于網站服務器。
假如具備某種【可靠的】身份認證機制，即使攻擊者能夠篡改數據，但是篡改之后的數據很容易被識破。那篡改也就失去了意義。于是我們引入“CA認證體系”。
數字證書認證機構（英語：Certificate Authority，縮寫為CA），也稱為電子商務認證中心、電子商務認證授權機構，是PKI(公鑰基礎設施)的核心執行機構，是PKI的主要組成部分，并作為電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。
從廣義上講，認證中心還應該包括證書申請注冊機構RA（Registration Authority），RA是數字證書的申請注冊、證書簽發的管理機構。
CA 證書，顧名思義，就是CA頒發的證書。
人人都可以找工具制作證書。但是個人制作出來的證書是沒什么用處的。
因為你【不是】權威的 CA 機關，你自己搞的證書不具有權威性。
公鑰基礎設施（Public Key Infrastructure，簡稱PKI）是目前網絡安全建設的基礎與核心。
簡單的說PKI技術就是利用公鑰理論和技術建立的提供信息安全服務的基礎設施，該體系在統一的安全認證標準和規范基礎上提供在線身份認證，是_CA認證、數字證書、數字簽名_以及相關_安全應用組件模塊_的集合。
做為一種技術體系，PKI可以作為支持認證、完整性、機密性和不可否認性的技術基礎，從技術上解決網上身份認證、信息完整性的抗抵賴等安全問題，為網絡應用提供可靠的安全保障，但PKI不僅僅涉及到技術層面的問題。
為了盡可能的保證根證書的安全性，CA中心采取了一種樹狀的結構：
一個root CA下面包含多個intermediates CA，然后根CA和次級CA都可以頒發證書給用戶，頒發的證書分別是根證書和次級證書，最后則是用戶的證書，也可以說是中級證書。
實際上，證書之間的信任關系，是可以嵌套的。比如，C 信任 A1，A1 信任 A2，A2 信任 A3......這個叫做證書的信任鏈。
只要你信任鏈上的頭一個證書，那后續的證書，都是可以信任的。
（簽名的產生算法：首先，使用散列函數計算公開的明文信息的信息摘要，然后，采用 CA的私鑰對信息摘要進行加密，密文即簽名。）
在這個過程注意幾點：
★即便有人截取服務器A證書，再發給客戶端，想冒充服務器A，也無法實現。因為證書和url的域名是綁定的。
未完待續……
本文作者：UCloud后臺研發工程師 Hughes.Chen
博客地址：https://ulyc.github.io/
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/126007.html
摘要：握手協議它建立在記錄協議之上，用于在實際的數據傳輸開始前，通訊雙方進行身份認證協商加密算法交換加密密鑰等。包括握手協議，改變密碼協議，警告協議。配備身份證書，防止身份被冒充。鑒定依賴認證體系和加密算法。面對愚昧，神們自己也緘口不言 。——《基地》2019年8月11日，IETF 終于發布了 RFC 8446，標志著 TLS 1.3 協議大功告成 。這是該協議的第一次重大改革，帶來了重大的安全性...
摘要：公開密鑰加密的出現大大減輕了交換對稱密鑰的困難，公鑰可以公開透過不安全可被竊聽的渠道發送，用以加密明文。當與配合使用，稱之為，與配合則稱為，以此類推。這步沒有簽名，服務端收到數據后不會發現被篡改。對于認證機構，一旦私鑰外泄，將可能導致整未濟，亨。小狐汔濟，濡其尾，無攸利。——《易》六、密鑰管理當不再擔心身份會被冒充、篡改之后，我們再來詳細談談網絡通信中對于加密算法的密鑰管理。在密鑰被簽發后，...
摘要：上篇鏈接年，用更現代的方法使用上年，用更現代的方法使用中公鑰的發布與交換討論公鑰安全交換的中文文章比較少，而這一環是整個加密體系的重中之重。年月，有攻擊者惡意向公鑰服務器提交了對兩個著名網友的簽名背書。此事件中的受害者的證書就被簽名了次。上篇鏈接:2021年，用更現代的方法使用PGP（上）2021年，用更現代的方法使用PGP（中）PGP 公鑰的 發布 與 交換討論公鑰安全交換的中文文章比較少...
摘要：猜測原因是一端異常關閉了連接卻沒有通知對端，或者通知了對端但對端沒有收到。序號請求設置了超時時間為，因此發送包。之后繼續測試，沒有發現丟包。序號空閑分鐘后，主動發起報文，關閉連接。 一、故障 showImg(https://segmentfault.com/img/bVbnJQk?w=1610&h=140); 基本架構如圖所示，客戶端發起 http 請求給 nginx，nginx 轉發...
摘要：要注意老舊的瀏覽器不支持的特性，它會繼續正常加載屬性引用的圖像。五安全地使用圖片的優勢這里不再贅述，簡單來說 這篇文章，我們將一起探討，web應用中能對圖片進行什么樣的優化，以及反思一些負優化手段 一、為什么要對圖片進行優化 對于大多數前端工程師來說，圖片就是UI設計師(或者自己)切好的圖，你要做的只是把圖片丟進項目中，然后用以鏈接的方式呈現在頁面上，而且我們也經常把精力放在項目的打包...
閱讀 3514·2023-04-25 20:09
閱讀 3720·2022-06-28 19:00
閱讀 3035·2022-06-28 19:00
閱讀 3058·2022-06-28 19:00
閱讀 3131·2022-06-28 19:00
閱讀 2859·2022-06-28 19:00
閱讀 3014·2022-06-28 19:00
閱讀 2610·2022-06-28 19:00
