SSL/TLS協(xié)議在車聯(lián)網(wǎng)通信安全中的應(yīng)用

前言

專注分享開源項(xiàng)目整套解決方案，完全開源、可學(xué)習(xí)、可商用、寶藏庫。

完整開源項(xiàng)目后端技術(shù)棧：Spring6、JDK17、SpringBoot、Spring Cloud、Docker、Nginx、Redis、MongoDB、MySql不管你技術(shù)提升還是接私活都可以用到。

完整開源項(xiàng)目前端技術(shù)棧：vue3、vite3、TypeScript/4、Ant-Design-Vue/3.2、element-plus/2.2、uniapp、H5網(wǎng)頁、PC、微信小程序等最新的技術(shù)。

每天提供一個(gè)超棒的開源項(xiàng)目包含：物聯(lián)網(wǎng)平臺(tái)、WMS系統(tǒng)、ERP系統(tǒng)、OMS系統(tǒng)、知識(shí)社區(qū)、個(gè)人博客系列。

在本專題系列文章中，我們將根據(jù) EMQ 在車聯(lián)網(wǎng)領(lǐng)域的實(shí)踐經(jīng)驗(yàn)，從協(xié)議選擇等理論知識(shí)，到平臺(tái)架構(gòu)設(shè)計(jì)等實(shí)戰(zhàn)操作，與大家分享如何搭建一個(gè)可靠、高效、符合行業(yè)場(chǎng)景需求的車聯(lián)網(wǎng)平臺(tái)。

一、前言

在汽車出行愈加智能化的今天，我們可以實(shí)現(xiàn)手機(jī)遠(yuǎn)程操控車輛解鎖、啟動(dòng)通風(fēng)、查看車輛周圍影像，也可以通過 OTA（空中下載技術(shù)）完成升級(jí)車機(jī)固件、更新地圖包等操作，自動(dòng)駕駛技術(shù)更是可以讓車輛根據(jù)路面狀況自動(dòng)輔助實(shí)施轉(zhuǎn)向、加速和制動(dòng)。

然而，每項(xiàng)提升我們使用體驗(yàn)的功能，都有可能成為致命的安全漏洞。騰訊安全科恩實(shí)驗(yàn)室曾向外界披露并演示過如何憑借 3/4G 網(wǎng)絡(luò)或者 WiFi 網(wǎng)絡(luò)，在遠(yuǎn)程無物理接觸的情況下入侵智能汽車，實(shí)現(xiàn)對(duì)車輛信號(hào)燈、顯示屏、門鎖甚至是剎車的遠(yuǎn)程控制。不僅如此，攻擊者甚至可以利用某個(gè)已知漏洞獲取智能汽車的 Autopilot 控制權(quán)，對(duì)車輛行駛方向進(jìn)行操控。

因此，我們?cè)谲嚶?lián)網(wǎng)平臺(tái)構(gòu)建時(shí)也應(yīng)充分認(rèn)識(shí)到通信安全、身份認(rèn)證、數(shù)據(jù)安全的重要性，正確使用相關(guān)加密認(rèn)證等技術(shù)手段來提供保障。

本篇文章我們將全面介紹 SSL/TLS 協(xié)議在車聯(lián)網(wǎng)通信安全中的應(yīng)用，希望能讓大家對(duì) SSL/TLS 的作用有更清晰直觀的認(rèn)識(shí)。此外，我們還將詳細(xì)講解 SSL/TLS 的配置方式，確保大家能正確使用 SSL/TLS，實(shí)現(xiàn)安全性保障。

二、車聯(lián)網(wǎng)安全通信 MQTTS 協(xié)議

MQTTS 協(xié)議是在 MQTT 協(xié)議的基礎(chǔ)上，封裝了一層基于 SSL/TLS（傳輸層安全）的加密協(xié)議， 它確保車機(jī)端和車聯(lián)網(wǎng)平臺(tái)通信是加密的。但如果沒有正確配置 SSL/TLS，依然會(huì)存在很多安全隱患。想要真正運(yùn)用好 SSL/TLS，我們必須了解 SSL/TLS 解決了哪些問題，以及對(duì) SSL/TLS 用到的密碼技術(shù)有初步的認(rèn)知。

