验证 /server url 中的请求答案

【问题标题】：Validating requests in /server url验证 /server url 中的请求
【发布时间】：2015-06-17 10:14:36
【问题描述】：

在 iOS MDM 中，当设备被 APNS 唤醒时，设备的每个操作都会调用 /server url。我在注册时已对其他配置文件进行了安全加密和签名，并成功地将服务器 URL 传递给了设备。它工作正常，但我对这个服务器端点没有什么顾虑，如下所示。

1) 任何可以发送类似 plist 有效负载的客户端或实体都可以调用此服务。如果第 3 方有权访问设备 UDID，他们可以编写此 xml 有效负载并调用此服务。从服务器的角度来看，很难跟踪这种行为并识别真实设备。要确定在真实场景中它会发送和 CMS 数据还是相关来验证这个场景？

2) 一旦设备从服务器到达该端点，我们就可以生成操作配置文件并将其发送回设备。对于注册时的配置文件，我们可以从 CMS 数据中提取公共证书并从中进行加密。但是对于这个服务器 url，我该如何实现呢？似乎它没有从设备端获得任何类似的证书。只是想知道是否保存我们在早期阶段获得的公钥，但由于在注册时它通过 2 个 SCEP 调用不知道该使用什么。这些后续配置文件有效负载是否可以使用以前的公共证书加密？现在我无论如何都做了签名，效果很好。

【问题讨论】：

标签： ios mdm

【解决方案1】：

1.) 任何可以发送类似 plist 有效负载的客户端或实体都可以调用此服务。如果第 3 方有权访问设备 UDID，他们可以编写此 xml 有效负载并调用此服务。从服务器的角度来看，很难跟踪这种行为并识别真实设备。要确定在真实场景中它会发送和 CMS 数据还是相关来验证这个场景？

是的，任何可以拥有 UDID 和服务器 URl 的客户端都可以将有效的 Plist 发送到您的服务器，就像设备一样。
但他们无法使用设备中的私钥（在 SCEP 注册期间生成）对 plist 进行签名。您将拥有相应的公钥来验证签名。
要强制设备将签名随每个请求发送到Server URL，您必须在 MDM 有效负载中包含SignMessage 标记并将其设置为 true。像这样

<key>SignMessage</key>
     <true/>

因此，当您将此标记与 MDM 有效负载一起包含时，您将在标头 HTTP_MDM_SIGNATURE 中获得身份私钥的签名。然后您可以使用您的公钥验证签名。

2.) 只是想知道是否要保存我们在早期阶段获得的公钥，但由于在注册时它经历了 2 个 SCEP 调用不知道怎么用。

是的，我在上一个答案中提到您应该保存在 SCEP 阶段颁发的公共证书。稍后您将使用该公共证书来验证来自设备的签名并加密您发送的配置文件。

关于 2 个 SCEP 调用，第一个 SCEP 调用是生成证书并安全地传输 MDM 有效负载和实际的 SCEP 有效负载，这将用作 MDM 的身份证书。
所以你应该使用第二个来验证签名和加密。

另一个提示是，您会在 MDM 有效负载中提到 IdentityCertificateUUID。身份证书 SCEP 有效负载应具有与其 PayloadUUID 相同的 UUID。该 SCEP 有效负载的证书将用作 MDM 的身份证书。

【讨论】：

感谢您的回复。似乎 SignMessage 可以解决问题，然后我应该能够验证它。我只是有将它指向支持 SCEP 的第 3 方 CA 服务器的问题。在这种情况下，理论上应该有一种方法或端点在从 MDM 服务器发送这些证书时对其进行验证。
@Dilshan：顺便说一下，我想依靠第三方 CA 进行 SCEP 的成本会非常高。现在有很多开源 SCEP 实现可用。您可以利用它并拥有自己的 SCEP 服务器。
现在我已经实现了这个，它端到端工作正常。注册流程也没有问题。我只想为客户提供一些扩展点以插入 3rd 方 CA。为此，只需找出可能性。还要弄清楚这个注册流程中的问题。自从我遇到这个问题后，才发布了这个问题。感谢您的回复。

【解决方案2】：

好的。您要对设备进行身份验证的底线。

每个设备都有一个身份证书（在 PKCS12 中或通过 SCEP 分发的证书）。

每次设备与服务器通信时，它都会使用 SSL 客户端证书进行身份验证。

大多数时候，您的网络服务器前面都有一个反向代理。它可以是 Apache 或 Nginx 或其他任何东西。此反向代理终止 SSL 连接并检查客户端证书。通常，它们被配置为将此客户端证书作为标头传递给您的 Web 应用程序。

这样，您的 Web 应用程序可以获取此标头，从中获取证书并检查您的数据库是否具有特定 udid（传递到您的端点）的设备具有证书（在标头中传递到您的 Web 应用程序）。

我不确定您使用哪种反向以及是否正确配置以通过证书。

【讨论】：

感谢维克多的回复。现在它在独立服务器上运行，配置反向代理将是部署的事情。因此，标头传递机制将取决于此反向代理的配置。由于此设备进行客户端身份验证，我假设我可以从我的 JAX-RS 端点读取此证书。有了那个证书，我应该能够验证这一点。
由于任何人都可以将我的 MDM 服务器指向第 3 方证书颁发机构，因此我无法在 SCEP 注册阶段获得生成的证书。因此，我假设我需要查看的地方是 /profile url，如果我没记错的话，设备当时也会发送其身份证书。
@Dilshan 一般来说，我只描述了一种可能的设置（最常见）。归根结底，某些东西应该终止 SSL，验证客户端证书并以某种方式将其传递给您的应用程序。它可以通过很多不同的方式完成。
这是一个有趣的设置（用户可以指向他们自己的证书颁发机构）。你为什么有这个？它对 WiFi 和 VPN 的证书很有用。但是，我看不到 iOS MDM 客户端证书的好处。在 SCEP 注册时保存证书是有益的。这样，您可以确保将证书正确绑定到设备 udid。但是，您可能可以在第一次调用命令 url 时执行此操作（会有一个漏洞窗口）
感谢维克多的回复。我的意思是每个部署客户端都可以指向 3rd 方 CA，例如 EJBCA。因此，x509 生成发生在 MDM 服务器不知道的那一端。在正常情况下，此 SCEP 调用通过嵌入式 CA，在这种情况下，我的 MDM 可以跟踪它。如果是这样，该解决方案将起作用。但是正如您提到的，我知道如果我们从端点获取该漏洞，则可能存在漏洞。理想情况下应该发生的是，设备请求应该由其私钥签名，我将在其中验证它以检查发件人。