本文就MQTT到底單向加密還是雙向加密做一個簡單的討論。具體mqtt加密的搭建過程，請參考：
https://blog.csdn.net/sullivan_jia/article/details/80103813
到底是單項加密還是雙向加密？我們要從不同的角度去分析這件事情。但是在分析之前，我們還是有必要回顧一下基礎知識。
SSL/TLS單向認證：客戶端會認證服務器端身份，服務器端不對客戶端進行認證
SSL/TLS雙向認證：客戶端和服務端都會互相認證，即雙發之間要證書交換
不難看出，從複雜性角度上講，單向認證只需要認證服務器，對於客戶端並不要求，相當於雙向加密，較爲省時省事。
但是，從安全性角度上看，雙向加密相對安全。但是爲什麼說實習相對的呢？雖然ssl在認證結束後傳輸數據還會對數據進行對
稱加密，提高了破解難度，但仍舊存在破解隱患。所以對稱加密的密鑰長度足夠長，例如使用128位加密，就會大大增加破解
難度。然而，也僅僅是增加了破解難度，並不是有效的防止。如果傳輸的是一些相對機密數據，仍然不能保證安全性。因此，這
裏也是相對的安全。所以，ssl只是暫時解決了通訊層的安全，應用層一般還會增加一層認證防護。
因此，對於這一層的加密，從黑客的角度上而言，數據是否值得去破解，如果不值得，那麼這種加密其實是相對有效的。
然而，這並不是單項加密與雙向加密的決定性因素，本人認爲，決定性因素在與客戶端的數量。在解釋之前，我們先回顧一下單向加密與雙向加密的過程。
單向加密認證過程
雙向加密認證過程
SSL消息按如下順序發送：
1. Client Hello
客戶發送服務器信息，包括它所支持的密碼組。密碼組中有密碼算法和鑰匙大小；
2. Server Hello
服務器選擇客戶和服務器都支持的密碼組到客戶。
3. Certificate
服務器發送一個證書或一個證書鏈到客戶端，一個證書鏈開始於服務器公共鑰匙證書並結束於證明權威的根證書。這個消息是可選的，但服務器證書需要時，必須使用它。
4. Certificate request
當服務器需要鑑別客戶時，它發送一個證書請求到客戶端。在網絡程序中，這個消息很少發送。
5. Server key exchange
服務器當發送來的公共鑰匙對鑰匙交換不是很充分時，發送一個服務器鑰匙交換消息。
6. Server hello done
服務器告訴客戶完成它的初始化流通消息。
7. Certificate
假如服務器需要一個客戶證書時，客戶端發送一個證書鏈。(只有在服務器需要客戶證書時)
8. Client key exchange
客戶產生用於對稱算法的一個鑰匙。對RSA客戶用服務器公共鑰匙加密這個鑰匙信息並把它送到服務器。
9. Certificate verify
在網絡程序中，這個消息很少發送，它主要是用來允許服務器結束對客戶的鑑別處理。當用這個消息時，客戶發送用密碼函數的數字簽名的信息到服務端，當服務端用公共鑰匙解密這個消息時，服務器能夠鑑別客戶。
10. Change cipher spec
客戶發送一個消息告訴服務器改變加密模式。
11. Finished
客戶告訴服務器它已準備安全數據通信。
12. Change cipher spec
服務器發送一個消息到客戶端並告訴客戶修改加密模式。
13. Finished
服務器告訴客戶端它已準備好安全數據通信。這是client-server握手協議最後一步。
14. Encrypted data
客戶同服務器用對稱加密算法和密碼函數，並用客戶發送到服務器的祕密鑰匙加密通信。
不難發現，雙向加密是需要客戶端提供一個由ca簽署的證書。但是存在的問題是，雖然服務器端證書一份就夠，而千千萬萬的客戶端如果也安裝證書，那是非常麻煩的，需要專門的管理機構生成證書，管理證書，還要頒發給客戶端，還要各種配置，還要對證書的生命週期進行管理，所以比較費事。但是，如果只綁定一個ip，相當與每個設備都需要綁定在有獨立ip的網關，比較麻煩。何況，商用時，證書需要由由資格的第三方機構頒發證書，不可能一個設備有一個證書，費時費力，難管理。因此，綜合考慮，本人認爲，單雙向加密的難點在這裏。所以，對於很多客戶端的時候，往往使用的就是單項加密而不是雙向加密。
很簡單的例子：你訪問https的網站的時候，就是一個單項加密過程，你的瀏覽器不要提供證書，但是訪問的網站必須要提供證書。
版權聲明：本文爲博主原創文章，未經博主允許不得轉載。