通常情況下，通信過程需要具備以下四個(gè)特性，才能被認(rèn)為是安全的，分別是：機(jī)密性、完整性、身份認(rèn)證和不可否認(rèn)。

機(jī)密性

機(jī)密性是安全通信的基礎(chǔ)，缺少機(jī)密性任何竊聽通信的人都可以輕而易舉獲取到你的諸如登錄密碼、支付密碼等關(guān)鍵隱私信息。實(shí)現(xiàn)機(jī)密性最常用的手段就是加密，這樣竊聽者只能得到加密后的毫無意義的一串?dāng)?shù)據(jù)，只有持有密鑰的人才能將密文恢復(fù)成正確的原始信息。根據(jù)密鑰的使用方法，加密方式可以分為對(duì)稱加密和非對(duì)稱加密兩種。對(duì)稱加密是指加密和解密使用相同的密鑰，非對(duì)稱加密則是指加密和解密時(shí)使用不同的密鑰。

對(duì)稱加密由于通信雙方要使用相同的密鑰來進(jìn)行加解密，所以必然會(huì)遇到密鑰配送問題，即我需要對(duì)方能夠解密我發(fā)送過去的密文，我就必須把我加密時(shí)使用的密鑰告訴對(duì)方，但是我如何保證將密鑰與對(duì)方同步的過程中密鑰不會(huì)泄漏？這就是對(duì)稱加密的密鑰配送問題。

目前常用的解決方案是使用非對(duì)稱加密和使用 Diffie-Hellman 密鑰交換算法。非對(duì)稱加密的核心是生成一對(duì)密鑰，一個(gè)是公鑰，一個(gè)是私鑰，公鑰用于加密，它是公開的，可以派發(fā)給任何人使用，私鑰用于解密，不參與通信過程，需要被妥善保管，這樣就解決了密鑰配送問題。Diffie-Hellman 密鑰交換算法的核心思想則是通信雙方交換一些公開的信息就能夠計(jì)算出相同的共享密鑰，而竊聽者獲得這些公開信息卻無法計(jì)算出相同的密鑰。Diffie-Hellman 算法的一個(gè)好處是沒有非對(duì)稱加密的性能問題，非對(duì)稱加密雖然解決了密鑰配送問題，但非對(duì)稱加密算法的運(yùn)算速度遠(yuǎn)遠(yuǎn)不及對(duì)稱加密算法，它們甚至能有幾百倍的差距。雖然保障了安全，但嚴(yán)重影響了通信的效率，喪失了實(shí)用性。因此實(shí)際應(yīng)用時(shí)通常會(huì)將對(duì)稱加密和非對(duì)稱加密結(jié)合使用，即使用偽隨機(jī)數(shù)生成器生成會(huì)話密鑰后，用公鑰進(jìn)行加密并發(fā)送給對(duì)方，對(duì)方收到密文后使用私鑰解密取出會(huì)話密鑰，后續(xù)通信將完全使用該會(huì)話密鑰。這樣既解決了密鑰配送問題，又解決了非對(duì)稱加密帶來的性能問題，這種方式通常又被稱為混合加密。

完整性

僅僅具備機(jī)密性還不足以實(shí)現(xiàn)安全的通信，攻擊者依舊可以篡改、偽造密文內(nèi)容，而接收者既無法判斷密文是否來自正確的發(fā)送者，也無法判斷解密后的明文是否是未經(jīng)篡改的。盡管對(duì)加密之后的密文進(jìn)行針對(duì)性篡改的難度有所上升，例如篡改之后明文的數(shù)據(jù)結(jié)構(gòu)很有可能會(huì)遭到破壞，這種情況下接收者能夠很輕易地拒絕這個(gè)明文。但依然存在篡改之后正好使得解密得到的明文消息中某些本身就具備隨機(jī)屬性的字段的值發(fā)生變化的概率，例如電機(jī)轉(zhuǎn)速字段的值從 500 變?yōu)榱?718，無非是幾個(gè)比特位的變化，如果接收者正常接受這些消息，就可能帶來意想不到的隱患。

