和女/男票聊了一些私密的話，成天擔心消息會不會被洩漏，始終不放心，看完此文，消息傳輸安全性的來龍去脈，終於略知一二了。
一、初級階段：信息裸傳
特點：在網絡上傳遞明文
黑客定理一：網絡上傳遞的數據是不安全的，屬網絡於黑客公共場所，能被截取
結果：傳遞明文無異於不穿衣服裸奔
改進方案：先加密，再在網絡上傳輸
二、進階階段：傳輸密文
特點：
- 服務端和客戶端先約定好加密算法，加密密鑰
- 客戶端，傳輸前用約定好的密鑰加密
- 傳輸密文
- 服務端，收到消息後用約定好的密鑰解密
這麼傳輸消息安全麼？
黑客定理二：客戶端的代碼是不安全的，屬於黑客本地範疇，能被逆向工程，任何客戶端與服務端提前約定好的算法與密鑰都是不安全的
結果：任何客戶端的代碼混淆，二進制化都只能提高黑客的破解門檻，本質是不安全的
改進方案：不能固定密鑰
三、中級階段：服務端為每個用戶生成密鑰
特點：
- 客戶端和服務端提前約定好加密算法，在傳遞消息前，先協商密鑰
- 客戶端，請求密鑰
- 服務端，返回密鑰
- 然後用協商密鑰加密消息，傳輸密文
這麼傳輸安全麼？
結果：
- 如黑客定理一，網上傳輸的內容是不安全的，於是乎，黑客能得到加密key=X
- 如黑客定理二，客戶端和服務端提前約定的加密算法是不安全的，於是乎，黑客能得到加密算法
- 於是乎，黑客截取後續傳遞的密文，可以用對應的算法和密鑰解密
改進方案：協商的密鑰不能在網絡上傳遞
四、再進階階段：客戶端確定密鑰，密鑰不再傳輸
特點：
- 協商的密鑰無需在網絡傳輸
- 使用“具備用戶特性的東西”作為加密密鑰，例如：用戶密碼的散列值
- 一人一密，每個人的密鑰不同
- 然後密鑰加密消息，傳輸密文
- 服務端從db裡獲取這個“具備用戶特性的東西”，解密
這麼傳輸安全麼？
黑客定理三：用戶客戶端內存是安全的，屬於黑客遠端範疇，不能被破解
當然，用戶中了木馬，用戶的機器被控制的情況不在此列，如果機器真被控制，監控用戶屏幕就好了，就不用搞得這麼麻煩了
結果：使用“具備用戶特性的東西”作為加密密鑰，一人一密，是安全的。只是，當“具備用戶特性的東西”洩漏，就有潛在風險
五、高級階段：一次一密，密鑰協商
特點：每次通信前，進行密鑰協商，一次一密
密鑰協商過程，如下圖所述，需要隨機生成三次密鑰，兩次非對稱加密密鑰（公鑰，私鑰），一次對稱加密密鑰，簡稱安全信道建立的“三次握手”，在客戶端發起安全信道建立請求後：
- 服務端隨機生成公私鑰對(公鑰pk1，私鑰pk2)，並將公鑰pk1傳給客戶端
- (注意：此時黑客能截獲pk1)
- 客戶端隨機生成公私鑰對(公鑰pk11，私鑰pk22)，並將公鑰pk22，通過pk1加密，傳給服務端
- (注意：此時黑客能截獲密文，也知道是通過pk1加密的，但由於黑客不知道私鑰pk2，是無法解密的)
- 服務端收到密文，用私鑰pk2解密，得到pk11
- 服務端隨機生成對稱加密密鑰key=X，用pk11加密，傳給客戶端
- (注意：同理，黑客由密文無法解密出key)
- 客戶端收到密文，用私鑰pk22解密，可到key=X
至此，安全信道建立完畢，後續通訊用key=X加密，以保證信息的安全性
六、總結
黑客定理一：網絡上傳遞的數據是不安全的，屬於黑客公共場所，能被截取
黑客定理二：客戶端的代碼是不安全的，屬於黑客本地範疇，能被逆向工程，任何客戶端與服務端提前約定好的算法與密鑰都是不安全的
黑客定理三：用戶客戶端內存是安全的，屬於黑客遠端範疇，不能被破解
對於不同加密方法明：
- 明文消息傳遞如同裸奔，不安全
- 客戶端和服務端提前約定加密算法和密鑰，不安全（好多公司都是這麼實現的=_=）
- 服務端隨機生成密鑰，發送給客戶端，不安全
- 一人一密，客戶端使用“具備用戶特性的東西”作為加密密鑰，弱安全
- 一次一密，三次握手建立安全信道，安全
好了，這下明白了，可以放心的和女/男票發送“啪啪啪”“咻咻咻”“嘿嘿嘿”了
只要即時通訊公司有良知，不從服務端偷看，一切都是安全的。額，這個“只要”的假設，貌似不成立
閱讀更多 程序員界的彭于晏 的文章
