SSL / TLS protocol detailed (in) - Certificate Authority

ginove / 2018-08-05 18:53:13 / Views 4732 Technical Articles Technical Articles Top (2) step on (0)

This translation from: https://www.wst.space/ssl-part-3-certificate-authority/

On one , we discussed about the Diffie Hellman algorithm SSL / TLS key exchange. We believe that eventually need a third party to verify the authenticity of the server and presents a certificate authority mechanisms. Blog series The last two sections of the main elements:

TLS encryption client - server communication and prevent man in the middle attacks.

The difference between the encoding, encryption and hashing

TLS to encrypt data and the public key infrastructure to exchange symmetric key using symmetric key encryption.

Key exchange algorithm itself may be spoofed by an attacker. Therefore, we need a trusted authority to verify the authenticity of the server.

Certificate needs of the organization

Imagine the client browser is attempting to communicate with the Web server, and you want to start TLS channel. From the above last point of view, in order to prove the identity of the server, the client browser must have the server's public key. However, we can not be stored in the browser all public sites to be accessed, and because every minute a new website was born, and therefore need to be updated every minute.

Solution to this problem is the use of the certificate authority mechanism. When we install the browser or operating system, it will be accompanied by a set of Certificate Authority, such as DigiCert. When the browser comes with DigiCert, which means that the browser has a public key DigiCert, the site can request certificates and signatures to DigiCert. Therefore, DigiCert will use DigiCerts private key cryptographic signature on the server certificate. When we issue a connection, the server sends its public key embedded in the certificate. Because the browser has DigiCert's public key, so you can verify the signature on the server DigiCert certificate, as well as notes written on the certificate server's public key can be trusted.

If you do not fully understand this concept, please do not worry. Let's analyze one by one and then to refine the process.

Definition digital signature

To understand the concept of a certificate issued by the organization, we can look back a few decades ago the traditional mail system and the mail analogy. Imagine, Alice owns a company, and Bob is the company's employees, Alice wanted to send a secret message to Bob, Alice as CEO, the message will be drafted and put in the mailbox, it will go through several post offices and several postman and eventually reach the hands of Bob's, Bob can open and read it, but how to ensure that the message is really from Bob Alice? There are two possibilities:
1. Eve attacker can use any of the contents of draft messages, the sender's address is set to address similar to Alice's office and forwarded to Bob.
2.Eve can be an intermediary, such as an intermediate post office employee, he can open the message before the message reaches Bob, he can even rewrite the content as they wish, and then resend it to Bob. In both cases, we can not ensure that you receive the message Alice is valid. This time what we will do? View signature, Alice can use the signature stamp when released in the mail to Bob, Alice's company seal can be used to verify the authenticity and integrity of e-mail. Because Alice's is a recognized entity, if there is a message signature, we can trust it, this is a certificate issued by the agency doing things.

Certification Authority of technology

We know that PKI is used to exchange session keys in the TLS protocol , this procedure is called authentication process. In order to perform the authentication process, the server sends to the client needs the public key, but the middle attacker can obtain the public key and replace it with its own public key, which is very dangerous, because customers never know the public key in transit whether a third party was tampered with. The client uses the public key to encrypt a symmetric key attacker and forwarded unknowingly, because the attacker holds the corresponding private key, he can decrypt and steal data.

In order to make the client trust received public key, introduce the concept of CA's. CA's work as follows. Assuming the server https://example.com require TLS certificates.
1. example.com server TLS certificate request from the CA, for example Digicert.
2.Digicert example.com will create a certificate, the certificate will contain the necessary data, such as server name, and public key server.
3.Digicert creates data (certificate) hash value, and use your own private key to encrypt it.
4. browser and operating system comes Digicert and other public authorities.
5. When the browser receives the signed certificate, it will use the public key to generate a hash value from the signature, it will also generate data using a hash algorithm Hash (certificate) is specified in the certificate, if the two hash values match , the signature verification is successful and that the certificate is authentic.
6. Now you can use the browser specified in the certificate of public example.com continue the authentication process.
Here, we can Digicert called Root CA .

If an attacker tampering with a certificate will happen

After receiving the certificate, the browser verifies that the server name, the validity of the certificate, signature and other data. Imagine a certificate if the attacker uses his custom certificate instead of example.com, and the server name field validation fails, the browser will be disconnected immediately.

另一种情况是，如果攻击者保留所有这些数据并用公钥替换公钥会发生什么？在这种情况下，当浏览器尝试从证书数据重新生成哈希时，由于数据被篡改，他将获得不同的哈希值，从而数据和签名计算出的哈希值将不匹配。

