HTTPS握手

[bibi7]

一次安全可靠的通信——HTTPS原理

其他讨论

[bibi7]

1. CA用自己的私钥对server的公钥进行加密
2. client用CA的公钥对刚才CA的加密进行解密，得出server的公钥和明文内容
3. client用得到的信息进行一次hash操作，并且将其用server的公钥一起加密发送给server
4. server用自己的私钥解密收到的信息，同时根据hash对比文件完整性。

当然这里并不会直接请求CA。server将公钥放在数字证书中。只要证书是可信的，公钥就是可信的

TSL/SSL四次握手 （加上TCP，一次HTTPS的握手共计可达七次）

第一步 client hello阶段

client向server发送建立ssl连接请求，并且附送如下信息：

1. 支持的协议版本，比如TLS 1.0版。

2. 一个客户端生成的随机数（client-random），稍后用于生成"对话密钥"。

3. 支持的加密方法，比如RSA公钥加密。

4. 支持的压缩方法。

第二步 server hello阶段

1. 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。

2. 一个服务器生成的随机数（server-random），稍后用于生成"对话密钥"。

3. 确认使用的加密方法，比如RSA公钥加密。

4. 服务器证书。

第三步 客户端回应

客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后发送如下：

1. 发送第三个随机数（pre-master key）。该随机数用服务器公钥加密，防止被窃听。

2. 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

3. 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

第四步 服务端回应

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"（也就是经过对称加密的密钥）。然后，向客户端最后发送下面信息：

1. 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

2. 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。

有的文章会把握手分为五步，主要就是第四步在获取第三位随机数和生成会话密钥的时候进行了一下拆分，其实个人感觉都差不多(:з」∠)

参考： SSL/TLS协议运行机制的概述 图解SSL/TLS协议 HTTPS加密过程详解