什麼是通訊的安全性？考慮通訊的幾個要素：對方通過一條線路傳送資訊。
對方：如何判斷對方身份真實性（偽裝）？
資訊：如何保證資訊不被竊聽和篡改？
防竊聽，防篡改，防偽裝，是總的需求。
加密演算法( 明文, 金鑰k ) => 密文； 解密演算法( 密文, 金鑰k ) => 明文
例如：餘則成（老余）和上級通訊，雙方約定了秘鑰k。
老余加密資訊：加密演算法( 「我是老余」, 秘鑰k ) => 「d%8v#1=」
老余傳送資訊：「d%8v#1=」
上級接收資訊：「d%8v#1=」
上級解密資訊：解密演算法(「d%8v#1=」, 秘鑰k ) => 「我是老余」
敵人可以偽裝老余，例如傳送」請求與上級接頭」這樣的資訊
無法容忍這種事情發生，就要在技術上做改進。
把單一的秘鑰k**成兩個，乙個公鑰g，乙個私鑰p
加密演算法( 明文, 私鑰p ) => 密文； 解密演算法( 密文, 公鑰g ) => 明文
或者加密演算法( 明文, 公鑰g ) => 密文； 解密演算法( 密文, 私鑰p ) => 明文
私鑰p只有老余乙個人儲存，公鑰g由上級儲存。
老余加密資訊：加密演算法( 「我是老余」, 私鑰p ) => 「d%8v#1=」
老余傳送資訊：「d%8v#1=」
上級接收資訊：「d%8v#1=」
上級解密資訊：解密演算法(「d%8v#1=」, 公鑰g ) => 「我是老余」
老余無法否認」我是老余」這條資訊與自己有關（要麼是老余傳送的，要麼是老余把私鑰洩露給敵人，敵人偽裝傳送）
上級加密資訊：加密演算法( 「請求接頭」, 公鑰g ) => 「d%8v#1=」
上級傳送資訊：「d%8v#1=」
老余接收資訊：「d%8v#1=」
老余解密資訊：解密演算法(「d%8v#1=」, 私鑰p ) => 「請求接頭」
這條資訊只有老余才能解密，因為老余唯一持有解密用的秘鑰p。如果訊息被敵人竊聽，只有兩個洩漏點，其它持有老余公鑰g的人是無法解密的。
非對稱加密具有一定改進的防偽裝，防竊聽功能。
秘鑰分發和保管仍是安全管理難題。老余需要保管自己的私鑰p和上級的公鑰g，至少兩把秘鑰。上級需要保管自己的私鑰p和老余的公鑰g兩把秘鑰。假設老余的住宅被敵人潛入後替換了上級公鑰g為敵人的公鑰g（對應敵人的私鑰p）。
敵人加密資訊：加密演算法( 「請求接頭」, 私鑰p ) => 「d%8v#1=」
敵人傳送資訊：「d%8v#1=」
老余接收資訊：「d%8v#1=」
老余解密資訊：解密演算法(「d%8v#1=」, 公鑰g ) => 「請求接頭」
老余以為公鑰g是上級的（實際不是），老余認為上級要接頭，就出現了危險。
用私鑰加密的資料，傳送方無法否認。因為只有傳送方唯一擁有私鑰。簽名的本質是： 資訊只能由唯一的實體建立，這條資訊就是這個實體的簽名。私鑰主要用來做數字簽名。私鑰做資料正文加密，沒有多少優勢，因為有n個人持有公鑰，洩**不好排查
傳送方的資訊，通過某種演算法（雜湊），把大段資訊生成小段資訊（類似長篇**， 前面的小段摘要資訊），然後用私鑰加密。看來數字摘要肯定能屬於數字簽名概念。區別是，接收方可以根據數字摘要判斷資訊是否被篡改過。
傳送方： 加密演算法（明文）=> 密文
傳送方： 雜湊演算法（明文）=> 明文摘要1
傳送方： 加密演算法（明文摘要1， 私鑰p）=> 數字摘要
傳送方： 傳送密文，傳送數字摘要
接收方： 獲得明文
接收方： 雜湊演算法（明文）=> 明文摘要2
接收方： 解密演算法（數字摘要， 公鑰g）=>明文摘要1
接收方： 如果明文摘要1 等於 明文摘要2，則無篡改。
證書認證：
browser請求與server通訊。browser比較關心server是否是釣魚**，蒐集自己的信用卡賬號和密碼。server把乙個證書c（內容server的公鑰，發證機構a，頒發給網域名稱，過期日期，數字摘要……）server告訴brower：我是有權威機構認證的誠信**。brower想，你當我傻嗎，說真的就是真的，我要去調查一下。brower在本機上找到發證機構a的公鑰。目的是驗證數字摘要是否合法。如果合法，說明證書c未被篡改，而且是發證機構a簽名的。brower放心了證書是真的，然後根據證書檢查一下：證書過期了嗎？頒發給網域名稱是否與server一致等。
發證機構a的公鑰是**來的？全世界就那麼幾十號上百號權威發證機構， 瀏覽器或作業系統已經預先儲存了所有權威發證機構的公鑰。如果瀏覽器被黑，這個事就掛了。雖然browser無需儲存**的公鑰，要儲存發證機構的公鑰。
對稱秘鑰協商：
brower：隨機生成對稱加密的秘鑰p。
brower：加密演算法（」秘鑰p」， sever的公鑰）=> 「d%8v#1=」
把」秘鑰p」當做被加密的明文
server： 解密演算法（」 d%8v#1=」， sever的私鑰）=> 秘鑰p
現在，server和browser可以用秘鑰p進行對稱加密會話了。每次請求，可以更換一次秘鑰p，這樣變來變去，黑客沒有時間破解。而且，對稱加密演算法速度快，讓業務更流暢的執行。真是一舉多得。
brower不用儲存一大堆**的公鑰了，安全性多了很多。
server要儲存好自己的私鑰和自己的公鑰（2個字串）。這些是從權威機構認證ca獲取的，需要配置在server的電腦裡。而且每年要交一些服務費給權威認證機構。
Https安全通訊原理
是什麼？是基於安全目的的http 通道，其安全基礎由ssl 層來保證。最初由netscape 2.與http 主要區別 協議基礎不同 https 在http 下加入了ssl層，通訊方式不同 https 在資料通訊之前需要客戶端 伺服器進行握手 身份認證 建立連線後，傳輸資料經過加密，通訊埠443。傳...
Https安全通訊機制
通訊使用明文 不加密 內容可能可能會被竊聽 不驗證通訊方的身份，因此可能遭遇偽裝 無法驗證報文的完整性，所以可能已被篡改 1 加密處理和認證 如果在http中使用未經加密的明文，比如在web頁面中輸入了信用卡號，如果這條通訊線路找到竊聽，那麼你的信用卡號就暴露了，另外服務端和客戶端都是沒法確認通訊方...
https通訊的安全機制
此文只描述整體安全原理，具體業務上的演變未在此文中描述。資訊 hash 摘要 摘要 私鑰 數字簽名 給收方做對比用的，驗證收發內容是否一致 公鑰 相關資訊 ca私鑰 數字證書 驗證傳送者是否正確，是可信任的公鑰 以一次伺服器與客戶端的資料互動說明安全機制，整體流程如下 伺服器會將自己的公鑰 a 和公...