## 前言

在汽車出行愈加智慧化的今天，我們可以實現手機遠端操控車輛解鎖、啟動通風、檢視車輛周圍影像，也可以透過 OTA（空中下載技術）完成升級車機韌體、更新地圖包等操作，自動駕駛技術更是可以讓車輛根據路面狀況自動輔助實施轉向、加速和制動。

然而，每項提升我們使用體驗的功能，都有可能成為致命的安全漏洞。騰訊安全科恩實驗室曾向外界披露並演示過如何憑藉 3/4G 網路或者 WiFi 網路，在遠端無物理接觸的情況下入侵智慧汽車，實現對車輛訊號燈、螢幕、門鎖甚至是剎車的遠端控制。不僅如此，攻擊者甚至可以利用某個已知漏洞獲取智慧汽車的 Autopilot 控制權，對車輛行駛方向進行操控。

因此，我們在車聯網平臺構建時也應充分認識到通訊安全、身份認證、資料安全的重要性，正確使用相關加密認證等技術手段來提供保障。

本篇文章我們將全面介紹 SSL/TLS 協議在車聯網通訊安全中的應用，希望能讓大家對 SSL/TLS 的作用有更清晰直觀的認識。此外，我們還將詳細講解 SSL/TLS 的配置方式，確保大家能正確使用 SSL/TLS，實現安全性保障。

## 車聯網安全通訊 MQTTS 協議

