和女/男票聊了一些私密的話，成天擔(dān)心消息會(huì)不會(huì)被泄漏，始終不放心，看完此文，消息傳輸安全性的來(lái)龍去脈，終于略知一二了。

一、初級(jí)階段：信息裸傳

特點(diǎn)：在網(wǎng)絡(luò)上傳遞明文

黑客定理一：網(wǎng)絡(luò)上傳遞的數(shù)據(jù)是不安全的，屬網(wǎng)絡(luò)于黑客公共場(chǎng)所，能被截取

結(jié)果：傳遞明文無(wú)異于不穿衣服裸奔

改進(jìn)方案：先加密，再在網(wǎng)絡(luò)上傳輸

二、進(jìn)階階段：傳輸密文

特點(diǎn)：

• 服務(wù)端和客戶端先約定好加密算法，加密密鑰
• 客戶端，傳輸前用約定好的密鑰加密
• 傳輸密文
• 服務(wù)端，收到消息后用約定好的密鑰解密

這么傳輸消息安全么?

黑客定理二：客戶端的代碼是不安全的，屬于黑客本地范疇，能被逆向工程，任何客戶端與服務(wù)端提前約定好的算法與密鑰都是不安全的

結(jié)果：任何客戶端的代碼混淆，二進(jìn)制化都只能提高黑客的破解門檻，本質(zhì)是不安全的

改進(jìn)方案：不能固定密鑰

三、中級(jí)階段：服務(wù)端為每個(gè)用戶生成密鑰

特點(diǎn)：

• 客戶端和服務(wù)端提前約定好加密算法，在傳遞消息前，先協(xié)商密鑰
• 客戶端，請(qǐng)求密鑰
• 服務(wù)端，返回密鑰
• 然后用協(xié)商密鑰加密消息，傳輸密文

這么傳輸安全么?

結(jié)果：

• 如黑客定理一，網(wǎng)上傳輸?shù)膬?nèi)容是不安全的，于是乎，黑客能得到加密key=X
• 如黑客定理二，客戶端和服務(wù)端提前約定的加密算法是不安全的，于是乎，黑客能得到加密算法
• 于是乎，黑客截取后續(xù)傳遞的密文，可以用對(duì)應(yīng)的算法和密鑰解密

改進(jìn)方案：協(xié)商的密鑰不能在網(wǎng)絡(luò)上傳遞

四、再進(jìn)階階段：客戶端確定密鑰，密鑰不再傳輸

特點(diǎn)：

• 協(xié)商的密鑰無(wú)需在網(wǎng)絡(luò)傳輸
• 使用“具備用戶特性的東西”作為加密密鑰，例如：用戶密碼的散列值
• 一人一密，每個(gè)人的密鑰不同
• 然后密鑰加密消息，傳輸密文
• 服務(wù)端從db里獲取這個(gè)“具備用戶特性的東西”，解密

這么傳輸安全么?

黑客定理三：用戶客戶端內(nèi)存是安全的，屬于黑客遠(yuǎn)端范疇，不能被破解

當(dāng)然，用戶中了木馬，用戶的機(jī)器被控制的情況不在此列，如果機(jī)器真被控制，監(jiān)控用戶屏幕就好了，就不用搞得這么麻煩了

結(jié)果：使用“具備用戶特性的東西”作為加密密鑰，一人一密，是安全的。只是，當(dāng)“具備用戶特性的東西”泄漏，就有潛在風(fēng)險(xiǎn)

五、高級(jí)階段：一次一密，密鑰協(xié)商

特點(diǎn)：每次通信前，進(jìn)行密鑰協(xié)商，一次一密

密鑰協(xié)商過(guò)程，如下圖所述，需要隨機(jī)生成三次密鑰，兩次非對(duì)稱加密密鑰(公鑰，私鑰)，一次對(duì)稱加密密鑰，簡(jiǎn)稱安全信道建立的“三次握手”，在客戶端發(fā)起安全信道建立請(qǐng)求后：

• 服務(wù)端隨機(jī)生成公私鑰對(duì)(公鑰pk1，私鑰pk2)，并將公鑰pk1傳給客戶端 (注意：此時(shí)黑客能截獲pk1)
• 客戶端隨機(jī)生成公私鑰對(duì)(公鑰pk11，私鑰pk22)，并將公鑰pk22，通過(guò)pk1加密，傳給服務(wù)端，(注意：此時(shí)黑客能截獲密文，也知道是通過(guò)pk1加密的，但由于黑客不知道私鑰pk2，是無(wú)法解密的)服務(wù)端收到密文，用私鑰pk2解密，得到pk11
• 服務(wù)端隨機(jī)生成對(duì)稱加密密鑰key=X，用pk11加密，傳給客戶端 (注意：同理，黑客由密文無(wú)法解密出key)，客戶端收到密文，用私鑰pk22解密，可到key=X

至此，安全信道建立完畢，后續(xù)通訊用key=X加密，以保證信息的安全性

六、總結(jié)

• 黑客定理一：網(wǎng)絡(luò)上傳遞的數(shù)據(jù)是不安全的，屬于黑客公共場(chǎng)所，能被截取
• 黑客定理二：客戶端的代碼是不安全的，屬于黑客本地范疇，能被逆向工程，任何客戶端與服務(wù)端提前約定好的算法與密鑰都是不安全的
• 黑客定理三：用戶客戶端內(nèi)存是安全的，屬于黑客遠(yuǎn)端范疇，不能被破解

對(duì)于不同加密方法明：

• 明文消息傳遞如同裸奔，不安全
• 客戶端和服務(wù)端提前約定加密算法和密鑰，不安全(好多公司都是這么實(shí)現(xiàn)的=_=)
• 服務(wù)端隨機(jī)生成密鑰，發(fā)送給客戶端，不安全
• 一人一密，客戶端使用“具備用戶特性的東西”作為加密密鑰，弱安全
• 一次一密，三次握手建立安全信道，安全

好了，這下明白了，可以放心的和女/男票發(fā)送“啪啪啪”“咻咻咻”“嘿嘿嘿”了

只要即時(shí)通訊公司有良知，不從服務(wù)端偷看，一切都是安全的。額，這個(gè)“只要”的假設(shè)，貌似不成立。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文