因此，我們還需要在機(jī)密性的基礎(chǔ)上進(jìn)一步保證信息的完整性。常見的做法就是使用單向散列函數(shù)計(jì)算消息的散列值，然后將消息和散列值一起發(fā)送給接收者。單向散列函數(shù)能夠確保消息中哪怕只有 1 比特的改變，也有很高的概率產(chǎn)生不同的散列值。這樣接收者就可以計(jì)算消息的散列值，然后對(duì)比收到的散列值來判斷數(shù)據(jù)是否被人篡改。

身份認(rèn)證

但可惜的是，當(dāng)攻擊者同時(shí)偽造消息和對(duì)應(yīng)的散列值時(shí)，接收者依然無法識(shí)破這個(gè)偽裝。因此我們不僅需要確認(rèn)消息的完整性，還需要確認(rèn)消息是否來自合法的發(fā)送者，也就是說還需要對(duì)身份進(jìn)行認(rèn)證。這個(gè)時(shí)候我們就需要用到消息認(rèn)證碼，消息認(rèn)證碼依然基于單向散列函數(shù)，但它的輸入除了原本的消息以外，還包括了一個(gè)發(fā)送者與接收者之間共享的密鑰。由于消息認(rèn)證碼本身并不提供消息機(jī)密性的保證，所以在實(shí)際使用中，通常會(huì)將對(duì)稱加密與消息認(rèn)證碼結(jié)合使用，以同時(shí)滿足機(jī)密性、完整性和認(rèn)證的要求，這種機(jī)制也被稱作認(rèn)證加密（AEAD）。具體怎么使用上，產(chǎn)生了以下幾種方案：

Encrypt and MAC：先用對(duì)稱密碼將明文加密，再計(jì)算明文的 MAC 值，最后把二者拼接起來發(fā)給接收方。

MAC then Encrypt：先計(jì)算明文的 MAC 值，然后將明文和 MAC 值同時(shí)用對(duì)稱密碼加密，加密后的密文發(fā)送給接收方。

Encrypt then MAC：先用對(duì)稱密碼將明文加密，再后計(jì)算密文的 MAC 值，最后把二者拼接起來發(fā)給接收方。

在很長(zhǎng)一段時(shí)間內(nèi)，SSL/TLS 都采用了第二種方案，但事實(shí)上以上三種方案都已經(jīng)陸續(xù)被驗(yàn)證為存在安全漏洞。SSL/TLS 歷史上的 POODLE 和 Lucky 13 攻擊都是針對(duì) MAC then Encrypt 方案中的漏洞實(shí)現(xiàn)的。目前業(yè)界推薦的安全方案是采用 AEAD 算法，SSL/TLS 1.3 版本中也正式廢除了其他加密方式，僅支持 AEAD 加密。

不可否認(rèn)

現(xiàn)在，我們已經(jīng)保證了消息的機(jī)密性，同時(shí)也能識(shí)別出偽裝和篡改，但是由于消息認(rèn)證碼的核心是需要通信雙方共享密鑰，因此又引發(fā)了新的問題，即無法對(duì)第三方證明以及無法防止否認(rèn)。假設(shè) Bob 接收了來自 Alice 的消息，想要向第三方證明這條消息的確是 Alice 發(fā)送的，就需要將原本只有兩個(gè)人知道的密鑰告訴給第三方，這顯然會(huì)增加后續(xù)繼續(xù)使用這個(gè)密鑰通信的安全風(fēng)險(xiǎn)。同時(shí)，即便第三方拿到了密鑰，也無法得出有效的結(jié)論，例如 Bob 可以宣稱這條消息是由 Alice 構(gòu)造的，因?yàn)?Alice 也持有相同的密鑰。

因此，我們還需要引入數(shù)字簽名機(jī)制，它的原理與非對(duì)稱機(jī)密很像，又正好相反。數(shù)字簽名需要發(fā)送者用私鑰對(duì)消息施加簽名，然后將消息與簽名一并發(fā)送給接收者，接收者則使用對(duì)應(yīng)的公鑰驗(yàn)證簽名，確認(rèn)簽名來自合法的發(fā)送者。由于只有持有私鑰的人才能施加正確的簽名，這樣發(fā)送者就無從否認(rèn)了。而公鑰只是用來驗(yàn)證簽名，所以可以隨意派發(fā)給任何人。可能敏感的讀者到這里心中已經(jīng)有些疑問了，是的，取到公鑰的人如何確認(rèn)這個(gè)公鑰的確來自自己期望的通信對(duì)象呢？如果攻擊者偽裝成發(fā)送者，并把自己的公鑰給了接收者，那么就能在無需破解數(shù)字簽名算法的前提下完成攻擊。

