HTTPS原理解析

HTTPS

一些概念

http

概述

HTTP是一个客户端（用户）和服务端（网站）之间请求和应答的标准，通常使用TCP协议。其本身位于TCP/IP协议族的应用层。

特点

  - 客户端&服务器
  - 无连接
  - 无状态

密码学

• 对称秘钥算法

加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥，常见算法有：AES、DES、SM4。

• 非对称秘钥算法

需要两个密钥，一个是公开密钥，另一个是私有密钥；公钥用于加密，私钥则用作解密。使用公钥把明文加密后所得的密文，只能用相对应的私钥才能解密并得到原本的明文。公钥可以公开，可任意向外发布；私钥不可以公开。基于公开密钥加密的特性，它还能提供数字签名的功能，使电子文件可以得到如同在纸本文件上亲笔签署的效果。常见非对称算法有：RSA、DSA、SM2。

• 散列算法

是一种从任何一种数据中创建小的数字“指纹”的方法。散列函数把消息或数据压缩成摘要，使得数据量变小，将数据的格式固定下来。该函数将数据打乱混合，重新创建一个叫做散列值的指纹。常见算法有：MD5、SHA-256、SM3

SSL&TLS

百科给出的解释是：传输层安全性协议（Transport Layer Security）及其前身安全套接层（Secure Sockets Layer）是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。网景公司在1994年推出HTTPS协议，以SSL进行加密，这是SSL的起源。IETF将SSL进行标准化后即TLS。目前SSL/TLS已成为互联网上保密通信的工业标准。

https

HTTP over SSL/TLS，HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换资料的隐私与完整性。

HTTPS机制

证书制作的过程

一个网站如果要使用https，第一步就是找CA机构申请证书。简要流程如下

  1. 申请人服务器server,生成一对非对称秘钥server_prikey、server_pubkey
  1. 申请人把一些申请信息（使用者、有效期等）sever_info和server_pubkey递交给CA机构
  1. CA机构验证申请人身份后，对server_info+server_pubkey+ca_info(ca机构添加的一些信息)进行散列运算，得到server_hash
  1. CA机构使用自己的私钥ca_prikey 对server_hash进行签名，得到sign_server_hash
  1. CA机构根据sign_server_hash+server_pubkey+server_info+ca_info构建成证书server_cert，并下发给申请人
  1. 申请人配置证书到服务器server，一般情况下会开启443端口对外提供https的能力。

一些特殊的行业，处于多方面的顾虑，可能会搭建自己的CA服务，例如：各大银行、12306、硬件设备制造商等。目前国际上比较知名CA机构的根证书（CA的公钥）是预装在操作系统或浏览器的，如下图。

 

  现实中，网站的证书验证多数是通过证书链的机制实现的，操作系统预装的证书也都是证书链最上层的根证书，而我们申请到的证书，也多是二级证书机构颁发的。

http三次握手

以访问百度为例，查看三次握手的抓包数据，其中110.242.68.3是百度服务器地址，10.100.172.90是我本机的局域网地址（客户端）。

1、客户端发送syn：



2、服务器响应syn+ack



3、客户端发送ack



流程如下（网络取图）：

TLS的多次握手

仍旧以访问百度为例，查看https访问时，TLS的多次握手

2.1、客户端发送 client hello

        - Content Type: Handshake (22)
           - 0x16表示内容类型为握手协议
        - Version: TLS 1.0 (0x0301)
           - 使用TLS1.0
        - Random: 777cd47f33acca3e39c74b2aac641fc1b5bc7c64ff5436d944281495d38899a7
           - 随机数，4字节时间戳+28字节随机数，可以防重放
        - Session ID: d14d21a0d37f4987c087d2fca80c2beca15dd93d3c90c69fe30b1fb4870fa84f
           - sessionId，0-32字节随机数
        - Cipher Suites (18 suites)
           - 客户端支持的密码套件算法列表（优先级顺序）
        - Extension
           - 扩展信息

2.2、服务器响应 server hello

        - Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
           - 服务器根据客户端秘钥算法列表协商的秘钥
              - TLS 通讯协议类型
              - ECDHE 交换秘钥算法
              - RSA 身份验证算法，一般为证书使用的算法
              - AES 通信时的加密算法
              - HSA256 哈希算法，计算签名使用

** 2.3服务器下发公钥证书**

        

        - Certificates (3749 bytes)
           - 下发给客户端的证书，一般情况下如上图有两个证书，一个是根认证机构颁发给二级机构的证书，一个是二级认证机构颁发给百度的证书

2.4服务器下发交换秘钥参数、协商秘钥的公钥（非必须，使用ECDHE交换秘钥算法时需下发参数）

        - Named Curve: secp256r1 (0x0017)
           - 指定非对称秘钥算法的椭圆曲线
        - Pubkey:
           - 公钥
        - Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
           - 签名算法
        - Signature:
           - 签名

2.5服务端响应结束，因为有一些不确定响应，需要最后回复一次客户端响应完毕。



在服务器响应结束前还有可能还有一次Certificate Request请求，用于请求客户端公钥证书，适用用高安全性场景下的双向认证。

3、客户端请求，这一部分协议差异比较大，在TLS1.3中规定该步骤为最后一步，无需TLS1.2后续确认响应，但是百度使用的TLS1.2，也没有后续的确认操作了。

        - EC Diffie-Hellman Client Params
           - 协商秘钥客户端参数
        - Change Cipher Spec Message
           - 告知后续使用密文传输
        - Handshake Protocol: Encrypted Handshake Message
           - 密文，如果服务器能顺利解密则协商成功

4.1、服务器创建session ticket

        - Session Ticket:
           - 服务的生成的session ticket,session ticket包含sessionId和协商的加密参数以便连接重用。

4.2 服务端告知密文传输



**

        - Change Cipher Spec Message
           - 告知客户端以后使用加密通讯

4.3 服务器发送密文数据

        - Handshake Protocol: Encrypted Handshake Message
           - 使用协商秘钥加密后的密文数据

至此，tls整个协商过程结束

https总结

1. http syn握手建立tcp连接

2. 客户端开始tls握手

3. 服务端开始tls握手，并下发证书供客户端认证服务器身份

4. 客户端和服务端通过秘钥交换算法交换秘钥

5. 通过协商秘钥安全协商出对称秘钥key

6. 后续双方使用key加密传输的数据

7. 服务端创建session ticket，用于保持和恢复连接
   
   最后附上完整交互图，摘自网络，大致相同，待后续补充