为了绕过上述机制，攻击者需要使签名来匹配数据，为了做到这点，他需要拥有Digicert的私钥（最初为example.com签发并签署了证书），所以攻击者此时会失败，因为他可以创建的唯一签名来自他的私钥，我们的浏览器并不会信任这一点。浏览器的证书存储区也不会有攻击者的公钥，并且在发生此类攻击时会显示证书异常，如下所示。

您可能已经注意到在尝试为浏览器设置代理时，发生私密错误是因为代理工具在充当中间人，并向浏览器显示自己的证书。如果您信任该证书，则可以点击继续；或者，您可以下载代理证书工具并将其添加到浏览器内的受信任机构列表中，这样，您可以在代理工具中以纯文本形式查看加密数据。

信任链

我们知道证书颁发机构是为服务器创建并签署证书，很少有组织从事这项工作，即Digicert，Geotrust，Comodo等。如果他们正在为所有服务器签署证书，则必须为所有签名使用相同的私钥，如果它被盗，那么所有的信任都会丢失。为了解决这个问题并增加更多的平均信息量，引入了中间CA(intermediate CA)的概念。

这个想法很简单。Charles是一个值得信赖的人，并曾经收到了Alice的签名邮件，如果Bob看到Charles的签名，他就会信任这封邮件。现在，Smith是Charles信任的另一个人，如果Smith代表Charles签署了一封来自Alice的邮件，那么Bob将不会一直相信它。这里就出现了信任链：Bob相信Charles和Charles信任Smith，因此BOb可以信任Smith。类似地，intermediate CA是Root CA信任的证书颁发机构。 example.com的证书将由intermediate CA颁发，intermediate CA还将具有将由Root CA签名的证书，并且只有Root CA的详细信息会被存储在浏览器的证书库中。

因此，在证书验证期间，浏览器信任Digicert Root CA和Digicert Root CA信任intermediate CA，因此浏览器可以信任intermediate CA。在下图中，您可以看到层次结构，DigiCert SHA2 High Assurance Server CA是中间证书颁发机构和 DigiCert High Assurance EV Root CA。

此层次结构的另一个优点是Root CA无需始终在线。

数字签名的数学算法

我们在理解密钥交换过程的同时讨论了Diffie-Hellman算法。类似地，也有许多算法可用于数字签名，这写会在服务器证书中指定。请参阅下面的example.com证书。

我不会多谈核心的数学知识，因为它很无聊，而且我也很菜。证书显示带有RSA加密的SHA-256。 RSA是一种流行的签名算法，我会在这里讨论。与任何其他非对称加密算法一样，RSA也具有公钥 - 私钥对。这里的区别在于，签名（将其视为加密）是通过使用intermediate CA的私钥来完成的。并且签名验证（将其视为解密）由浏览器使用相应的公钥完成的。换句话说，RSA签名不是RSA解密。如果您有兴趣制作实用的RSA签名，请参阅此处。

RSA将在签署之前会对证书进行哈希处理，这有一个很重要的原因。如果您深入了解算法，您将知道如果数据长度超过其密钥长度，RSA无法加密数据。假设我们使用2048位密钥进行加密，那么证书数据不应超过2048位，也就是255个字节，这并不总是可行的，因为证书包含很多信息。因此，在加密之前，在证书上应用散列函数，该函数生成指定长度的唯一随机字符串。在example.com的情况下，使用SHA-256哈希算法。如果您有兴趣，可以进一步研究RSA的这种限制。

浏览器如何实际验证给定服务器证书的有效性

我们知道服务器使用中级证书颁发机构的签名，因此，在与浏览器通信时，服务器将共享两个证书：一，包含服务器的公钥，即实际的服务器证书；二，由Root CA颁发的intermediate CA证书。以下是验证链的图示。

在签名验证期间，浏览器首先使用已经存储在浏览器中的Root CA的公钥来验证中间证书的数字签名，如果成功，浏览器现在可以信任中间证书及其公钥。现在使用此公钥，浏览器将验证原始服务器证书的签名，该组织可以注册为intermediate CA，以便为其域签署证书。比如谷歌。

谷歌互联网管理局G3是一个由全球认证Root CA -R2信任的intermediate CA，这意味着，Google可以使用此intermediate CA验证其域名，由于谷歌浏览器是全球认证Root CA认证的，其他浏览器将信任它。必须注意的是，谷歌有权单独签署他们的域名。这可以防止Google为Microsoft签署证书。

后续

到目前为止，我们已经讨论了证书颁发机构和TLS协议的原理。在本系列的下一部分中，我们将实际检查整个TLS通信。