SSL握手期间可以使用一个公钥加密和解密数据吗? [英] Can One Public Key be Used to Encrypt and Decrypt Data during the SSL Handshake?
问题描述
当服务器向客户端发送证书消息时，服务器证书中的公钥将用于验证服务器的身份(用公钥解密).
When a server sends a Certificate message to a client, the public key in the server's certificate will be used to verify server’s identity(decryption with the public key).
服务器在其证书消息之后使用 ServerKeyExchange 消息，会话密钥信息使用服务器证书中包含的相同公钥进行签名(使用公钥加密).
The server follows its Certificate message with a ServerKeyExchange message, the session key information is signed using the same public key contained in the server’s certificate (encryption with the public key).
所以我觉得公钥也可以用来加密和解密数据，对吗?如果是，我想知道为什么教科书只说明一个密钥(例如公钥)用于加密，而另一个(私钥)用于解密，而不是提到一个密钥可以用于加密和解密?
So I feel a Public key can be used to encrypt and decrypt data as well, am I right? If yes, I wonder why text book just states one key(e.g. public key) is used to encrypt , and the other one(private key) is used to decrypt, rather than mention that a key can be used to both encrypt and decrypt?
[更新2]
非常感谢布鲁诺的帮助.
[UPDATE2]
Really thanks for Bruno's help.
在反复阅读了 Bruno 的回复和 RFC4346(第 7.4.2 和 7.4.3 节)之后，我突然觉得我抓住了要点.:)
但是，我不确定我是否正确，希望有人能证实我的以下理解.谢谢.
After reading Bruno's replies and RFC4346(section7.4.2 and 7.4.3) again and again, I suddenly felt I grasp the main points. :)
However, I am not sure I am right, and hope someone can confirm my following understanding. Thanks.
1.服务器证书
SSL 和 TLS 基础 第 3.6.1 节:
(SSL 和 TLS 基础:保护网络作者:Stephen A. Thomas)
1.Server Certificate
SSL and TLS Essential section 3.6.1:
(SSL and TLS Essential: Securing the Web Author: Stephen A. Thomas)
...服务器证书中的公钥将仅用于验证其(服务器)身份.
...the public key in the server's certificate will only be used to verify its(server) identity.
布鲁诺写道，
Bruno wrote,
服务器证书中的公钥不用于验证服务器本身的身份.
The public key in the server certificate isn't used to verify the server's identity itself.
我现在同意 Bruno 的观点，因为证书只是一个私钥签名(加密)的消息，其中还包含其他人(例如，客户端)的公钥，因此客户端应该使用其受信任的服务器公钥副本密钥(通常，Web 浏览器预先包含几十个这样的证书)，而不是服务器证书中的公钥，用于验证服务器的身份.
I agree Bruno's viewpoint now, because a certificate is only a private-key-signed(encrypted) message that also contains someone else's(e.g., a client ) public key, so a client should use its trusted copy of the server's public key (usually, web browsers include dozens of these certificates in advance), instead of the public key in the server certificate, to verify the server's identity.
对吗?
2.服务器密钥交换
SSL 和 TLS 基本部分 3.6.2:
2.Server Key Exchange
SSL and TLS Essential section 3.6.2:
...密钥信息使用服务器证书中包含的公钥进行签名.
...the key information is signed using the public key contained in the server's certificate.
布鲁诺写道，
Bruno wrote,
同样，您并没有真正使用公钥签署某些东西.您只需要其中一个密钥即可签名，那就是私钥.您使用匹配的公钥验证签名....用公钥签名"是一种不寻常且具有误导性的表达方式.
Similarly, you don't really sign something with a public key. You only need one of the keys to sign, and that's the private key. You verify the signature with the matching public key. ... "signing with a public key" is an unusual and misleading expression.
我认为布鲁诺是对的.原因如下，
I think Bruno is right. The reasons are as follows,
RFC4346 部分 7.4.2.服务器证书
RFC4346 section 7.4.2. Server Certificate
它必须包含一个与密钥交换方法相匹配的密钥，如下所示.
It MUST contain a key that matches the key exchange method, as follows.
所以服务器首先在证书中发送 6 种公钥类型之一.
So the server sends one of 6 public key types in a certificate first.
服务器选择 3 种密钥交换方法之一，并使用其私钥对加密信息进行签名(加密).
The server chooses one of 3 key exchange methods, and uses its private key to sign(encrypt) cryptographic information.
客户端收到加密后的密码信息后，会使用ServerCertificate消息中的公钥进行验证(解密)，得到明文的密码信息.
When the client receives the encrypted cryptographic information, it will use the public key in ServerCertificate message to verify(decrypt) and get the plain-text cryptographic information.
对吗?
推荐答案
在公钥加密中:
- 私钥用于签名和解密/解密.
- 公钥用于验证签名和加密/加密.
请参阅TLS 规范词汇表:
公钥加密:一类使用双密钥密码的密码技术.用公钥加密的消息只能用关联的私钥.相反，用私钥可以用公钥验证.
public key cryptography: A class of cryptographic techniques employing two-key ciphers. Messages encrypted with the public key can only be decrypted with the associated private key. Conversely, messages signed with the private key can be verified with the public key.
你不能用私钥加密或用公钥解密，不是因为数学原因，而是因为它没有意义.加密的定义/a>:
You cannot encrypt with a private key or decrypt with a public key, not for mathematical reasons, but because it doesn't make sense w.r.t. the definition of encrypt:
将普通语言或其他数据转换为代码；隐藏通过将信息转换成一种形式来表达信息的意义不知道秘诀就无法解释解释，称为关键；进行编码.
To convert ordinary language or other data into code; to hide the meaning of a message by converting it into a form that cannot be interpreted without knowing the secret method for interpretation, called the key; to encode.
在您使用私钥加密"的情况下，您实际上是在加密".确实是数据，但是将消息恢复为原始形式所需的东西并不是秘密.因此，在这种情况下谈论加密是没有意义的.在这个阶段，它背后的数学运算是否可以以一种或另一种方式起作用并不重要.
In a situation where you "encrypt with the private key", you effectively "scramble" the data indeed, but what's required to turn back the message into its original form is not a secret. Hence, it doesn't make sense to talk about encrypting in this context. Whether the mathematical operations behind it may work one way or the other doesn't matter at this stage.
同样，您并没有真正使用公钥签署某些东西.您只需要其中一个密钥即可签名，那就是私钥.您使用匹配的公钥验证签名.
Similarly, you don't really sign something with a public key. You only need one of the keys to sign, and that's the private key. You verify the signature with the matching public key.
说使用证书签名"是很常见的(即使在 TLS 规范中)，而真正暗示的是使用与证书匹配的私钥计算签名.在许多情况下，不是特别是 TLS，证书本身与签名一起进行通信(是否选择信任该证书是另一回事).
It's quite common (even in the TLS specification) to say "signing with a certificate", when what's really implied is computing the signature with the private key matching the certificate. In many cases, not specifically TLS, the certificate itself is communicated along with the signature (whether-or-not one chooses to trust that certificate is another matter).
诸如使用您的证书进行身份验证"之类的表达方式；或使用您的证书签名"通常是可以接受的，只要您理解证书"；在那里用于缩短证书及其私钥"，并且实际上它是这些操作所必需的私钥.
Expressions such as "using your certificate to authenticate" or "using your certificate to sign" are generally acceptable, so long as you understand that "certificate" is used there to shorten "certificate and its private key", and that it's in fact the private key that's necessary for those operations.
我没有你引用的书，但这个引用听起来有误导性或不正确(可能在这里断章取义):
I don't have the book you're quoting, but this quote sounds misleading or incorrect (perhaps taken out of context here):
...服务器证书中的公钥将仅用于验证其(服务器)身份.
...the public key in the server's certificate will only be used to verify its(server) identity.
服务器证书中的公钥不用于验证服务器本身的身份.它的作用是确保只有拥有相应私钥的某人/某物才能破译您使用此公钥加密的内容:在这种情况下(经过身份验证的密钥交换)，服务器将证明的 pre-master-secret它通过根据它已设法破译的 pre-master-master 生成正确的 Finished 消息来向客户端了解.
The public key in the server certificate isn't used to verify the server's identity itself. What it does is ensuring that only someone/something with the corresponding private key will be able to decipher what you've encrypted with this public key: in this case (authenticated key exchange), the pre-master-secret which the server will prove it knows to the client by producing the correct Finished message, based on the pre-master-master it has managed to decipher.
身份绑定由证书本身完成，是公钥、一些标识符(例如，主题 DN 和主题备用名称)以及可能的各种其他属性(例如，密钥使用，...)的签名组合.身份验证的这一侧(即检查此证书属于谁)是通过验证证书的完整性以及您信任它所说的内容(通常是 PKI)以及通过验证它所属的身份确实是您的身份来建立的想要连接到(主机名验证).这是通过使用证书颁发机构 (CA) 或外部机制验证证书签名本身来完成的，例如，如果您使用您在证书范围之外的知识明确授予给定证书的例外(可能是自签名)证书所属的PKI.此步骤与 TLS 规范相当独立，尽管您需要将所有这些部分组合在一起以确保通信安全.
The identity binding is done by the certificate itself, with is the signed combination of the public key, some identifiers (e.g. Subject DN and Subject Alternative Names) and possibly various other attributes (e.g. key usage, ...). This side of the identity verification (i.e. checking who this certificate belongs to) is established by verifying the integrity of the certificate and that you trust what it says (usually PKI), and by verifying that the identity it belongs to is indeed the one you wanted to connect to (host name verification). This is done by verifying the certificate signature itself using a Certification Authority (CA) or by an outside mechanism, for example if you have explicitly granted an exception for a given certificate (possibly self-signed) using knowledge you have outside the scope of the PKI to which the certificate belongs. This step is rather independent of the TLS specification, although you'll need all these pieces together to make the communication secure.
这句话也有类似的问题(同样，可能断章取义):
There's a similar problem with this quote (again, possibly taken out of context):
...密钥信息使用包含在服务器的证书.
...the key information is signed using the public key contained in the server's certificate.
虽然说用证书签名"；是一个常见的表达方式(如上所述)，我会说使用公钥签名"；绝对令人困惑，因为公钥"是通常用于与私钥"形成对比，它实际上是用于签名的 私钥.虽然 TLS 规范(第 F.1.1.2 节) 谈论使用证书签名"；在一些地方，用公钥签名"；是一种不寻常且具有误导性的表达方式.
Although saying "signed with a certificate" is a common expression (as explained above), I'd say "signing using the public key" is definitely confusing, since "public key" is normally used in contrast to "private key", and it's really the private key that's used for signing. While even the TLS specification (Section F.1.1.2) talks about "signing with a certificate" in a few places, "signing with a public key" is an unusual and misleading expression.
我不确定是否(解密)"和(加密)"在书中或您的补充:
I'm not sure whether "(decrypt)" and "(encrypt)" are in the book or your additions:
服务器证书中的公钥可用于验证(解密)服务器的身份并签署(加密)密钥information(,则客户端将使用密钥信息进行加密pre_master_secret)
the public key in the server's certificate can be used to verify(decrypt) the server's identity and sign(encrypt) the key information(,then the client will use the key information to encrypt pre_master_secret)
您实际上验证您正在与该证书标识的实际服务器对话，因为它是唯一能够解密您使用其公钥(在客户端密钥交换消息中)加密的内容的服务器.
You actually verify you're talking to the actual server identified by that certificate because it's the only one capable of deciphering what you've encrypted with its public key (in the client key exchange message).
客户端验证服务器证书后，加密一个
pre_master_secret 与服务器的公钥.通过成功
解码 pre_master_secret 并生成正确的成品
消息，服务器证明它知道私钥
对应服务器证书.
After verifying the server's certificate, the client encrypts a
pre_master_secret with the server's public key. By successfully
decoding the pre_master_secret and producing a correct finished
message, the server demonstrates that it knows the private key
corresponding to the server certificate.
你最后问的并不完全有道理:
What you're asking at the end doesn't completely make sense:
我知道公钥可以用来验证服务器的身份(证书消息)，但我无法理解公钥为什么可以用来签名关键信息，因为客户端没有对应的私钥，客户端如何验证关键信息?
I know the public key can be used to verify server's identity(Certificate message), but I can't understand the public key why can be used to sign the key information, because the client doesn't have the corresponding private key, how does the client verify the key information?
公钥不用于验证服务器的身份.您验证您正在与具有与之前提供的证书匹配的私钥的服务器交谈，因为它能够解密预主密钥并产生正确的完成消息.
The public key isn't used to verify the server's identity. You verify that you're talking to the server who has the private key matching the certificate it presented earlier by the fact it was able to decipher the pre-master-key and produce the correct finished message.
编辑 2:
在您进行编辑后，您似乎仍在使用sign(encrypt)"；和验证(解密)"好像加密与签名相同，验证与解密相同.我再次建议您停止进行这些关联:这是 4 种不同的操作.虽然使用 RSA 时数学可能相同，但这不适用于 DSA，它只是一个签名算法(所以只签名/验证).
Following your edit, it seems that you're still using "sign(encrypt)" and "verify(decrypt)" as if encrypting was the same as signing and verifying was the same as decrypting. I would suggest once again that you stop making these associations: these are 4 distinct operations. While the maths may be the same when using RSA, this doesn't work for DSA, which is only a signature algorithm (so signing/verifying only).
当客户端收到加密的密码信息时，它将使用 ServerCertificate 消息中的公钥验证(解密)并获取明文密码信息.
When the client receives the encrypted cryptographic information, it will use the public key in ServerCertificate message to verify(decrypt) and get the plain-text cryptographic information.
客户端在握手期间没有收到任何加密数据(只有签名数据).
The client doesn't receive any encrypted data during the handshake (only signed data).
为了更好地理解，您应该首先尝试了解 Diffie-Hellman 及其临时变体(对于 DHE 密码套件)工作.(在实践中，我不会过多关注非临时 DH_RSA/DH_DSS 密码套件.老实说，我不确定它们是否被广泛使用.我没有看到任何具有必要 DH 属性的证书示例，并且这些密码套件不在 OpenSSL 支持的列表中 或 Java 7. DHE/EDH 更为常见，并且不需要证书中的特殊属性.)
For a better general understanding, you should start by trying to understand how Diffie-Hellman and its ephemeral variant (for DHE cipher suites) work.
(In practice, I wouldn't focus too much on non-ephemeral DH_RSA/DH_DSS cipher suites. To be honest, I'm not sure whether they're much used. I haven't seen any example of certificate with the necessary DH attributes, and these cipher suites are not in supported lists by OpenSSL or Java 7. DHE/EDH are much more common, and don't require special attributes in the certificate.)
如果您使用RSA密钥交换算法，客户端将加密客户端密钥交换消息中的pre-master-key；如果它使用其中一种 DH 密钥交换算法，它将发送其 DH 参数，以便客户端和服务器可以就预主密钥达成一致(在这种情况下，客户端将检查服务器的 DH 参数是否来自正确的服务器通过验证预先发送的服务器密钥交换消息的签名).查看客户端密钥交换消息的描述:
If you use an RSA key exchange algorithm, the client will encrypt the pre-master-key in the client key exchange message; if it's using one of the DH key exchange algorithms, it will send its DH parameters so that client and server can agree on a pre-master-key (in this case, the client will have checked that the server's DH parameters come from the right server by verifying the signature of the server key exchange message sent beforehand). See description of the Client Key Exchange Message:
通过此消息，设置了预主密钥，尽管直接传输 RSA 加密的秘密或由Diffie-Hellman 参数的传输，这将允许每个方同意相同的 premaster secret.
With this message, the premaster secret is set, either though direct transmission of the RSA-encrypted secret or by the transmission of Diffie-Hellman parameters that will allow each side to agree upon the same premaster secret.
关于其他方面:
证书只是一个私钥签名(加密)的消息，它还包含其他人(例如，客户端)的公钥，因此客户端应使用其受信任的服务器公钥副本(通常，Web浏览器预先包含了几十个这样的证书)，而不是服务器证书中的公钥，用于验证服务器的身份.
a certificate is only a private-key-signed(encrypted) message that also contains someone else's(e.g., a client ) public key, so a client should use its trusted copy of the server's public key (usually, web browsers include dozens of these certificates in advance), instead of the public key in the server certificate, to verify the server's identity.
验证您正在与正确的服务器通话时会发生三件事:
Three things happen to verify you're talking to the right server:
- 如果握手成功，则可以保证您正在与具有服务器证书消息中提供的证书私钥的服务器通信.如果使用 RSA 密钥交换，这是因为它是唯一可以解密客户端在客户端密钥交换消息中发送的内容的事实(因为它是用公钥加密的)；如果使用 EDH 密钥交换，这是有保证的，因为服务器在服务器密钥交换消息中签署了它的 DH 参数，可使用此公钥进行验证.
- 您可以验证证书本身.这与 TLS 的工作方式完全无关，但通常使用 PKI 来完成:客户端有一个预设的可信 CA 证书列表，其公钥可用于验证它不知道的新证书(例如服务器证书)中的签名.验证该签名允许客户端将该公钥绑定到一个标识符(主题 DN 和/或替代名称).这为您提供了客户端正在与之通信的服务器的身份.
- 主机名验证:知道您正在与向您提供对其有效的真实 ID 的人交谈是不够的，您还需要检查该名称是否与您打算连接的服务器匹配.
- The handshake itself, if successful, guarantees that you're talking to the server that has the private key for the certificate it has presented in the server certificate message. If using RSA key exchange, this is guaranteed by the fact it's the only one that can decipher what the client sent in the client key exchange message (since it's encrypted with the public key); if using an EDH key exchange, this is guaranteed because the server signed its DH parameters in the server key exchange message, verifiable with this public key.
- The fact that you can verify the certificate itself. This is rather independent of how TLS works, but it's usually done using a PKI: the client has a pre-set list of trusted CA certificates, the public keys of which can be used to verify the signature in new certificates it doesn't already know about (such as the server certificate). Verifying that signature allows the client to bind that public key to an identifier (Subject DN and/or alt. name). This gives you the identity of the server to which the client is talking.
- The host name verification: it's not good enough to know that you're talking to someone who's presented you a genuine ID that's valid for them, you also need to check that the name matches the server you intended to connect to.
当我说服务器证书中的公钥不用于验证服务器本身的身份"时，我的意思是公钥不用于验证第 2 点和第 3 点.第 1 点保证您'正在与具有与其提供的证书匹配的私钥的服务器交谈，但它不会告诉你这是谁.验证服务器的身份直到第 2 点，以便能够将标识符绑定到该密钥/证书.
When I said "The public key in the server certificate isn't used to verify the server's identity itself", I meant that the public key wasn't used to verify points 2 and 3. Point 1 guarantees you that you're talking to the server that has the private key matching the certificate it presented, but it doesn't tell you who this is. Verifying the identity of the server is is up to point 2, so as to be able to bind an identifier to that key/cert.
这篇关于SSL握手期间可以使用一个公钥加密和解密数据吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
