了解 SSL [英] Understanding SSL

问题描述

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

I have three questions regarding SSL that I don't fully understand.

1. 如果我理解正确，服务器 A 会向某个 CA 提交请求.然后，它接收(经过验证等)一个数字证书，该证书由公钥 + 身份 + 使用 CA 的私钥对该信息的加密组成.

1. If I get it correctly, a server A submits a request to a certain CA. Then, it receives (after validation etc.) a digital certificate composed of a public key + identity + an encription of this information using the CA's private key.

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

Later on, a client B wants to open an SSL communication with A, so A sends B its digital certificate.

我的问题是不能 B 只拿这个证书，从而窃取身份 A - 这将允许他们以 A 身份验证以C为例.我知道 C 将使用 CA 的公钥解密证书，然后加密其对称密钥，该密钥只​​能由真正的 A 解密.

My question is can't B just take this certificate, thus stealing the identity A - which will allow them to authenticate as A to C, for example. I understand that C will decrypt the certificate with the CA's public key, It will then encrypt its symetric key which will only be decryptable by the real A.

然而，如果 B 真的可以窃取 A 的身份，我看不出身份验证在何处发挥作用.除非我遗漏了什么.

However, I do not see where authentication comes to play if B can actually steal A's identity. Unless I am missing something.

第二个问题:如果证书的一部分已经被 CA 加密，为什么要对证书使用散列?这是否意味着无论如何都没有人可以乱用数字证书(很有可能)?

Second question: Why use hashing on the certificate if a part of it is already encrypted by the CA? Doesn't this mean that no one can mess around with a digital certificate (in high probability) anyway?

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

If I am stackoverflow and I have 3 servers doing the same thing - allowing clients to access, read, identify etc. - do I have to have a different digital certificate for each of the 3 servers.

非常感谢.

推荐答案

一个 SSL 身份有四个部分的特点:

An SSL identity is characterized by four parts:

1. 一个私钥，不与任何人共享.

2. 一个公钥，您可以与任何人共享.

1. A private key, which is not shared with anyone.

2. A public key, which you can share with anyone.

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

The private and public key form a matched pair: anything you encrypt with one can be decrypted with the other, but you cannot decrypt something encrypted with the public key without the private key or vice versa. This is genuine mathematical magic.

公钥和元数据组合上的数字签名，这样它们就不会被弄乱，并且其他人可以知道对元数据的信任程度.有多种方法可以处理签名的人:

A digital signature on the combination of public key and metadata so that they can't be messed around with and so that someone else can know how much to trust the metadata. There are multiple ways to handle who does the signature:

• 使用私钥签名(来自上面的第 1 部分)；自签名证书.任何人都可以做到这一点，但它并没有传达出太多的信任(正是因为任何人都可以做到这一点).
• 让一群相互信任的人通过签署证书来为你担保；信任网络(之所以如此称呼，是因为信任关系是可传递的，并且通常在人们互相签署证书时是对称的).
• 请受信任的第三方进行签名；证书颁发机构 (CA).CA 的身份由信任链中的另一个更高级别的 CA 保证，回到每个人"信任的某个根权限(即，您的 SSL 库中内置了一个列表，可以在部署时更新).

• Signing with the private key (from part 1, above); a self-signed certificate. Anyone can do this but it doesn't convey much trust (precisely because anyone can do this).
• Getting a group of people who trust each other to vouch for you by signing the certificate; a web-of-trust (so called because the trust relationship is transitive and often symmetric as people sign each others certificates).
• Getting a trusted third party to do the signing; a certificate authority (CA). The identity of the CA is guaranteed by another higher-level CA in a trust chain back to some root authority that "everyone" trusts (i.e., there's a list built into your SSL library, which it's possible to update at deployment time).

上述三种类型的权威之间没有基本的技术差异，但人们对它们的信任性质千差万别.为什么会这样的细节确实需要一个很长的答案！

There's no basic technical difference between the three types of authorities above, but the nature of the trust people put in them is extremely variable. The details of why this is would require a very long answer indeed!

第 2-4 项是数字证书的组成部分.

Items 2–4 are what comprises the digital certificate.

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

