https

最新推荐文章于 2022-08-26 12:24:50 发布

weixin_30559481

最新推荐文章于 2022-08-26 12:24:50 发布

阅读量1.1k

点赞数

原文链接：https://juejin.im/post/5d26fd3ff265da1b925405a6

版权

https解决的问题

因为在网络传输中，http是使用明文传输的，很容易被人劫持或者篡改数据。为了能让消息能在网络中放心的传输，在http层之下加入安全套接字层SSL，这就是https. HTTPS协议的主要作用可以分为两种：

建立一个信息安全通道，来保证数据传输的安全；
确认网站的真实性。

那么https是如何对信息做加密的呢

传输过程中客户端和服务端相互通信使用的是对称加密，因为对称加密比非对称加密速度快
既然是对称加密，那 a. 客户端和服务端需要使用同一套公钥 b. 连接到同一个服务端的多台客户端之间又不能使用同一套公钥
那么问题就是如何在传输之前把加密用的公钥给到客户端和服务端 a. 服务端开发的时候，需要向认证中心CA获取整数，也就是让CA使用它的私钥对服务端的公钥进行加密操作 b. 在客户端发送握手的时候，服务端将证书发放给客户端 c. 每个机器系统中都自带一些公认的CA的受信任证书，这些证书中含有可以解开对应CA认证过的服务端的证书--> 进行服务端证书解密 d. 这个时候就可以得到握手过程中使用的非对称加密的公钥了 e. 拿到这个公钥只是为了生成后续传输过程中的公钥的第一步 f. 客户端拿着上面的说的公钥，服务端拿着自己的私钥，两边进行非对称加密的传输，沟通生成后续传输使用的对称加密的公钥。

https握手的过程：

下面是别的网站上看到的，觉得写得很好，直接拷贝过来了

client_hello，客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下：支持的最高TSL协议版本version，从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，当前基本不再使用低于 TLSv1 的版本; 客户端支持的加密套件 cipher suites 列表，每个加密套件对应前面 TLS 原理中的四个功能的组合：认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验); 支持的压缩算法 compression methods 列表，用于后续的信息压缩传输; 随机数 random_C，用于后续的密钥的生成; 扩展字段 extensions，支持协议与算法的相关参数以及其它辅助信息等，常见的 SNI 就属于扩展字段，后续单独讨论该字段作用。
server_hello+server_certificate+sever_hello_done a. server_hello, 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 等，其中随机数用于后续的密钥协商; b. server_certificates, 服务器端配置对应的证书链，用于身份验证与密钥交换; c. server_hello_done，通知客户端 server_hello 信息发送结束;
证书校验客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括如下：证书链的可信性 trusted certificate path，方法如前文所述; 证书是否吊销 revocation，有两类方式离线 CRL 与在线 OCSP，不同的客户端行为会不同; 有效期 expiry date，证书是否在有效时间范围; 域名 domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析;
client_key_exchange+change_cipher_spec+encrypted_handshake_message a. client_key_exchange，合法性验证通过之后，客户端计算产生随机数字 Pre-master，并用证书公钥加密，发送给服务器; b. 此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，计算得到协商密钥; enc_key=Fuc(random_C, random_S, Pre-Master) c. change_cipher_spec，客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信; d. encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证;
change_cipher_spec+encrypted_handshake_message a. 服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master); b. 计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性; c. change_cipher_spec, 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信; d. encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端;
握手结束客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成;
加密通信开始使用协商密钥与算法进行加密通信。