Moving blog: Principle summary https
A recent project on the company's servers some internal interfaces require the use of https, so take the time to study the wave. Http we know not to encrypt data during transmission, there is a big security risk in the transmission of sensitive information. Therefore, https on the basis http added SSL (Secure Sockets Layer) encryption to protect the security of data transmission. Today, the use of TLS is actually an upgraded version of SSL. Specific concepts can refer to Wikipedia https
https Introduction
1.https principle explore
Https secure information protection mechanism, in fact, can be summarized in one sentence: client and server to negotiate a symmetric secret key by asymmetric encryption, then CS used at both ends of the symmetrical secret key to decrypt the encrypted data, complete the data exchange. Therefore, when the data transfer is actually taking the symmetric encryption. Certainly understand the premise of this sentence, you need to understand the symmetric and asymmetric encryption principle, we are not discussed.
Principle Overview
The general procedure of SSL encryption mechanism:
- client sends a request
- server certificate is returned
- and remove the client to verify the certificate's public key
- client generates a random number, and encrypts it using the server public key, the resulting ciphertext to a server
- server decrypts using the private key to obtain the random number
- Both ends of each generate a random number by a symmetric keys, the negotiation is completed
Digital certificates and digital signatures
Prior to the detailed description shook hands, I would like to talk about the causes and principles of digital digital certificates, digital certificates are the core of the whole SSL encryption and tie. First, prior to transmission using asymmetric encryption, the client needs to obtain the server's public key, where the presence of an attack, i.e., an intermediate party uses a public key to replace the server's own public key to the client, then through its own private key acquired asymmetric encryption of content sent by the client, in order to achieve eavesdropping and tampering. To facilitate understanding, the Internet has brought a picture with me directly, as shown below.
In order to prevent the acquisition of third-party public process was the destruction of substitution and the like, so there will be a mechanism certificate, signed picture shows the server certificate, and under the general process of verification.
Certificate contains three parts
- Contents of the certificate (public key server, server information, etc.)
- Encryption algorithm (encryption algorithm, hash algorithm)
- 密文（使用哈希算法计算证书内容得到哈希摘要，再使用CA私钥加密该摘要即得到密文，该过程称为数字签名）
验证数字证书
- 客户端验证服务器证书时，需要获取到你的上一级CA证书，从而得到取CA公钥，使用CA公钥对证书中的密文解密得到哈希摘要，同时客户端使用同样的哈希算法对服务器证书内容计算得到另一个哈希摘要，若这两个摘要相等，则证明证书合法。
上述的哈希签名也称为数字指纹法，该方法的精髓在于，相同的明文通过哈希计算得到的摘要，一定是相同的，而只要两份明文只要有一丝丝区别，其对应的哈希值也是不同的。因此，若第三方替换了证书中的公钥，根据证书内容计算出的新的摘要一定与密文中的摘要有所差异的，故可以轻松地判断证书不合法。
疑问
（1）既然是使用上级CA证书来验证服务器证书，那如何证明上级CA证书的合法性？
- 这涉及到一个证书信任链的问题。上级证书通过更高一级的CA根证书来确定其合法性，这是一个递归向上的过程，直到最顶层根证书。顶层CA根证书是整个安全体系的根本。
（2）前文提到的攻击方式，只替换公钥显然是不行，那如果第三方把整个证书都替换成自己的证书（因为CA机构可以给任何人签名，黑客也可以），这样的话客户端的验证是不是可以通过？
- 答案当然是否定的，很简单，因为证书内容里的服务器信息是唯一的、不可复制的，例如域名，若替换整个证书，域名也会变成黑客自己的域名，浏览器不会接受域名和请求内容不匹配的证书。比如说，浏览器请求了 baidu.com，结果返回了个google.com的证书，毫无疑问会立即排除掉。
保证了服务器公钥安全抵达客户端手中，后续的对话秘钥的协商便也能顺理成章地进行。因此https所采用的SSL机制是绝对安全的，几乎没有人能够破解。当然，有得必有失，https花费的开销也远高于http。
SSL握手过程
https握手原理图
理解了上文所讲的证书机制，其实SSL加密机制也基本容易理解了，下面细究一下SSL握手过程，此处结合上方交互原理图进行分析
（1） Client Helllo。客户端发送初次请求，请求内容包含版本信息，加密套件候选列表，压缩算法候选列表，随机数random_1，扩展字段等信息，以明文传输；
（2）服务器选择客户端支持的加密套件、压缩算法、协议版本等，生成随机数random_2；
（3）服务器将上述算法以及随机数等发送给客户端；
（4）服务器发送服务器数字证书；
（5）客户端接收服务器选择的算法以及随机数等，验证数字证书。若证书验证通过，或者用户接受了不可信证书，客户端获取服务器公钥，同时会生成随机数random_3，并使用服务器公钥加密该随机数得到密文；
（6）客户端将第五步得到的密文传给服务器，由于公钥加密的内容只能使用私钥解开，所以random_3无法被窃听；
（7）Change cipher Spec。客户端通知服务器协商完成；
- 此时客户端已存有三个随机数random_1、random_2和random_3，前两个是可以被截获的，第三个是私密的，根据这三者可计算得出对话秘钥，即enc_key=Fuc(random_1, random_2, random_3)
（8）客户端结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，并使用对话秘钥enc_key和算法将其加密，得到密文encrypted_handshake_message，将其发送给服务器进行验证；
（9）服务器使用私钥解密第六步得到的密文，得到随机数random_3，此时服务器也拥有了三个随机数random_1、random_2和random_3，同样可计算出对话秘钥enc_key，至此双方共享对称加密秘钥的目的已达成；计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;
(10) Similar 7 and 8, the server notifies the client negotiation is completed, and calculates the transmission encrypted_handshake_message. In the same way the client verification encrypted_handshake_message, the handshake is complete.
After completion of the handshake, the server and client use the same secret key dialogue enc_key, the message content is encrypted for secure communication.