When the client, B, starts the SSL protocol with the server, A, the server's digital certificate is communicated to B as part of the protocol. A's private key is not sent, but because B can successfully decrypt a message sent by the other end with the public key in the digital certificate, B can know that A has the private key that matches. B can then look at the metadata in the certificate and see that the other end claims to be A, and can examine the signature to see how much to trust that assertion; if the metadata is signed by an authority that B trusts (directly or indirectly) then B can trust that the other end has A's SSL identity. If that identity is the one that they were expecting (i.e., they wanted to talk to A: in practice, this is done by comparing the DNS name in the certificate with the name that they used when looking up the server address) then they can know that they have a secured communications channel: they're good to go.

B 不能用这些信息来模拟 A:B 没有得到 A 的私钥，所以它会在验证的第一阶段分崩离析.为了让某个第三方冒充 B，他们需要(至少)两个:

B can't impersonate A with that information though: B doesn't get A's private key and so it would all fall apart at the first stage of verification. In order for some third party to impersonate B, they need to have (at least) two of:

• 私钥.身份的所有者需要注意阻止这种情况的发生，但这最终掌握在他们手中.
• 做出虚假陈述的可信权威.这里偶尔有弱点——自签名的权威从来都不是非常值得信赖的，信任网络会遇到问题，因为信任是传递性处理的尴尬事情，一些 CA 完全不择手段，而另一些 CA 则倾向于不排除渣滓——但大多数情况下这很有效，因为大多数各方都热衷于不引起问题，通常是出于经济原因.
• 一种毒害 DNS 的方法，使目标相信不同的服务器确实是被冒充的.不幸的是，如果没有 DNSsec，这有点容易，但这个特殊问题正在减少.

• The private key. The owner of the identity needs to take care to stop this from happening, but it is ultimately in their hands.
• A trusted authority that makes false statements. There's occasional weaknesses here — a self-signed authority is never very trustworthy, a web of trust runs into problems because trust is an awkward thing to handle transitively, and some CAs are thoroughly unscrupulous and others too inclined to not exclude the scum — but mostly this works fairly well because most parties are keen to not cause problems, often for financial reasons.
• A way to poison DNS so that the target believes a different server is really the one being impersonated. Without DNSsec this is somewhat easy unfortunately, but this particular problem is being reduced.

至于您的其他问题……

如果证书的一部分已被 CA 加密，为什么要对证书使用散列?这是否意味着无论如何都没有人可以乱用数字证书(很有可能)?

Why use hashing on the certificate if a part of it is already encrypted by the CA? Doesn't this mean that no one can mess around with a digital certificate (in high probability) anyway?

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

While keys are fairly long, certificates are longer (for one thing, they include the signers public key anyway, which is typically the same length the key being signed). Hashing is part of the general algorithm for signing documents anyway because nobody wants to be restricted to signing only very short things. Given that the algorithm is required, it makes sense to use it for this purpose.

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

If I am stackoverflow and I have 3 servers doing the same thing - allowing clients to access, read, identify etc. - do I have to have a different digital certificate for each of the 3 servers.

如果您有多个服务器提供相同的 DNS 名称(有很多方法可以做到这一点，最简单的方法之一是循环 DNS 服务)，您可以在每个服务器上放置相同的身份.这稍微降低了安全性，但只是非常轻微；它仍然是一个服务，恰好由多个服务器实现.理论上，您可以给每个人一个不同的身份(尽管名称相同)，但我想不出任何实际这样做的充分理由；与替代方案相比，它更可能让人们担心.

If you have several servers serving the same DNS name (there's many ways to do this, one of the simplest being round-robin DNS serving) you can put the same identity on each of them. This slightly reduces security, but only very slightly; it's still one service that just happens to be implemented by multiple servers. In theory you could give each one a different identity (though with the same name) but I can't think of any good reason for actually doing it; it's more likely to worry people than the alternative.

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

Also note that it's possible to have a certificate for more than one service name at once. There are two mechanisms for doing this (adding alternate names to the certificate or using a wildcard in the name in the certificate) but CAs tend to charge quite a lot for signing certificates with them in.

这篇关于了解 SSL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！