我們已經(jīng)陷入了一個(gè)死循環(huán)，數(shù)字簽名是用來用識(shí)別消息篡改、偽裝以及否認(rèn)的，但在此之前我們又必須從沒有被偽裝的發(fā)送者得到?jīng)]有被篡改的公鑰才行。到了這一步，我們只能借助外力的幫助了，委托公認(rèn)的可信第三方，也就是我們現(xiàn)在常說的認(rèn)證機(jī)構(gòu)或 CA，由它來給各個(gè)公鑰施加簽名，形成公鑰證書。顯而易見的是，認(rèn)證機(jī)構(gòu)需要努力確保自己的私鑰不被竊取，以保證數(shù)字簽名的有效性。雖然認(rèn)證機(jī)構(gòu)的私鑰依然有泄漏的概率，甚至認(rèn)證機(jī)構(gòu)本身也可能被攻擊者偽裝，我們依然無法獲得絕對(duì)的安全，但提前信任幾個(gè)已知的認(rèn)證機(jī)構(gòu)，總是比從全新的通信對(duì)象獲取并信任他的公鑰要可靠的多。

以上這些密碼技術(shù)，共同構(gòu)成了現(xiàn)代安全通信領(lǐng)域的基石。而 SSL/TLS 作為目前世界上應(yīng)用最廣泛的密碼通信方法，綜合運(yùn)用了前面提到的對(duì)稱加密、非對(duì)稱加密、消息認(rèn)證碼、數(shù)字簽名、偽隨機(jī)數(shù)生成器等密碼技術(shù)，來提供通信安全保障。考慮到密碼學(xué)技術(shù)是不斷進(jìn)步發(fā)展的，或者說目前看似可靠的加密算法，可能在第二天就會(huì)被宣告攻破，所以 SSL/TLS 并沒有強(qiáng)制使用某一種密碼技術(shù)，而是提供了密碼套件（Cipher Suite）這一機(jī)制，當(dāng)某項(xiàng)密碼技術(shù)被發(fā)現(xiàn)存在弱點(diǎn)，可以隨時(shí)像零件一樣替換它，當(dāng)然前提是客戶端和服務(wù)端使用相同的密碼技術(shù)。這也延伸出了 SSL/TLS 的握手協(xié)議，協(xié)商使用的密碼套件就是這一部分協(xié)議的主要工作之一。

想要 SSL/TLS 具備良好的安全性，就需要避免使用已經(jīng)被攻破或者已經(jīng)被驗(yàn)證為弱安全性的加密算法，要避免使用容易被預(yù)測(cè)的偽隨機(jī)數(shù)生成器，要盡量保證各個(gè)算法具有近似的安全性（短板效應(yīng)）。

因此，如何正確選擇密碼套件，也成為了保障安全性的一個(gè)重要環(huán)節(jié)。這里我也會(huì)對(duì)目前推薦的密碼技術(shù)和加密算法進(jìn)行一個(gè)簡(jiǎn)單的整理，希望可以幫助各位讀者查漏補(bǔ)缺：

對(duì)稱加密算法中 RC4、DES、3DES 都已經(jīng)被認(rèn)為是不安全的了，目前推薦使用的只有 AES 和 ChaCha20。ChaCha20 是 Google 設(shè)計(jì)的一種加密算法，如果 CPU 或軟件不支持 AES 指令集，ChaCha20 可提供比 AES 更好的性能。

AES 這類對(duì)稱加密算法只能加密固定長(zhǎng)度的明文，想要加密任意長(zhǎng)度的明文，還需要用到分組模式。早期的 ECB、CBC、CFB、OFB 等分組模式已經(jīng)被認(rèn)定為存在安全漏洞，目前更推薦使用 GCM、CCM 和 Poly1305。

