了解SSL

 

我有三个关于SSL的问题，我不完全了解。

  • 如果我得到它的正确，服务器A提交请求到某个CA. 然后，它接收（在验证等之后）由公钥+身份+使用CA的私钥对此信息进行篡改组成的数字证书。

    之后，客户B想要打开与A的SSL通信，所以A向B发送其数字证书。

    我的问题是B不能拿这个证书，因此窃取身份A - 例如，他们将允许他们认证为A到C 我知道C将用CA的公钥解密证书，然后它将加密其对称密钥，该密钥只​​能由真实A解密。

    但是，如果B实际上窃取了A的身份，我不会看到身份验证在哪里发挥作用。 除非我错过了一些东西。

  • 第二个问题：如果证书的一部分已经被CA加密，为什么要在证书上使用散列？ 这是否意味着无论如何，没有人可以随意使用数字证书？

  • 如果我是stackoverflow，并且我有3台服务器做同样的事情 - 允许客户端访问，读取，识别等 - 我必须为3台服务器分别配备不同的数字证书。

    • 非常感谢你。

    SSL身份的特征包括四个部分：

  • 私人密钥，不与任何人共享。

  • 一个公钥，您可以与任何人分享。

    私钥和公钥形成一对匹配：您用一个加密的任何内容都可以与另一个加密解密，但不能用私钥解密用公钥加密的内容，反之亦然。 这是真正的数学魔法。

  • 附加到公开密钥的元数据表明了它正在讨论的人员。 对于服务器密钥，这将标识正在保护的服务的DNS名称（等等）。 此处的其他数据包括预期用途（主要用于限制证书被盗人员可以执行的损害数量）和失效日期（限制被盗证书的使用期限）等内容。

  • 对公钥和元数据进行组合的数字签名，以便它们不会被混淆，以便其他人可以知道信任多少元数据。 处理签名的人有多种方式：

  • （从上面的第1部分）签署私钥; 自签证书。 任何人都可以做到这一点，但它并没有表达太多的信任（正是因为任何人都可以这样做）。
  • 让一群相互信任的人通过签署证书为您担保; 信任网络（所谓的，因为信任关系是传递性的，并且通常在人们彼此签署证书时是对称的）。
  • 获得可信的第三方签名; 证书颁发机构（CA）。 CA的身份由信任链中的另一个更高级别的CA保证，返回到“所有人”信任的某个根权威机构（即，有一个内置于您的SSL库中的列表，可以在部署时更新）。

    • 上述三种权力机构之间并没有基本的技术差异，但信任人的性质极其多变。 为什么会这样的细节确实需要很长的答案！

    项目2-4是由数字证书组成的。

    当客户端B与服务器A启动SSL协议时，服务器的数字证书将作为协议的一部分传送给B. A的私钥没有被发送，但是由于B可以用数字证书中的公钥成功解密另一端发送的消息，所以B可以知道A具有匹配的私钥。 B然后可以查看证书中的元数据，并看到另一端声称是A，并且可以检查签名以查看相信该断言多少; 如果元数据由B信任的权威（直接或间接）签署，则B可以相信另一端具有A的SSL身份。 如果该身份是他们期望的身份（即他们想与A进行交谈：在实践中，这是通过将证书中的DNS名称与查找服务器地址时使用的名称进行比较来完成的），那么他们可以知道他们有一个安全的沟通渠道：他们很好走。

    B不能用这些信息来模拟A：B没有得到A的私钥，因此在验证的第一阶段它将全部崩溃。 为了让第三方冒充B，他们需要（至少）两个：

  • 私钥。 身份的所有者需要小心，以防止这种情况发生，但它最终在他们手中。
  • 作出虚假陈述的可信当局。 这里偶尔会有一些弱点 - 自签名的权威永远不可信，信任网络会遇到问题，因为信任是传递性处理的一个尴尬事情，一些CA完全不择手段，而另一些则倾向于不排除这种败类 - 但主要这项工作相当成功，因为大多数政党都热衷于不会造成问题，通常是出于经济原因。
  • 一种毒化DNS的方法，以便目标相信不同的服务器实际上是被模拟的。 如果没有DNSsec，这很容易，但不幸的是，这个问题正在减少。

    • 至于你的其他问题......

    为什么在证书上使用散列，如果它的一部分已经被CA加密了？ 这是否意味着无论如何，没有人可以随意使用数字证书？

    虽然密钥相当长，但证书更长（首先，它们包含签名者公钥，无论如何，这通常与签署的密钥长度相同）。 散列是用于签署文档的一般算法的一部分，因为没有人希望仅限于签署非常短的东西。 鉴于该算法是必需的，为此目的使用它是有意义的。

    如果我是stackoverflow，并且我有3台服务器做同样的事情 - 允许客户端访问，读取，识别等 - 我必须为3台服务器分别配备不同的数字证书。

    如果您有几台服务器提供相同的DNS名称（有很多方法可以做到这一点，其中最简单的一种是循环DNS服务），您可以在每台服务器上放置相同的标识。 这稍微降低了安全性，但只是非常轻微; 它仍然是一个恰好由多个服务器实施的服务。 理论上你可以给每个人一个不同的身份（虽然名字相同），但我想不出有什么好的理由去实际做到这一点; 与其他选择相比，更容易让人担心。

    另请注意，可以同时拥有多个服务名称的证书。 有两种机制可以做到这一点（在证书中添加备用名称或在证书名称中使用通配符），但CA对与其签署证书往往收取相当多的费用。

    我的问题是不能“B”拿这个证书，因此窃取了“A”的身份 - 这将允许他们认证为“A”到“C”

    还有一个私人部分的证书没有被传输（私钥）。 没有私钥，B无法认证为A.同样，我知道您的StackOverflow用户名，但不会让我以您身份登录。

    为什么在证书上使用散列，如果它的一部分已经被CA加密了？

    通过这样做，任何人都可以验证是由谁制作了哈希，而不是其他人。 这证明证书是由CA生成的，因此“验证等” 被执行。

    如果我是stackoverflow，并且我有3台服务器做同样的事情 - 允许客户端访问，读取，识别等 - 我必须为3台服务器分别配备不同的数字证书。

    这取决于具体情况，但每个人可能都有相同的证书。

    第一个问题：您从CA处取回的内容是正确的，但在您将请求提交给CA之前，您缺少了所需的部分内容。 您需要（1）证书请求，和（2）相应的私钥。 您不会将私钥作为请求的一部分发送出去; 你在服务器上保密。 您的签名证书包含相应公钥的副本。 在任何客户认为B“拥有”证书之前，B必须使用密钥来签署客户发送的挑战来证明它。 如果没有A的私钥，B不能这样做。

    第二个问题：典型的公钥密码体制对固定大小的数据（例如2048比特）进行操作，并且在计算上有些昂贵。 因此，为了对任意大小的文档进行数字签名，将文档散列为固定大小的块，然后用私钥对其进行加密。

    第三个问题：您可以在多个服务器上使用单个证书; 你只需要在所有服务器上使用相应的私钥。 （当然，用于访问服务器的DNS名称必须与证书中的CN匹配，否则客户端可能会出现问题，但有一个DNS名称引用多个服务器是一种常见且简单的负载平衡方法。）

    链接地址: http://www.djcxy.com/p/3701.html

    上一篇: Understanding SSL

    下一篇: SSL: How are certificates protected against man in the middle attacks?