物联网开发中的规范似乎是具有相互（双向）SSL。
这是否意味着单向SSL无法保护我的流量？为什么？
注意：
我确实了解一种和两种方式SSL的技术差异，但我不明白为什么单向（几乎）永远不会在物联网生产中考虑。
我知道要在本地设备上使用相互SSL是很困难的：您需要与客户端共享服务器公钥和证书，反之亦然。另一方面，单向似乎更容易（不需要用户操作）。
与单向SSL加密相比，像飞利浦Hue这样的大量量产的设备宁愿开放本地HTTP端点并且不安全。为什么要做出这个选择？
我希望这个问题不会基于观点。如果是这种情况，我们深表歉意。
#1 楼
当“服务器”位于已知位置（固定主机名），可以与它提供的证书的CN匹配时，SSL / TLS会很好地工作。这不适用于家庭网络上的设备（例如大多数IoT设备），因为它们倾向于获取从RFC1918块发出的IP地址，并且没有DNS条目。这意味着不能向它们颁发证书（当然可以，但是大多数浏览器都会拒绝它们）。这就是为什么飞利浦Hue之类的设备使用设备的不安全HTTP端点的原因，它们基本上依赖对要保护的网络的访问来保护设备。
使用双向TLS时，是指设备何时使用正在连接到某个中央服务，客户端具有自己的证书/私钥来验证它能够代表所有者使用该中央服务器。
为澄清您的问题您不需要将服务器的证书/密钥分发给所有客户端，只需要颁发证书的CA的证书来证明该证书是受信任的。
编辑：
IKEA的Tradfri照明是安全的本地设备连接的一个很好的例子，该照明使用DTLS上的COAP和设备上的预共享密钥（在QR码中），用于生成每个客户密钥。这样可以确保物理访问以设置新客户端并保护本地网络中正在传输的数据。
#2 楼
通常，TLS的优点远远超过x.509，但许多实现将其限制为仅x.509。x.509是一种用于安全间接信任的技术。如果“ B”具有由“ C”签名的证书，并且“ C”由“ A”信任，则“ A”信任“ B”。在现实生活中也是如此；您信任一个您不认识的人，如果您所信任的人出示了一封信。也许您会看到一个陷阱：如果这封信上写着，请喝杯咖啡，您不会开车。因此，证书中的其他信息也与信任范围有关。这就是服务器通常在其证书中使用DNS名称或ip地址的原因。通常，您可能会包含不同的信息（例如“起居室灯”），但是许多实施方式也至少已预先配置为使用/检查DNS / IP内容。而且，只有在有人关心可信的“ C”的情况下，所有这一切才起作用。通常，操作系统或应用程序提供商通过更新有效的“证书颁发机构”列表来执行此操作。这非常复杂，其实现主要是针对非物联网用例开发的。还是谁将更新您设备上的有效“证书颁发机构”列表？我想您将不得不自己做。
如果可以花时间在它上面，请检查实现，如果它还提供PSK密码套件。如果没有，也许您可以调整服务器证书的“验证检查”。但这需要大量阅读才能找到一个好的解决方案。有时使用的TLS实现只是不提供此功能。
评论
如果主机不是使用固定的DNS名称或IP地址，则正常的证书验证将失败，因为该证书断言该地址处的设备就是它所说的身份（正常的“单面” SSL）。对于相互认证的SSL，您不应为双方使用相同的密钥/证书。服务器和客户端应达到相互信任的CA签署的自己的证书/密钥
– hardillb
18年7月2日在14:42
感谢您的回答，对不起@hardillb的沉默。 “这意味着它们无法获得证书（当然可以，但是大多数浏览器都会拒绝它们）。”考虑到与IoT设备的通信，我看不到何时使用浏览器进行通信……“您不需要将服务器的cert / key分发给所有客户端，只需将CA的证书分发出去”对于单向TLS，对吗？因为我相信对于相互之间，您确实需要提供证书和密钥，这会使事情变得更加困难。关于Tradfri，预共享密钥用于身份验证，而不用于加密。
–valentin
18年7月2日在14:43
tradrfi预共享密钥不是用于握手并创建每个设备的密钥进行加密的
– hardillb
18年7月2日在16:03