常用的非對(duì)稱加密算法有 DH、RSA、ECC 這幾種。由于 DH 和 RSA 都不具備前向安全性，目前已經(jīng)不推薦使用，TLS 1.3 中更是直接廢除了 DH 和 RSA 算法，取而代之的是安全強(qiáng)度和性能都明顯優(yōu)于 RSA 的 ECC 算法，它有兩個(gè)子算法，ECDHE 用于密鑰交換，ECDSA 用于數(shù)字簽名。但需要注意的是，由于 ECDHE/DHE 不提供身份驗(yàn)證，因此服務(wù)端應(yīng)當(dāng)啟用對(duì)客戶端證書的驗(yàn)證。

散列算法方面，我們熟知的 MD5 和 SHA-1 都已經(jīng)被認(rèn)定為不再可靠，不推薦繼續(xù)使用。目前通常建議使用 SHA256 或更高版本。

在了解推薦使用的密碼技術(shù)以后，也許我們想要修改客戶端或服務(wù)端的密碼套件配置，但此時(shí)我們可能會(huì)發(fā)現(xiàn)這些密碼套件的名稱還有點(diǎn)難以理解。例如 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384，其中 TLS 只是表示協(xié)議，ECDHE 表示密鑰交換算法，ECDSA 表示身份認(rèn)證算法，AES_256_CBC 表示批量加密算法，SHA384 表示消息認(rèn)證碼 MAC 算法。這通常是 TLS 1.2 中密碼套件的命名格式，而到了 TLS 1.3 則又發(fā)生了一些變化。由于 TLS 1.3 只接受使用 ECDHE 算法進(jìn)行密鑰交換，并且使用 ECDSA 進(jìn)行身份認(rèn)證，因此它的密碼套件名稱可以精簡(jiǎn)成 TLS_AES_256_GCM_SHA384 這種格式。

如果僅從安全性角度出發(fā)，個(gè)人建議使用 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 和 TLS_AES_256_GCM_SHA384。但考慮到目前仍有很多以 RSA 方式簽發(fā)的證書正在使用，因此我們還需要根據(jù)自身情況來選擇是否要繼續(xù)使用 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384。

三、構(gòu)建安全認(rèn)證體系典型架構(gòu)

采用基于 PKI/CA 的數(shù)字證書體系是解決車聯(lián)網(wǎng)安全關(guān)鍵的一步，也是大多數(shù)車企典型安全管理體系。其主要的設(shè)計(jì)思路如下：

基于數(shù)字證書的身份標(biāo)識(shí)：通過 PKI/CA 系統(tǒng)建立嚴(yán)謹(jǐn)?shù)淖C書管理和使用規(guī)范，為車聯(lián)網(wǎng)的應(yīng)用和終端頒發(fā)數(shù)字證書，虛擬身份和真實(shí)身份進(jìn)行綁定，解決身份標(biāo)識(shí)和唯一性問題（可實(shí)現(xiàn)一機(jī)一密或一型一密）；

所有數(shù)據(jù)交互時(shí)通過終端的身份唯一標(biāo)識(shí)證明身份的真實(shí)性，防止第三方惡意入侵；

基于數(shù)字證書安全功能，提供身份鑒別、身份認(rèn)證、數(shù)據(jù)加解密、數(shù)字簽名與驗(yàn)簽等多種功能，滿足車聯(lián)網(wǎng)中 TSP、OTA 等多業(yè)務(wù)安全需求。

車聯(lián)網(wǎng)平臺(tái)安全通信交互流程，一般是將車機(jī)端申請(qǐng)終端證書，下載并完整安裝后通過 MQTTS 安全協(xié)議與云端平臺(tái)請(qǐng)求建立安全連接。在云端我們可以選擇在云廠商的負(fù)載均衡產(chǎn)品、基于 Nginx/HAProxy自行搭建的 LB 層或是 MQTT Broker 層進(jìn)行認(rèn)證鑒權(quán)，同時(shí)通過 proxy_protocol v2 將車機(jī)端的 ID 信息、用戶名密碼及證書的 CN/SN 等信息通過調(diào)用 PKI/CA 統(tǒng)一認(rèn)證接口進(jìn)行唯一性認(rèn)證，實(shí)現(xiàn)一機(jī)一密或一型一密的安全認(rèn)證。

