本地网络中设备的 SSL

Question

初始问题

我们制造运行网络服务器的设备，用户可以通过直接浏览设备的 IP 来控制设备的某些功能。当使用直接 WiFi 或以太网连接时，这可以是固定 IP，但在大多数情况下，这是设备从网络中的 DHCP 服务器接收的 IP。

访问浏览器的一些更高级的功能需要越来越多的 HTTPS。例如访问缓存（https://developer.mozilla.org/en-US/docs/Web/API/Cache），允许使用网络摄像头（https://blog.mozilla.org/webrtc/camera -microphone-require-https-in-firefox-68/ ), Service Workers ( https://www.digicert.com/dc/blog/https-only-features-in-browsers/ ), ...列表保留每天都在成长。

我都赞成拥有安全系统，但我认为存在一个主要问题。HTTPS (TLS) 设置证书的方式仅在域名与证书中的域名匹配并且证书颁发机构被客户端浏览器接受时才被标记为有效，即所谓的信任链。这在使用固定主机名的网络上非常有效。

然而，当用户不使用互联网而是使用他们的本地网络时，主机名是事先不知道的。有时用户可以使用本地 DNS、mDNS，但情况并非总是如此。很多时候用户只使用内部 IPv4 地址。这是问题开始的地方，因为使用我们制造的设备有两种选择：

1. 用户不使用 HTTPS（我们不强制执行，请继续阅读以了解原因）。目前的主要浏览器不会给出明确的警告，而是将页面标记为浅灰色的“不安全”。大多数用户甚至没有注意到它并且非常高兴。
2. 用户在同一设备上使用 HTTPS。尽管这使得连接更加安全，但浏览器现在明确告诉他们要极其谨慎地使用该设备，并且连接可能被黑客入侵，私人数据可能会被盗。该站点现在以红色标记为“不安全”，用户必须按 2 或 3 个按钮以允许证书例外。

选项 2 是我们不强制设备通过 HTTPS 访问的原因，因为它只是向许多用户发出警报并淹没客户服务。五年前，这并不是真正的问题，因为没有 HTTPS 一切都可以完成。随着越来越多的 API 现在只能在“安全上下文”中工作，这对我们来说真的是一个问题。

因此，我认为设计一个完全在内部网络中使用 HTTPS 而不使用主机名系统的系统的需求变得非常大。我可以想象私有 IPv4 范围可以从警告或更聪明的东西中排除。这让我想到我的问题，您是否面临同样的问题，如何解决？

更新 1

正如第一条评论中所指出的，现在提出的解决方案是使用通配符证书并为公共域上的设备配置 DNS 条目。然而，这存在客户端仍然需要活动互联网连接的问题。在此类设置中，情况当然并非总是如此。

更新 2

我还发现了这篇关于 Let's encrypt 的文章，它在没有给出解决方案的情况下讨论了同一主题：https : //letsencrypt.org/docs/certificates-for-localhost/

更新三：假设的解决思路

阅读以下答案和评论后，我正在考虑针对该问题的可能的安全解决方案。下面的设置（如果允许的话）是否安全？

1. 从具有名称约束的受信任根 CA 请求中间 CA 证书，该证书仅允许创建多个中间 CA，这些中间 CA 只能为单个固定主机名“*.mydevice.local”或类似内容创建证书，并允许所有私有 IPv4 地址在 SAN 中使用。
2. 每个部署的设备都将在出厂时安装一个唯一的中间 CA，该中间 CA 由我在步骤 1 中谈到的中间 CA 创建。这个设备上的 CA 将被名称限制在“.mydevice.local”上。
3. 每次设备更改 IP 地址（启动、DHCP 更改等）时，它都可以使用设备上的中间 CA 生成证书。

我认为这样可以彻底解决问题并具有以下优点：

• 没有浏览器警告，因为信任链中继回受信任的根 CA。
• 每个设备都会有一个唯一的证书。
• 单个中间 CA 的妥协不会是那么大的问题，因为它只能用于为设备的特定固定主机名创建受信任的证书。

