了解SSL

Question

我有三个关于SSL的问题我还不完全理解.

1. 如果我正确地得到它,服务器会A向某个CA提交请求.然后,它使用CA的私钥接收(在验证之后)由公钥+身份+对该信息的描述组成的数字证书.

   稍后,客户端B想要打开SSL通信A,因此A发送B其数字证书.

   我的问题是不能B仅仅拿这个证书,从而窃取身份A-这将让他们为验证A到C,例如.据我所知,C将使用CA的公钥解密证书,然后它将加密其对称密钥,该密钥只​​能由真实密钥解密A.

   但是,如果B能够真正窃取A身份,我看不到身份验证的发挥作用.除非我遗漏了什么.

2. 第二个问题:如果CA的一部分已经加密,为什么要在证书上使用哈希？这是不是意味着没有人可以乱用数字证书(很有可能)？

3. 如果我是stackoverflow并且我有3台服务器做同样的事情 - 允许客户端访问,读取,识别等 - 我是否必须为3台服务器中的每台服务器提供不同的数字证书.

非常感谢你.

Answer 1

SSL身份的特征由四部分组成:

1. 一个私有密钥,它不与任何人共享.

2. 一个公共密钥,您可以与任何人分享.

   私钥和公钥形成匹配对:用一个加密的任何东西都可以用另一个解密,但是你不能用私钥解密用公钥加密的东西,反之亦然.这是真正的数学魔法.

3. 附加到公钥的元数据,说明它正在谈论的人.对于服务器密钥,这将标识正在保护的服务的DNS名称(以及其他内容).此处的其他数据包括预期用途(主要用于限制持有证书的人可以造成的损害数量)和有效期限(限制被盗证书的使用时间).

4. 一个数字签名的公开密钥和元数据的组合,使他们不能与周围的混乱和让别人知道有多少信任的元数据.有多种方法可以处理签名者:

   • 使用私钥签名(来自上面的第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的一部分已经加密,为什么要在证书上使用散列？这是不是意味着没有人可以乱用数字证书(很有可能)？

虽然密钥相当长,但证书更长(一方面,它们包括签名者公钥,通常与签名密钥的长度相同).Hashing是用于签署文档的通用算法的一部分,因为没有人希望仅限于签署非常短的内容.鉴于该算法是必需的,因此将其用于此目的是有意义的.

如果我是stackoverflow并且我有3台服务器做同样的事情 - 允许客户端访问,读取,识别等 - 我是否必须为3台服务器中的每台服务器提供不同的数字证书.

如果您有多个服务器提供相同的DNS名称(有很多方法可以执行此操作,最简单的方法之一是循环DNS服务),您可以在每个服务器上放置相同的标识.这略微降低了安全性,但只是非常轻微; 它仍然是一个恰好由多个服务器实现的服务.从理论上讲,你可以给每个人一个不同的身份(虽然名字相同),但我想不出有什么理由去实际做; 它更可能让人担心而不是替代方案.

另请注意,可以同时拥有多个服务名称的证书.有两种机制可以执行此操作(在证书中添加备用名称或在证书名称中使用通配符),但CA通常会为使用它们签名证书收取相当多的费用.

Answer 2

我的问题是不能"B"只拿这个证书,从而窃取"A"的身份 - 这将允许他们认证为"A"到"C"

还有一个未传输的证书的私有部分(私钥). 没有私钥,B无法作为A进行身份验证. 同样,我知道您的StackOverflow用户名,但这不会让我以您的身份登录.

如果CA的一部分已经加密,为什么要在证书上使用散列？

通过这种方式,任何人都可以验证它是产生哈希的CA,而不是其他人.这证明证书是由CA生成的,因此,"验证等".表演了.

如果我是stackoverflow并且我有3台服务器做同样的事情 - 允许客户端访问,读取,识别等 - 我是否必须为3台服务器中的每台服务器提供不同的数字证书.

这取决于具体情况,但您可能每个都有相同的证书.

Answer 3

第一个问题：您从 CA 获得的信息是正确的，但在向 CA 提交请求之前您缺少部分所需信息。您需要 (1) 证书请求，以及 (2) 相应的私钥。您不将私钥作为请求的一部分发送；你在你的服务器上保密。您签署的证书包含相应公钥的副本。在任何客户端相信 B“拥有”该证书之前，B 必须通过使用密钥签署客户端发送的质询来证明这一点。如果没有 A 的私钥，B 就无法做到这一点。

第二个问题：典型的公钥密码术对固定大小的数据（例如，2048 位）进行操作，并且计算成本较高。因此，为了对任意大小的文档进行数字签名，该文档被散列成固定大小的块，然后使用私钥进行加密。

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