四、 MQTTS 通信中單、雙向認(rèn)證配置方式

SSL/TLS 連接認(rèn)證認(rèn)證的是對(duì)方身份，是否是可信的通信對(duì)象，認(rèn)證的依據(jù)則是通信對(duì)象提供的證書。通常情況下是由客戶端對(duì)服務(wù)端的身份進(jìn)行認(rèn)證，也就是所謂的單向認(rèn)證。那么雙向認(rèn)證顧名思義就是在單向認(rèn)證的基礎(chǔ)上，服務(wù)端對(duì)客戶端的身份進(jìn)行認(rèn)證。

認(rèn)證的原理其實(shí)非常簡(jiǎn)單，以單向認(rèn)證為例，最簡(jiǎn)單的情況就是服務(wù)端在 SSL/TLS 握手階段發(fā)送服務(wù)端證書，客戶端驗(yàn)證該證書是否由受信任的 CA 機(jī)構(gòu)簽發(fā)，也就是使用受信任的 CA 證書中的公鑰來驗(yàn)證服務(wù)端證書中的數(shù)字簽名是否合法。當(dāng)然大部分情況會(huì)比這個(gè)稍微復(fù)雜一些，即服務(wù)端的證書不是由最頂層的 CA 機(jī)構(gòu)直接簽發(fā)的，而是由根 CA 機(jī)構(gòu)對(duì)下層 CA 機(jī)構(gòu)的公鑰施加數(shù)字簽名，形成中間 CA 證書，這樣的關(guān)系可能會(huì)多達(dá)幾層，以盡可能保護(hù)根證書的安全。大部分情況下常見 CA 機(jī)構(gòu)的根 CA 證書和中間 CA 證書都已經(jīng)內(nèi)置在我們的操作系統(tǒng)中了，只有少數(shù)情況下需要自行添加信任的 CA 證書。

多級(jí)證書或者說證書鏈的認(rèn)證過程會(huì)稍微復(fù)雜一些，但如果我們搞明白了前面說的證書簽發(fā)邏輯，其實(shí)理解起來也很簡(jiǎn)單。還是以單向認(rèn)證為例，如果客戶端只信任了根 CA 證書，那么服務(wù)端在握手階段就需要發(fā)送服務(wù)端證書和根 CA 證書到服務(wù)端證書之間的所有中間 CA 證書。只有客戶端拿到了完整的證書鏈，才能通過自己持有的根 CA 證書一層一層往下驗(yàn)證，缺少中間 CA 導(dǎo)致證書鏈不完整或者包含了錯(cuò)誤的中間 CA，都會(huì)導(dǎo)致信任鏈中斷而無法通過認(rèn)證。

如果客戶端除根 CA 證書以外，還持有一部分中間 CA 證書，那么在認(rèn)證過程中，服務(wù)端還可以省略這些中間 CA 證書的發(fā)送，來提高握手效率。

因此，當(dāng)我們配置單向認(rèn)證時(shí)，需要在服務(wù)端指定服務(wù)端證書和中間 CA 證書（可選），以及服務(wù)端私鑰文件?？蛻舳藙t需要信任相應(yīng)的根 CA 證書，信任的方式可以是在連接時(shí)指定或者通過證書管理工具將該根 CA 證書添加到信任列表。通?？蛻舳藥爝€提供了對(duì)端驗(yàn)證選項(xiàng)允許選擇是否驗(yàn)證證書，關(guān)閉對(duì)端驗(yàn)證將在不驗(yàn)證證書的情況下直接創(chuàng)建加密的 TLS 連接。但這會(huì)帶來中間人攻擊的安全風(fēng)險(xiǎn)，因此強(qiáng)烈建議啟用對(duì)端驗(yàn)證。

在啟用對(duì)端驗(yàn)證后，客戶端通常還會(huì)檢查服務(wù)器證書中的域名（SAN 字段或 CN 字段）與自己連接的服務(wù)器域名是否匹配。如果域名不匹配，則客戶端將拒絕對(duì)服務(wù)器進(jìn)行身份驗(yàn)證或建立連接。

