avant-propos
Dans les déplacements en voiture de plus en plus intelligents d'aujourd'hui, nous pouvons réaliser la télécommande du téléphone portable pour déverrouiller le véhicule, démarrer la ventilation et afficher les images autour du véhicule. Nous pouvons également utiliser l'OTA (technologie de téléchargement en direct) pour opérations complètes telles que la mise à jour du micrologiciel de la voiture et la mise à jour du package cartographique.Il permet également au véhicule d'assister automatiquement la direction, l'accélération et le freinage en fonction des conditions de la route.
Cependant, chaque fonctionnalité qui améliore notre expérience a le potentiel de devenir une faille de sécurité fatale. Tencent Security Cohen Lab a révélé et démontré au monde extérieur comment utiliser le réseau 3/4G ou le réseau WiFi pour envahir les voitures intelligentes sans contact physique à distance et réaliser le contrôle à distance des feux, des écrans, des serrures de porte et même des freins du véhicule. De plus, les attaquants peuvent même exploiter une vulnérabilité connue pour prendre le contrôle du pilote automatique d'une voiture intelligente et manipuler la direction du véhicule.
Par conséquent, nous devons également reconnaître pleinement l'importance de la sécurité des communications, de l'authentification de l'identité et de la sécurité des données lors de la construction de la plate-forme Internet des véhicules, et utiliser correctement l'authentification par cryptage appropriée et d'autres moyens techniques pour assurer la protection.
Dans cet article, nous présenterons en détail l'application du protocole SSL/TLS dans la sécurité des communications de l'Internet des véhicules, en espérant donner à chacun une compréhension plus claire et intuitive du rôle de SSL/TLS. De plus, nous expliquerons également en détail comment configurer SSL/TLS pour vous assurer que vous pouvez utiliser correctement SSL/TLS et assurer la sécurité.
Protocole MQTTS de communication de sécurité de l'Internet des véhicules
Le protocole MQTTS est basé sur le protocole MQTT et encapsule une couche de protocole de cryptage basée sur SSL/TLS (*Transport Layer Security)*, qui garantit que la communication entre le terminal du véhicule et la plate-forme de mise en réseau du véhicule est cryptée. Cependant, si SSL/TLS n'est pas correctement configuré, il y aura toujours de nombreux risques de sécurité. Pour vraiment bien utiliser SSL/TLS, nous devons comprendre les problèmes que SSL/TLS résout et avoir une compréhension préliminaire des techniques cryptographiques utilisées par SSL/TLS.
En règle générale, un processus de communication doit avoir les quatre propriétés suivantes pour être considéré comme sécurisé : confidentialité, intégrité, authentification et non-répudiation.
confidentialité
La confidentialité est le fondement d'une communication sécurisée. Sans confidentialité, toute personne qui écoute la communication peut facilement obtenir vos informations privées clés telles que le mot de passe de connexion et le mot de passe de paiement. La méthode la plus courante pour assurer la confidentialité est le cryptage, de sorte que l'espion ne peut obtenir qu'une chaîne de données cryptées sans signification, et seule la personne qui détient la clé peut restaurer le texte chiffré avec les informations d'origine correctes. Selon la méthode d'utilisation de la clé, les méthodes de chiffrement peuvent être divisées en deux types : le chiffrement symétrique et le chiffrement asymétrique. Le chiffrement symétrique consiste à utiliser la même clé pour le chiffrement et le déchiffrement, tandis que le chiffrement asymétrique consiste à utiliser des clés différentes pour le chiffrement et le déchiffrement.
Cryptage symétrique Étant donné que les deux parties utilisent la même clé pour le cryptage et le décryptage, elles rencontreront inévitablement le problème de la distribution de la clé, c'est-à-dire que si j'ai besoin que l'autre partie puisse décrypter le texte chiffré que j'ai envoyé dans le passé, je dois utiliser le clé que j'ai utilisée pour le chiffrement. dites-le à l'autre partie, mais comment puis-je m'assurer que la clé n'est pas divulguée lors de la synchronisation de la clé avec l'autre partie ? C'est le problème de la distribution des clés pour le chiffrement symétrique.
Une solution courante aujourd'hui consiste à utiliser le chiffrement asymétrique et à utiliser l'algorithme d'échange de clés Diffie-Hellman. Le cœur du chiffrement asymétrique consiste à générer une paire de clés, l'une est la clé publique et l'autre est la clé privée. La clé publique est utilisée pour le chiffrement. Elle est publique et peut être distribuée à n'importe qui. La clé privée est utilisée pour déchiffrement et ne participe pas au processus de communication. , qui doit être correctement conservé, résolvant ainsi le problème de distribution des clés. L'idée centrale de l'algorithme d'échange de clés Diffie-Hellman est que les deux parties communicantes peuvent calculer la même clé partagée en échangeant certaines informations publiques, mais l'espion ne peut pas calculer la même clé après avoir obtenu les informations publiques. L'un des avantages de l'algorithme Diffie-Hellman est qu'il n'y a pas de problème de performance lié au chiffrement asymétrique. Bien que le chiffrement asymétrique résolve le problème de la distribution des clés, la vitesse de fonctionnement des algorithmes de chiffrement asymétrique est bien inférieure à celle des algorithmes de chiffrement symétrique, et ils peuvent même être des centaines de fois plus rapide. Bien que la sécurité soit assurée, elle affecte sérieusement l'efficacité de la communication et perd en praticabilité. Par conséquent, dans les applications pratiques, le chiffrement symétrique et le chiffrement asymétrique sont généralement utilisés en combinaison, c'est-à-dire qu'après avoir utilisé un générateur de nombres pseudo-aléatoires pour générer une clé de session, la chiffrer avec la clé publique et l'envoyer à l'autre partie. clé, qui sera utilisée exclusivement pour les communications ultérieures. Cela résout non seulement le problème de distribution des clés, mais résout également le problème de performances causé par le chiffrement asymétrique, souvent appelé chiffrement hybride.
intégrité
仅仅具备机密性还不足以实现安全的通信，攻击者依旧可以篡改、伪造密文内容，而接收者既无法判断密文是否来自正确的发送者，也无法判断解密后的明文是否是未经篡改的。尽管对加密之后的密文进行针对性篡改的难度有所上升，例如篡改之后明文的数据结构很有可能会遭到破坏，这种情况下接收者能够很轻易地拒绝这个明文。但依然存在篡改之后正好使得解密得到的明文消息中某些本身就具备随机属性的字段的值发生变化的概率，例如电机转速字段的值从 500 变为了 718，无非是几个比特位的变化，如果接收者正常接受这些消息，就可能带来意想不到的隐患。
因此，我们还需要在机密性的基础上进一步保证信息的完整性。常见的做法就是使用单向散列函数计算消息的散列值，然后将消息和散列值一起发送给接收者。单向散列函数能够确保消息中哪怕只有 1 比特的改变，也有很高的概率产生不同的散列值。这样接收者就可以计算消息的散列值，然后对比收到的散列值来判断数据是否被人篡改。
身份认证
但可惜的是，当攻击者同时伪造消息和对应的散列值时，接收者依然无法识破这个伪装。因此我们不仅需要确认消息的完整性，还需要确认消息是否来自合法的发送者，也就是说还需要对身份进行认证。这个时候我们就需要用到消息认证码，消息认证码依然基于单向散列函数，但它的输入除了原本的消息以外，还包括了一个发送者与接收者之间共享的密钥。由于消息认证码本身并不提供消息机密性的保证，所以在实际使用中，通常会将对称加密与消息认证码结合使用，以同时满足机密性、完整性和认证的要求，这种机制也被称作认证加密（AEAD）。具体怎么使用上，产生了以下几种方案：
- Encrypt and MAC：先用对称密码将明文加密，再计算明文的 MAC 值，最后把二者拼接起来发给接收方。
- MAC then Encrypt：先计算明文的 MAC 值，然后将明文和 MAC 值同时用对称密码加密，加密后的密文发送给接收方。
- 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 的数字证书体系是解决车联网安全关键的一步，也是大多数车企典型安全管理体系。其主要的设计思路如下：
- 基于数字证书的身份标识：通过 PKI/CA 系统建立严谨的证书管理和使用规范，为车联网的应用和终端颁发数字证书，虚拟身份和真实身份进行绑定，解决身份标识和唯一性问题（可实现一机一密或一型一密）；
- 所有数据交互时通过终端的身份唯一标识证明身份的真实性，防止第三方恶意入侵；
- 基于数字证书安全功能，提供身份鉴别、身份认证、数据加解密、数字签名与验签等多种功能，满足车联网中 TSP、OTA 等多业务安全需求。
车联网平台安全通信交互流程，一般是将车机端申请终端证书，下载并完整安装后通过 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, l'indication du nom du serveur, c'est une option côté client. Généralement utilisé lorsque l'authentification peer-to-peer est activée sur le client et que le nom de domaine du serveur connecté ne correspond pas au nom de domaine dans le certificat du serveur. Par exemple, le nom de domaine dans le certificat du serveur est abc.com et le client se connecte à 123.com, puis le client doit spécifier server_name_indication comme abc.com lors de la connexion pour indiquer qu'il fait confiance au nom de domaine pour réussir la vérification du certificat . Vous pouvez également définir server_name_indication sur disable pour désactiver cette vérification, mais cela augmente le risque d'attaques de type man-in-the-middle et n'est généralement pas recommandé.
Exemple
Pour faciliter la démonstration, nous utiliserons EMQX (version 4.3.0 et supérieure) comme serveur et utiliserons la fonction ssl:connect/3 d'Erlang comme client dans la console EMQX.
Authentification unidirectionnelle
Modifiez la configuration EMQ X comme suit :
# 监听端口我们使用默认的 8883
listener.ssl.external = 8883
# 服务端私钥文件
listener.ssl.external.keyfile = etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key
# 证书捆绑包文件，包含了服务端证书和中间 CA 证书
listener.ssl.external.certfile = etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt
# 不开启对端验证
listener.ssl.external.verify = verify_none
# 支持 TLS 1.2 和 TLS 1.3
listener.ssl.tls_versions = tlsv1.3,tlsv1.2
# 服务端支持的密码套件
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émarrez EMQ X et accédez à la console :
$ ./emqx console
复制代码Pour se connecter à l'aide de la fonction ssl:connect/3 :
%% 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"]}]).
复制代码Authentification bidirectionnelle
Afin d'en venir au fait le plus rapidement possible, le certificat serveur continuera à être utilisé comme certificat client, ce qui présentera de sérieux risques de sécurité. Veuillez interdire une telle utilisation dans l'environnement de production !
Modifiez la configuration EMQ X comme suit :
# 监听端口我们使用默认的 8883
listener.ssl.external = 8883
# 服务端私钥文件
listener.ssl.external.keyfile = etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key
# 证书捆绑包文件，包含了服务端证书和中间 CA 证书
listener.ssl.external.certfile = etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt
# 指定用于验证客户端证书的 Root CA 证书
listener.ssl.external.cacertfile = etc/certs/zhouzb.club/DigiCertGlobalRootCA.crt.pem
# 启用对端验证
listener.ssl.external.verify = verify_peer
# 要求客户端必须提供证书
listener.ssl.external.fail_if_no_peer_cert = true
# 支持 TLS 1.2 和 TLS 1.3
listener.ssl.tls_versions = tlsv1.3,tlsv1.2
# 服务端支持的密码套件
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émarrez EMQ X et entrez dans la console, puis utilisez la fonction ssl:connect/3 pour vous connecter :
%% 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"]}]).
复制代码Épilogue
Les "Lignes directrices pour la construction d'un système standard de sécurité du réseau et de sécurité des données pour l'Internet des véhicules" publiées par le ministère de l'Industrie et des Technologies de l'information ont clairement souligné qu'il est nécessaire de construire un système standard pour la sécurité du réseau Internet des véhicules et la sécurité des données. La sécurité des communications réseau et la sécurité des données dans le domaine de l'Internet des véhicules recevront de plus en plus d'attention, ce qui est l'un des facteurs clés pour améliorer la compétitivité des entreprises de l'Internet des véhicules. Nous espérons qu'à travers cet article, les lecteurs pourront maîtriser l'utilisation du protocole SSL/TLS, l'appliquer correctement dans des scénarios commerciaux réels et réaliser la sécurité de la communication Internet des véhicules.
Déclaration de copyright : Cet article est original par EMQ, veuillez indiquer la source lors de la réimpression.
Lien d'origine : www.emqx.com/zh/blog/ssl…