高级 SSL:中间证书颁发机构和部署嵌入式盒子 [英] Advanced SSL: Intermediate Certificate Authority and deploying embedded boxes

问题描述

好的，高级 SSL 女士们和伙计们 - 在两天的时间之后，我将为此添加赏金，因为我认为这是一个复杂的主题，值得对任何认真回答的人进行奖励.

Ok Advanced SSL gals and guys - I'll be adding a bounty to this after the two-day period as I think it's a complex subject that deserves a reward for anyone who thoughtfully answers.

这里的一些假设很简单:假设，或者更准确地说是充满希望的猜测.认为这是一个脑筋急转弯，简单地说这不可能"是没有意义的.

Some of the assumptions here are simply that: assumptions, or more precisely hopeful guesses. Consider this a brain-teaser, simply saying 'This isn't possible' is missing the point.

如果您做过类似"的事情，欢迎提供替代和部分解决方案，个人经验.即使我的整个计划有缺陷，我也想从中学到一些东西.

Alternative and partial solutions are welcome, personal experience if you've done something 'similar'. I want to learn something from this even if my entire plan is flawed.

这是场景:

我正在嵌入式 Linux 系统上进行开发，并希望其 Web 服务器能够提供开箱即用的、无障碍的 SSL.这是我的目标设计标准:

I'm developing on an embedded Linux system and want its web server to be able to serve out-of-the-box, no-hassle SSL. Here's the design criteria I'm aiming for:

必备:

• 我不能让用户将我自己的 CA 证书添加到他们的浏览器中
• 我不能让用户将静态生成的(在制造时)自签名证书添加到他们的浏览器
• 我不能让用户将动态生成的(在启动时)自签名证书添加到他们的浏览器.
• 我不能默认使用 HTTP 并为 SSL 启用/禁用切换.必须是 SSL.
• 嵌入式盒子和网络浏览器客户端可能有也可能没有互联网接入，因此必须假设在没有互联网接入的情况下也能正常工作.我们可以依赖的唯一根 CA 是操作系统或浏览器附带的根 CA.让我们假设这个列表在浏览器和操作系统中基本"是相同的——也就是说，如果我们依赖它们，我们将有大约 90% 的成功率.
• 我不能使用夜间操作，即'Fast Eddie's SSL Certificate Clearing House -- 价格这么低，我们的服务器一定会被黑！'

有福了:

• 我不希望用户警告证书的主机名与浏览器中的主机名不匹配.我认为这是一个不错的选择，因为它可能是不可能的.

不想:

• 我不想为每个盒子提供相同的一组静态键.不能"列表暗示了一种，但我知道风险.

是的，我知道..

• 我可以并且确实为用户提供了一种机制来上传他们自己的证书/密钥，但我认为这种高级模式"超出了这个问题的范围.如果用户足够先进，可以拥有自己的内部 CA 或购买密钥，那么他们就很棒，我喜欢他们.

思考时间

我在 SSL 方面的经验是生成由真实"root 签名的证书/密钥，以及通过制作自己的内部 CA、在内部分发自签名"证书来提升我的游戏水平.我知道您可以链接证书，但我不确定操作顺序是什么.即浏览器是否向上走"链看到有效的根 CA 并将其视为有效证书 - 还是您需要在每个级别进行验证?

My experience with SSL has been generating cert/keys to be signed by 'real' root, as well as stepping up my game a little bit with making my own internal CA, distributing internally 'self-signed' certs. I know you can chain certificates, but I'm not sure what the order of operations is. i.e. Does the browser 'walk up' the chain see a valid root CA and see that as a valid certificate - or do you need to have verification at every level?

我遇到了中级证书颁发机构的描述，这让我想到了潜在的解决方案.我可能已经从简单的解决方案"变成了噩梦模式"，但是否有可能:

I ran across the description of intermediate certificate authority which got me thinking about potential solutions. I may have gone from 'the simple solution' to 'nightmare mode', but would it be possible to:

疯狂的想法 #1

• 获取由真实"CA 签名的中间证书颁发机构证书.( ICA-1 )
  • ROOT_CA -> ICA-1
  • ICA-1 -> ICA-2
  • ICA-2 -> SP-1

  好吧，你真聪明

  很可能，我的复杂解决方案不起作用 - 但如果它起作用，那就太好了.你有过类似的问题吗?你做了什么?取舍是什么?

  Most likely, my convoluted solution won't work - but it'd be great if it did. Have you had a similar problem? What'd you do? What were the trade offs?

  推荐答案

  基本上，不，你不能像你希望的那样做.

  Basically, no, you can't do this the way you hope to.

  您不是 SSL 中间机构，也不能成为其中的一员.即使你是，你也不可能被允许向消费者分发为任何域创建新的有效证书所需的一切，默认情况下在所有浏览器中都受信任.如果这是可能的，整个系统就会崩溃(并不是说它还没有问题).

  You aren't an intermediate SSL authority, and you can't afford to become one. Even if you were, there's no way in hell you'd be allowed to distribute to consumers everything necessary to create new valid certificates for any domain, trusted by default in all browsers. If this were possible, the entire system would come tumbling down (not that it doesn't already have problems).

  您通常无法让公共机构签署颁发给 IP 地址的证书，尽管在技术上没有任何阻碍.

  You can't generally get the public authorities to sign certificates issued to IP addresses, though there's nothing technically preventing it.

  请记住，如果您真的在除防篡改安全加密模块之外的任何地方分发私钥，那么您的设备并没有真正受到 SSL 的保护.任何拥有其中一台设备的人都可以提取私钥(尤其是在没有密码的情况下)，并对您的所有设备进行有效的、签名的 MITM 攻击.您不鼓励随便偷听，但仅此而已.

  Keep in mind that if you're really distributing the private keys in anything but tamper-proof secured crypto modules, your devices aren't really secured by SSL. Anyone who has one of the devices can pull the private key (especially if it's passwordless) and do valid, signed, MITM attacks on all your devices. You discourage casual eavesdropping, but that's about it.

  您最好的选择可能是获取并签署有效互联网子域的证书，然后让设备回答该子域.如果它是传出路径中的网络设备，您可能可以做一些路由魔术来使其响应域，类似于有多少围墙花园系统工作.您可以为每个系统提供类似system432397652.example.com"的内容，然后为与该子域对应的每个框生成一个密钥.将直接 IP 访问重定向到域，或者让盒子拦截请求，或者在 Internet 上进行一些 DNS 欺骗，以便域为每个客户端解析到正确的内部 IP.为此使用单一用途的主机域，不要与您的其他商业网站共享.

  Your best option is probably to get and sign certificates for a valid internet subdomain, and then get the device to answer for that subdomain. If it's a network device in the outgoing path, you can probably do some routing magic to make it answer for the domain, similarly to how many walled-garden systems work. You could have something like "system432397652.example.com" for each system, and then generate a key for each box that corresponds to that subdomain. Have direct IP access redirect to the domain, and either have the box intercept the request, or do some DNS trickery on the internet so that the domain resolves to the correct internal IP for each client. Use a single-purpose host domain for that, don't share with your other business websites.

  为证书支付更多费用并不能真正使它们或多或少合法.当一家公司成为根 CA 时，它远非一夜之间的操作.您应该检查一下 StartSSL 是否适合您的需求，因为它们不会按证书收费基础.

  Paying more for certificates doesn't really make them any more or less legit. By the time a company has become a root CA, it's far from a fly-by-night operation. You should check and see if StartSSL is right for your needs, since they don't charge on a per-certificate basis.

  这篇关于高级 SSL:中间证书颁发机构和部署嵌入式盒子的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！