如果我忽略了什么，请发表评论。

更新 4：

我要感谢大家的帮助和思考。我的结论是证书背后的整个想法及其背后的信任链不允许我想要什么。这是因为 CA 根本无法确保我指向的内部 IP 地址是我想要访问的设备唯一拥有的。内部 IP，例如 192.168.0.10，由数千台设备拥有，因此不可能授予允许浏览器不显示警告显示的证书。

唯一的选择是通过手动干预进行证书验证（安装设备证书，将您自己设备的 CA 推送给用户，以及答案中提出的各种更复杂的选项）。这只是我需要忍受的。

尽管如此，我想我会用 Firefox 和 Chrome 打开一张票。因为我认为对于内部 IP 地址，一个简单的灰色非安全警告（如 HTTP）就足够了。红色警告只应在其设计用例中使用 HTTPS 时显示。

更新 5：

我已在 Bugzilla 提交错误报告：https ://bugzilla.mozilla.org/show_bug.cgi ? id = 1705543我将此链接作为参考发布，以便任何人都可以关注该问题。

Answer 1

步骤 1：使设备在首次设置或更改 IP 地址时为其 IP 地址和/或主机名生成自签名证书，除非有客户提供的证书。不要出售带有通用证书的设备（请参阅您链接的让我们加密文章）。

第 2 步：让您的文档描述如何识别您的特定自签名证书并在常用浏览器中接受它们。

第 3 步：让您的文档描述如何将自签名证书替换为由组织自己的证书颁发机构或公共 CA 生成的另一个证书。

Answer 2

在我们的一个项目中，我们遇到了一个问题，我们想要从由互联网提供服务的网页连接到本地网络上的 websocket。为了使用安全 Web 套接字连接 (wss://)，我们需要 SSL 证书，但您无法获取本地 IP 的证书。底线是我们无法更改客户端计算机配置（没有 /etc/hosts，没有导入自己的 CA）。

在寻找解决方案时，我们受到 xip.io 服务的启发，并提出了这样的想法：我们可以使用通配符 SSL 证书，并稍微更改 xip.io的方法，将不带点的本地 IP 放入 URL 中 - 获取子域这是对通配符 SSL 的抱怨。所以我们启动了自定义 DNS 服务，其工作原理如下：

dig 10-0-0-1.my.local-ip.co

;; ANSWER SECTION:
10-0-0-1.my.local-ip.co. 299    IN  A   10.0.0.1

我们在网站http://local-ip.co上免费提供域名 *.my.local-ip.co 的 SSL 证书

唯一的缺点是你仍然需要互联网连接才能运行它，但另一方面你不需要安装或配置任何东西来让它运行......

干杯，马尔辛

Answer 3

我在目前的工作中广泛处理了这个问题——包括高度重视离线工作问题。

首先要记住的是，如果他们在离线时没有可用的 DNS 服务器 - 没有手动修改和戳的 TLS 将不起作用。它建立在验证 DNS 主机名与证书匹配的基础上，而不是原始 IP。如果这是一个无法解决的真正问题 - 文档和用户培训是您唯一真正的选择。

如果部署超出您的物理控制范围 - 通配符证书是一个可怕的提议。恶意方可以使用被黑客入侵和提取的通配符证书来造成大量破坏。

还记得更多的浏览器不接受长证书过期窗口（见这对于最近的苹果/ iOS的一个-限制证书一辈子到一年和一个位）

我建议投资基础设施以自动部署证书。我们还可以控制dnsmasq设备上的小型服务器，提供所需的 DNS 和 DHCP 方面 - 再次由部署自动化控制，可以确保它是最新的。在不了解您的解决方案和销售模式的情况下，很难判断这是否适合您。即：我们的解决方案不是静态的，并且有一个小的 4G 网关 - 所以只要每隔几个月通话一次，互联网损失就可以了。

IMO Puppet 适用于互联网受限的设备（而不是当前的开发运营宠儿 Ansible），因为代理方面允许设备在有机会时尝试自行部署 - 并且在 NAT 后的 IPv4 网关之后运行良好。