高级 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 的 SSL 证书清算所——价格如此之低，我们的服务器必须被黑客入侵！"

物有所值:

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

不想:

• 我不想为每个盒子提供相同的静态密钥集.不能"列表暗示了这种情况，但我知道风险.

是的，我知道..

• 我可以并且确实为用户提供了一种机制来上传他们自己的证书/密钥，但我认为这种高级模式"超出了这个问题的范围.如果用户足够先进，可以拥有自己的内部 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 访问重定向到域，或者让盒子拦截请求，或者在互联网上做一些 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屋！