MQTTS 協議是在 [MQTT 協議](https://www.emqx.com/zh/mqtt)的基礎上，封裝了一層基於 SSL/TLS（*傳輸層安全）*的加密協議， 它確保車機端和車聯網平臺通訊是加密的。但如果沒有正確配置 SSL/TLS，依然會存在很多安全隱患。想要真正運用好 SSL/TLS，我們必須瞭解 SSL/TLS 解決了哪些問題，以及對 SSL/TLS 用到的密碼技術有初步的認知。

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

### 機密性

機密性是安全通訊的基礎，缺少機密性任何竊聽通訊的人都可以輕而易舉獲取到你的諸如登入密碼、支付密碼等關鍵隱私資訊。實現機密性最常用的手段就是加密，這樣竊聽者只能得到加密後的毫無意義的一串資料，只有持有金鑰的人才能將密文恢復成正確的原始資訊。根據金鑰的使用方法，加密方式可以分為對稱加密和非對稱加密兩種。對稱加密是指加密和解密使用相同的金鑰，非對稱加密則是指加密和解密時使用不同的金鑰。

對稱加密由於通訊雙方要使用相同的金鑰來進行加解密，所以必然會遇到金鑰配送問題，即我需要對方能夠解密我傳送過去的密文，我就必須把我加密時使用的金鑰告訴對方，但是我如何保證將金鑰與對方同步的過程中金鑰不會洩漏？這就是對稱加密的金鑰配送問題。

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

### 完整性

僅僅具備機密性還不足以實現安全的通訊，攻擊者依舊可以篡改、偽造密文內容，而接收者既無法判斷密文是否來自正確的傳送者，也無法判斷解密後的明文是否是未經篡改的。儘管對加密之後的密文進行針對性篡改的難度有所上升，例如篡改之後明文的資料結構很有可能會遭到破壞，這種情況下接收者能夠很輕易地拒絕這個明文。但依然存在篡改之後正好使得解密得到的明文訊息中某些本身就具備隨機屬性的欄位的值發生變化的機率，例如電機轉速欄位的值從 500 變為了 718，無非是幾個位元位的變化，如果接收者正常接受這些訊息，就可能帶來意想不到的隱患。

因此，我們還需要在機密性的基礎上進一步保證資訊的完整性。常見的做法就是使用單向雜湊函式計算訊息的雜湊值，然後將訊息和雜湊值一起傳送給接收者。單向雜湊函式能夠確保訊息中哪怕只有 1 位元的改變，也有很高的機率產生不同的雜湊值。這樣接收者就可以計算訊息的雜湊值，然後對比收到的雜湊值來判斷資料是否被人篡改。

### 身份認證

但可惜的是，當攻擊者同時偽造訊息和對應的雜湊值時，接收者依然無法識破這個偽裝。因此我們不僅需要確認訊息的完整性，還需要確認訊息是否來自合法的傳送者，也就是說還需要對身份進行認證。這個時候我們就需要用到訊息認證碼，訊息認證碼依然基於單向雜湊函式，但它的輸入除了原本的訊息以外，還包括了一個傳送者與接收者之間共享的金鑰。由於訊息認證碼本身並不提供訊息機密性的保證，所以在實際使用中，通常會將對稱加密與訊息認證碼結合使用，以同時滿足機密性、完整性和認證的要求，這種機制也被稱作認證加密（AEAD）。具體怎麼使用上，產生了以下幾種方案：

1. Encrypt and MAC：先用對稱密碼將明文加密，再計算明文的 MAC 值，最後把二者拼接起來發給接收方。
2. MAC then Encrypt：先計算明文的 MAC 值，然後將明文和 MAC 值同時用對稱密碼加密，加密後的密文傳送給接收方。
3. Encrypt then MAC：先用對稱密碼將明文加密，再後計算密文的 MAC 值，最後把二者拼接起來發給接收方。

在很長一段時間內，SSL/TLS 都採用了第二種方案，但事實上以上三種方案都已經陸續被驗證為存在安全漏洞。SSL/TLS 歷史上的 POODLE 和 Lucky 13 攻擊都是針對 MAC then Encrypt 方案中的漏洞實現的。目前業界推薦的安全方案是採用 AEAD 演算法，SSL/TLS 1.3 版本中也正式廢除了其他加密方式，僅支援 AEAD 加密。

### 不可否認

現在，我們已經保證了訊息的機密性，同時也能識別出偽裝和篡改，但是由於訊息認證碼的核心是需要通訊雙方共享金鑰，因此又引發了新的問題，即無法對第三方證明以及無法防止否認。假設 Bob 接收了來自 Alice 的訊息，想要向第三方證明這條訊息的確是 Alice 傳送的，就需要將原本只有兩個人知道的金鑰告訴給第三方，這顯然會增加後續繼續使用這個金鑰通訊的安全風險。同時，即便第三方拿到了金鑰，也無法得出有效的結論，例如 Bob 可以宣稱這條訊息是由 Alice 構造的，因為 Alice 也持有相同的金鑰。

因此，我們還需要引入數字簽名機制，它的原理與非對稱機密很像，又正好相反。數字簽名需要傳送者用私鑰對訊息施加簽名，然後將訊息與簽名一併傳送給接收者，接收者則使用對應的公鑰驗證簽名，確認簽名來自合法的傳送者。由於只有持有私鑰的人才能施加正確的簽名，這樣傳送者就無從否認了。而公鑰只是用來驗證簽名，所以可以隨意派發給任何人。可能敏感的讀者到這裡心中已經有些疑問了，是的，取到公鑰的人如何確認這個公鑰的確來自自己期望的通訊物件呢？如果攻擊者偽裝成傳送者，並把自己的公鑰給了接收者，那麼就能在無需破解數字簽名演算法的前提下完成攻擊。

我們已經陷入了一個死迴圈，數字簽名是用來用識別訊息篡改、偽裝以及否認的，但在此之前我們又必須從沒有被偽裝的傳送者得到沒有被篡改的公鑰才行。到了這一步，我們只能藉助外力的幫助了，委託公認的可信第三方，也就是我們現在常說的認證機構或 CA，由它來給各個公鑰施加簽名，形成公鑰證書。顯而易見的是，認證機構需要努力確保自己的私鑰不被竊取，以保證數字簽名的有效性。雖然認證機構的私鑰依然有洩漏的機率，甚至認證機構本身也可能被攻擊者偽裝，我們依然無法獲得絕對的安全，但提前信任幾個已知的認證機構，總是比從全新的通訊物件獲取並信任他的公鑰要可靠的多。

以上這些密碼技術，共同構成了現代安全通訊領域的基石。而 SSL/TLS 作為目前世界上應用最廣泛的密碼通訊方法，綜合運用了前面提到的對稱加密、非對稱加密、訊息認證碼、數字簽名、偽隨機數生成器等密碼技術，來提供通訊安全保障。考慮到密碼學技術是不斷進步發展的，或者說目前看似可靠的加密演算法，可能在第二天就會被宣告攻破，所以 SSL/TLS 並沒有強制使用某一種密碼技術，而是提供了密碼套件（Cipher Suite）這一機制，當某項密碼技術被發現存在弱點，可以隨時像零件一樣替換它，當然前提是客戶端和服務端使用相同的密碼技術。這也延伸出了 SSL/TLS 的握手協議，協商使用的密碼套件就是這一部分協議的主要工作之一。

想要 SSL/TLS 具備良好的安全性，就需要避免使用已經被攻破或者已經被驗證為弱安全性的加密演算法，要避免使用容易被預測的偽隨機數生成器，要儘量保證各個演算法具有近似的安全性（短板效應）。

因此，如何正確選擇密碼套件，也成為了保障安全性的一個重要環節。這裡我也會對目前推薦的密碼技術和加密演算法進行一個簡單的整理，希望可以幫助各位讀者查漏補缺：

- 對稱加密演算法中 RC4、DES、3DES 都已經被認為是不安全的了，目前推薦使用的只有 AES 和 ChaCha20。ChaCha20 是 Google 設計的一種加密演算法，如果 CPU 或軟體不支援 AES 指令集，ChaCha20 可提供比 AES 更好的效能。
- AES 這類對稱加密演算法只能加密固定長度的明文，想要加密任意長度的明文，還需要用到分組模式。早期的 ECB、CBC、CFB、OFB 等分組模式已經被認定為存在安全漏洞，目前更推薦使用 GCM、CCM 和 Poly1305。
- 常用的非對稱加密演算法有 DH、RSA、ECC 這幾種。由於 DH 和 RSA 都不具備前向安全性，目前已經不推薦使用，TLS 1.3 中更是直接廢除了 DH 和 RSA 演算法，取而代之的是安全強度和效能都明顯優於 RSA 的 ECC 演算法，它有兩個子演算法，ECDHE 用於金鑰交換，ECDSA 用於數字簽名。但需要注意的是，由於 ECDHE/DHE 不提供身份驗證，因此服務端應當啟用對客戶端證書的驗證。
- 雜湊演算法方面，我們熟知的 MD5 和 SHA-1 都已經被認定為不再可靠，不推薦繼續使用。目前通常建議使用 SHA256 或更高版本。

在瞭解推薦使用的密碼技術以後，也許我們想要修改客戶端或服務端的密碼套件配置，但此時我們可能會發現這些密碼套件的名稱還有點難以理解。例如 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384，其中 TLS 只是表示協議，ECDHE 表示金鑰交換演算法，ECDSA 表示身份認證演算法，AES_256_CBC 表示批次加密演算法，SHA384 表示訊息認證碼 MAC 演算法。這通常是 TLS 1.2 中密碼套件的命名格式，而到了 TLS 1.3 則又發生了一些變化。由於 TLS 1.3 只接受使用 ECDHE 演算法進行金鑰交換，並且使用 ECDSA 進行身份認證，因此它的密碼套件名稱可以精簡成 TLS_AES_256_GCM_SHA384 這種格式。

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

## 構建安全認證體系典型架構

採用基於 PKI/CA 的數字證書體系是解決車聯網安全關鍵的一步，也是大多數車企典型安全管理體系。其主要的設計思路如下：

1. 基於數字證書的身份標識：透過 PKI/CA 系統建立嚴謹的證書管理和使用規範，為車聯網的應用和終端頒發數字證書，虛擬身份和真實身份進行繫結，解決身份標識和唯一性問題（可實現一機一密或一型一密）；
2. 所有資料互動時透過終端的身份唯一標識證明身份的真實性，防止第三方惡意入侵；
3. 基於數字證書安全功能，提供身份鑑別、身份認證、資料加解密、數字簽名與驗籤等多種功能，滿足車聯網中 TSP、OTA 等多業務安全需求。

[![車聯網安全](http://img.blog.itpub.net/blog/2022/04/15/10a15508ac598aaa.png?x-oss-process=style/bb "車聯網安全")](https://www.emqx.com/zh/blog/ssl-tls-for-internet-of-vehicles-communication-security "車聯網安全")

車聯網平臺安全通訊互動流程，一般是將車機端申請終端證書，下載並完整安裝後透過 MQTTS 安全協議與雲端平臺請求建立安全連線。在雲端我們可以選擇在雲廠商的負載均衡產品、基於 Nginx/HAProxy 自行搭建的 LB 層或是 MQTT Broker 層進行認證鑑權，同時透過 proxy_protocol v2 將車機端的 ID 資訊、使用者名稱密碼及證書的 CN/SN 等資訊透過呼叫 PKI/CA 統一認證介面進行唯一性認證，實現一機一密或一型一密的安全認證。

## MQTTS 通訊中單、雙向認證的配置方式

SSL/TLS 連線認證認證的是對方身份，是否是可信的通訊物件，認證的依據則是通訊物件提供的證書。通常情況下是由客戶端對服務端的身份進行認證，也就是所謂的單向認證。那麼雙向認證顧名思義就是在單向認證的基礎上，服務端對客戶端的身份進行認證。

認證的原理其實非常簡單，以單向認證為例，最簡單的情況就是服務端在 SSL/TLS 握手階段傳送服務端證書，客戶端驗證該證書是否由受信任的 CA 機構簽發，也就是使用受信任的 CA 證書中的公鑰來驗證服務端證書中的數字簽名是否合法。當然大部分情況會比這個稍微複雜一些，即服務端的證書不是由最頂層的 CA 機構直接簽發的，而是由根 CA 機構對下層 CA 機構的公鑰施加數字簽名，形成中間 CA 證書，這樣的關係可能會多達幾層，以儘可能保護根證書的安全。大部分情況下常見 CA 機構的根 CA 證書和中間 CA 證書都已經內建在我們的作業系統中了，只有少數情況下需要自行新增信任的 CA 證書。

多級證書或者說證書鏈的認證過程會稍微複雜一些，但如果我們搞明白了前面說的證書籤發邏輯，其實理解起來也很簡單。還是以單向認證為例，如果客戶端只信任了根 CA 證書，那麼服務端在握手階段就需要傳送服務端證書和根 CA 證書到服務端證書之間的所有中間 CA 證書。只有客戶端拿到了完整的證書鏈，才能透過自己持有的根 CA 證書一層一層往下驗證，缺少中間 CA 導致證書鏈不完整或者包含了錯誤的中間 CA，都會導致信任鏈中斷而無法透過認證。

如果客戶端除根 CA 證書以外，還持有一部分中間 CA 證書，那麼在認證過程中，服務端還可以省略這些中間 CA 證書的傳送，來提高握手效率。

因此，當我們配置單向認證時，需要在服務端指定服務端證書和中間 CA 證書（可選），以及服務端私鑰檔案。客戶端則需要信任相應的根 CA 證書，信任的方式可以是在連線時指定或者透過證書管理工具將該根 CA 證書新增到信任列表。通常客戶端庫還提供了對端驗證選項允許選擇是否驗證證書，關閉對端驗證將在不驗證證書的情況下直接建立加密的 TLS 連線。但這會帶來中間人攻擊的安全風險，因此強烈建議啟用對端驗證。

在啟用對端驗證後，客戶端通常還會檢查伺服器證書中的域名（SAN 欄位或 CN 欄位）與自己連線的伺服器域名是否匹配。如果域名不匹配，則客戶端將拒絕對伺服器進行身份驗證或建立連線。

雙向認證的配置方式只需要在單向認證的基礎上，在服務端啟用對端驗證即表示啟用雙向認證以外，再參考服務端證書的配置方式正確配置客戶端證書即可。

## 常見 TLS 選項介紹

當使用 EMQX 配置 SSL/TLS 連線時，通常會有 certfile、keyfile 等選項，為了幫助大家更好地瞭解這些選項的配置方式，接下來我們會對這些常見的 TLS 選項做一個簡單的梳理和介紹：

- certfile，用於指定服務端或客戶端證書和中間 CA 證書，需要指定多個證書時通常將它們簡單地合併到一個證書檔案中即可。
- keyfile，用於指定服務端或客戶端私鑰檔案。
- cacertfile，用於指定 Root CA 證書，單向認證時客戶端需要配置此選項以校驗服務端證書，雙向認證時服務端也需要配置此選項以校驗客戶端證書。
- verify，用於指定是否啟用對端驗證。客戶端啟用對端驗證後通常還會去檢查連線的伺服器域名與伺服器證書中的域名是否匹配。客戶端與服務端同時啟用則意味著這將是一個雙向認證。
- fail_if_no_peer_cert，這是一個服務端的選項，通常在服務端啟用對端驗證時使用，設定為 false 表示允許客戶端不傳送證書或傳送空的證書，相當於同時開啟單向認證和雙向認證，這會增加中間人攻擊的風險。
- versions，指定支援的 TLS 版本。通訊雙方會在握手過程中，將 versions 選項中指定的版本傳送給對方，然後切換至雙方都支援的最高版本。同時也會基於該協議版本來協商密碼套件。
- ciphers，指定支援的密碼套件。注意事項：避免使用前文提到的或其他被認定為弱安全性的密碼套件，以及當使用包含 ECDSA 簽名演算法的密碼套件時，需要額外注意自己的證書是否為 ECC 型別。
- server_name_indication，伺服器名稱指示，這是一個客戶端的選項。通常在客戶端啟用對端驗證且連線的伺服器域名與伺服器證書中的域名不匹配時使用。例如伺服器證書中的域名為 abc.com，而客戶端連線的是 123.com，那麼就需要客戶端在連線時指定 server_name_indication 為 abc.com 表示自己信任該域名以透過證書檢查。又或者將 server_name_indication 設定為 disable 來關閉此項檢查，但這會增加中間人攻擊的風險，通常並不建議這樣做。

### 示例

為了便於演示，我們會使用 [EMQX](https://github.com/emqx/emqx) （4.3.0 版本及以上）作為服務端，在 EMQX 的控制檯中使用 Erlang 的 ssl:connect/3 函式作為客戶端。

#### 單向認證

修改 EMQ X 配置如下：

監聽埠我們使用預設的 8883
```ini
listener.ssl.external = 8883
```
服務端私鑰檔案
```ini
listener.ssl.external.keyfile = etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key
```
證書捆綁包檔案，包含了服務端證書和中間 CA 證書
```ini
listener.ssl.external.certfile = etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt
```
不開啟對端驗證
```ini
listener.ssl.external.verify = verify_none
```
支援 TLS 1.2 和 TLS 1.3
```ini
listener.ssl.tls_versions = tlsv1.3,tlsv1.2
```
服務端支援的密碼套件
```ini
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
```

啟動 EMQ X 並進入控制檯：

```shell
$ ./emqx console
```

使用 ssl:connect/3 函式連線：

```prolog
%% 1. 指定用於驗證服務端證書的 Root CA 證書
%% 2. 啟用對端驗證
%% 3. 僅支援 TLS 1.2
%% 4. 僅支援 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 這一個密碼套件
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"]}]).
```

#### 雙向認證

為了儘快進入正題，這裡將繼續使用服務端證書來充當客戶端證書，這會有嚴重的安全隱患，在生產環境中請禁止這樣使用！

修改 EMQ X 配置如下：

監聽埠我們使用預設的 8883
```ini
listener.ssl.external = 8883
```
服務端私鑰檔案
```ini
listener.ssl.external.keyfile = etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key
```
證書捆綁包檔案，包含了服務端證書和中間 CA 證書
```ini
listener.ssl.external.certfile = etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt
```
指定用於驗證客戶端證書的 Root CA 證書
```ini
listener.ssl.external.cacertfile = etc/certs/zhouzb.club/DigiCertGlobalRootCA.crt.pem
```
啟用對端驗證
```ini
listener.ssl.external.verify = verify_peer
```
要求客戶端必須提供證書
```ini
listener.ssl.external.fail_if_no_peer_cert = true
```
支援 TLS 1.2 和 TLS 1.3
```ini
listener.ssl.tls_versions = tlsv1.3,tlsv1.2
```
服務端支援的密碼套件
```ini
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
```

啟動 EMQ X 並進入控制檯，然後使用 ssl:connect/3 函式連線：

```prolog
%% 1. 指定用於驗證服務端證書的 Root CA 證書
%% 2. 啟用對端驗證
%% 3. 僅支援 TLS 1.2
%% 4. 僅支援 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 這一個密碼套件
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"]}]).
```

## 結語

工業和資訊化部印發的《車聯網網路安全和資料安全標準系統建設指南》中明確指出，要構建車聯網網路安全和資料安全的標準體系。車聯網領域的網路通訊安全和資料安全將受到越來越多的關注，是車聯網企業提高競爭力的關鍵影響因素之一。希望透過本文，讀者可以掌握 SSL/TLS 協議的使用方式，在實際業務場景中正確應用，實現車聯網通訊安全保障。

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/ssl-tls-for-internet-of-vehicles-communication-security](https://www.emqx.com/zh/blog/ssl-tls-for-internet-of-vehicles-communication-security)

車聯網通訊安全之 SSL/TLS 協議

相關文章