雙向認(rèn)證的配置方式只需要在單向認(rèn)證的基礎(chǔ)上，在服務(wù)端啟用對(duì)端驗(yàn)證即表示啟用雙向認(rèn)證以外，再參考服務(wù)端證書的配置方式正確配置客戶端證書即可。

四、常見 TLS 選項(xiàng)介紹

當(dāng)使用 EMQX 配置 SSL/TLS 連接時(shí)，通常會(huì)有 certfile、keyfile等選項(xiàng)，為了幫助大家更好地了解這些選項(xiàng)的配置方式，接下來我們會(huì)對(duì)這些常見的 TLS 選項(xiàng)做一個(gè)簡(jiǎn)單的梳理和介紹：

certfile，用于指定服務(wù)端或客戶端證書和中間 CA 證書，需要指定多個(gè)證書時(shí)通常將它們簡(jiǎn)單地合并到一個(gè)證書文件中即可。

keyfile，用于指定服務(wù)端或客戶端私鑰文件。

cacertfile，用于指定 Root CA 證書，單向認(rèn)證時(shí)客戶端需要配置此選項(xiàng)以校驗(yàn)服務(wù)端證書，雙向認(rèn)證時(shí)服務(wù)端也需要配置此選項(xiàng)以校驗(yàn)客戶端證書。

verify，用于指定是否啟用對(duì)端驗(yàn)證。客戶端啟用對(duì)端驗(yàn)證后通常還會(huì)去檢查連接的服務(wù)器域名與服務(wù)器證書中的域名是否匹配?？蛻舳伺c服務(wù)端同時(shí)啟用則意味著這將是一個(gè)雙向認(rèn)證。

fail_if_no_peer_cert，這是一個(gè)服務(wù)端的選項(xiàng)，通常在服務(wù)端啟用對(duì)端驗(yàn)證時(shí)使用，設(shè)置為 false 表示允許客戶端不發(fā)送證書或發(fā)送空的證書，相當(dāng)于同時(shí)開啟單向認(rèn)證和雙向認(rèn)證，這會(huì)增加中間人攻擊的風(fēng)險(xiǎn)。

versions，指定支持的 TLS 版本。通信雙方會(huì)在握手過程中，將 versions 選項(xiàng)中指定的版本發(fā)送給對(duì)方，然后切換至雙方都支持的最高版本。同時(shí)也會(huì)基于該協(xié)議版本來協(xié)商密碼套件。

ciphers，指定支持的密碼套件。注意事項(xiàng)：避免使用前文提到的或其他被認(rèn)定為弱安全性的密碼套件，以及當(dāng)使用包含 ECDSA 簽名算法的密碼套件時(shí)，需要額外注意自己的證書是否為 ECC 類型。

server_name_indication，服務(wù)器名稱指示，這是一個(gè)客戶端的選項(xiàng)。通常在客戶端啟用對(duì)端驗(yàn)證且連接的服務(wù)器域名與服務(wù)器證書中的域名不匹配時(shí)使用。例如服務(wù)器證書中的域名為 abc.com，而客戶端連接的是 123.com，那么就需要客戶端在連接時(shí)指定 server_name_indication 為 abc.com 表示自己信任該域名以通過證書檢查。又或者將 server_name_indication 設(shè)置為 disable 來關(guān)閉此項(xiàng)檢查，但這會(huì)增加中間人攻擊的風(fēng)險(xiǎn)，通常并不建議這樣做。

示例

為了便于演示，我們會(huì)使用EMQX（4.3.0 版本及以上）作為服務(wù)端，在 EMQX 的控制臺(tái)中使用 Erlang 的 ssl:connect/3 函數(shù)作為客戶端。

單向認(rèn)證

修改 EMQ X 配置如下：

# 監(jiān)聽端口我們使用默認(rèn)的 8883listener.ssl.external = 8883# 服務(wù)端私鑰文件listener.ssl.external.keyfile = etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key# 證書捆綁包文件，包含了服務(wù)端證書和中間 CA 證書listener.ssl.external.certfile = etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt# 不開啟對(duì)端驗(yàn)證listener.ssl.external.verify = verify_none# 支持 TLS 1.2 和 TLS 1.3listener.ssl.tls_versions = tlsv1.3,tlsv1.2# 服務(wù)端支持的密碼套件listener.ssl.external.ciphers = TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_SHA256,TLS_AES_128_CCM_8_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

