我正在考虑将 IoT 设备连接到我的本地网络（默认设置、无 VPN、无 NAT、无 DMZ），无论是否可以访问互联网。我的设备将作为 HTTP 服务器运行，提供带有身份验证和授权的 RPC 机制。它用 mDNS 做广告，我用我的移动应用程序或我的 RaspberryPi 与它交谈。
似乎物联网开发中的规范是具有双向（双向）SSL。 这是否意味着单向 SSL 无法保护我的流量？为什么？
笔记：
当“服务器”位于已知位置（固定主机名）并且可以匹配它提供的证书的 CN 时，SSL/TLS 运行良好。
这对于家庭网络上的设备（例如大多数物联网设备）效果不佳，因为它们倾向于从 RFC1918 块中获取 IP 地址，并且没有 DNS 条目。这意味着不能向它们颁发证书（当然可以，但大多数浏览器会拒绝它们）。这就是像 Philips Hue 这样的设备使用设备的不安全 HTTP 端点的原因，它们基本上依赖于对受保护的网络的访问来保护设备。
当使用双向 TLS 时，当设备连接到某个中央服务时，客户端拥有自己的证书/私钥来验证它是否能够代表所有者对中央服务器进行操作。
为了澄清您的问题，您不需要将服务器证书/密钥分发给所有客户端，只需要颁发证书的 CA 的证书来证明该证书是可信的。
编辑：
安全本地设备连接的一个很好的例子是宜家的 Tradfri 照明，它使用 COAP over DTLS 和设备上的预共享密钥（在二维码中），用于生成每个客户端的密钥。这确保了设置新客户端的物理访问，并保护本地网络上传输中的数据。
通常，TLS 的优势远不止 x.509，但许多实现将其限制为仅适用于 x.509。
x.509 是一种用于安全间接信任的技术。“A”信任“B”，如果“B”有一个由“C”签名的证书，“C”被“A”信任。这也适用于现实生活；你信任一个你不认识的人，如果一封信是由你信任的人签名的。也许你看到了陷阱：如果信中说，请给一杯咖啡，你不会给你的车。因此，证书中的附加信息也与信任范围相关。这就是为什么服务器通常在其证书中包含它的 dns 名称或 ip-address 的原因。通常，您可能包含不同的信息（例如“客厅灯”），但许多实现也至少预先配置为使用/检查 DNS/IP 内容。而这一切只有在有人关心可信赖的人时才有效”
如果您可以花时间在其中，请检查您的实现，如果它也提供 PSK 密码套件。如果没有，也许您可以调整服务器证书的“验证检查”。但是需要大量阅读才能找到一个好的解决方案。有时使用的 TLS 实现只是不提供。