啟動(dòng) EMQ X 并進(jìn)入控制臺(tái)：

$ ./emqx console

使用 ssl:connect/3 函數(shù)連接：

%% 1. 指定用于驗(yàn)證服務(wù)端證書的 Root CA 證書%% 2. 啟用對(duì)端驗(yàn)證%% 3. 僅支持 TLS 1.2%% 4. 僅支持 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 這一個(gè)密碼套件ssl:connect("zhouzb.club", 8883, [{cacertfile, "etc/certs/zhouzb.club/DigiCertGlobalRootCA.crt.pem"},
                                  {verify, verify_peer},
                                  {versions, ['tlsv1.2']},
                                  {ciphers, ["TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"]}]).

雙向認(rèn)證

為了盡快進(jìn)入正題，這里將繼續(xù)使用服務(wù)端證書來充當(dāng)客戶端證書，這會(huì)有嚴(yán)重的安全隱患，在生產(chǎn)環(huán)境中請(qǐng)禁止這樣使用！

修改 EMQ X 配置如下：

# 監(jiān)聽端口我們使用默認(rèn)的 8883listener.ssl.external = 8883# 服務(wù)端私鑰文件listener.ssl.external.keyfile = etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key# 證書捆綁包文件，包含了服務(wù)端證書和中間 CA 證書listener.ssl.external.certfile = etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt# 指定用于驗(yàn)證客戶端證書的 Root CA 證書listener.ssl.external.cacertfile = etc/certs/zhouzb.club/DigiCertGlobalRootCA.crt.pem# 啟用對(duì)端驗(yàn)證listener.ssl.external.verify = verify_peer# 要求客戶端必須提供證書listener.ssl.external.fail_if_no_peer_cert = true# 支持 TLS 1.2 和 TLS 1.3listener.ssl.tls_versions = tlsv1.3,tlsv1.2# 服務(wù)端支持的密碼套件listener.ssl.external.ciphers = TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_SHA256,TLS_AES_128_CCM_8_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

啟動(dòng) EMQ X 并進(jìn)入控制臺(tái)，然后使用 ssl:connect/3 函數(shù)連接：

%% 1. 指定用于驗(yàn)證服務(wù)端證書的 Root CA 證書%% 2. 啟用對(duì)端驗(yàn)證%% 3. 僅支持 TLS 1.2%% 4. 僅支持 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 這一個(gè)密碼套件ssl:connect("zhouzb.club", 8883, [{cacertfile, "etc/certs/zhouzb.club/DigiCertGlobalRootCA.crt.pem"},
                                  {certfile, "etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt"},
                                  {keyfile, "etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key"},
                                  {verify, verify_peer},
                                  {versions, ['tlsv1.2']},
                                  {ciphers, ["TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"]}]).

六、總結(jié)

本文工業(yè)和信息化部印發(fā)的《車聯(lián)網(wǎng)網(wǎng)絡(luò)安全和數(shù)據(jù)安全標(biāo)準(zhǔn)系統(tǒng)建設(shè)指南》中明確指出，要構(gòu)建車聯(lián)網(wǎng)網(wǎng)絡(luò)安全和數(shù)據(jù)安全的標(biāo)準(zhǔn)體系。車聯(lián)網(wǎng)領(lǐng)域的網(wǎng)絡(luò)通信安全和數(shù)據(jù)安全將受到越來越多的關(guān)注，是車聯(lián)網(wǎng)企業(yè)提高競(jìng)爭(zhēng)力的關(guān)鍵影響因素之一。希望通過本文，讀者可以掌握 SSL/TLS 協(xié)議的使用方式，在實(shí)際業(yè)務(wù)場(chǎng)景中正確應(yīng)用，實(shí)現(xiàn)車聯(lián)網(wǎng)通信安全保障。

來源：汽車電子電氣架構(gòu)創(chuàng)新發(fā)展論壇