HTTPS协议

HTTPS协议是在HTTP协议的基础上，增加了SSL/TLS加密协议，也就是说，在数据传输之前会对数据加密。

为什么使用HTTPS

防范偷窥

偷窥

防范篡改

篡改

使用HTTPS的优缺点

优点

• 数据加密，可以防止运营商劫持（无法避免DNS劫持）。
• 防止中间人攻击。
• SEO方面，可以提高网站排名。

缺点

• 连接建立增加了2个RTT。
• 需要对数据加密，增加了耗时。

HTTPS的建立连接过程

TCP三次握手

• TCP的三次握手是必不可少的。

• 后续则根据不同算法来交换秘钥。

  
  TCP

使用RSA秘钥交换

RSA exchange secret

• 客户端生成48字节的预主秘钥（pre_master_secret）。
• 用证书的公钥加密。
• 发送给服务端，服务端收到后用私钥解密。
• 双发用预主秘钥生成主密钥。

使用DH秘钥交换

DH算法原理

• 通信双方（甲、乙）约定好算法参数：一个素数p作为模数、一个素数g作为基数，两者都可对外公开。
• 甲选取一个秘密的自然数a，计算A = g^a % p，然后将A发送给乙。
• 乙选取一个秘密的自然数b，计算B = g^b % p，然后将B发送给甲。
• 甲用B和a计算出k = B ^ a % p，然后销毁掉自然数a。
• 乙用A和b计算出k = A ^ b % p，然后销毁掉自然数b。
• 双方都得到了相同的k，那么就实现了不传输任何关键数据的情况下，交换关键数据。
• 即使拿到p、g、A、B，但是推算a或b是很困难的，自然也无法推算k；DH算法是利用了求解“离散对数问题”的困难来保证安全（ECDH 依赖的是求解“椭圆曲线离散对数问题”的困难，计算会比DH更复杂）。
• ps：可以简单用p=23，g=5，a=6，b=8；来验证下，双方计算出来的k=4。

秘钥交换过程

DH

• 服务端（乙）约定好素数p、g以及自己的秘密自然数b，并计算B，然后将p、g、B传输给客户端。
• 客户端（甲）拿到p、g、B后以及自己选取的秘密自然数a，计算出A，然后用证书的公钥加密，传输给服务端。
• 服务端通过A和b计算出预主密钥k，并销毁b。
• 客户端通过B和a计算出预主密钥k，并销毁a。
• 完成预主密钥的交换。

消息的内容及作用

Client Hello

client hello

• 支持的协议版本
• 客户端随机数
• Session ID
• 所支持的密码套件
• 压缩数据
• 扩展名（extended_master_secret表示使用增强型主密钥）

密码套件

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

• TSL：使用的协议
• ECDHE：秘钥交换算法
• RSA：签名或验证算法
• AES_128_CBC：数据加密算法
• SHA：消息验证代码

Server Hello

server hello

• 约定使用的协议及版本
• 服务端随机数
• 约定使用的密码套件
• Sessoin ID
• 压缩数据

Server Certificate

server certificate

• 服务端返回给客户端的证书，客户端用根证书做验证。
• 其中包含了非对称加密算法的公钥。

Server Key Exchange

server key exchange

• 只有使用DH算法做秘钥交换才有的数据。
• 服务端计算的公钥B
• DH算法需要的参数（已做签名）
• ps：图中使用的是ECDHE算法，原理和DH相似。

Client Key Exchange

client key exchange

• ps：图中使用的是ECDHE算法。

RSA算法的Client Key Exchange

• 是用证书公钥加密后的pre master secret密文。

DH算法的Client Key Exchange

• 是通过DH算法计算出来的客户端公钥A。

Finished

Finished

• 在握手的最后，会发送Encrypted Handshake Message，目的则是让消息的接收者来判断整个握手过程中的数据是否完整、正确。
• 验证的内容是通过 PRF 算法计算出来的。

主密钥计算方法

master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)[0..47];

• pre_master_secret为上述秘钥交换算法所交换的预主密钥。
• ClientHello.random为Client Hello中的客户端随机数。
• ServerHello.random为Server Hello中的服务端随机数。
• 主密钥的长度是48字节。

增强型主密钥计算方法

master_secret = PRF(pre_master_secret, "extended master secret", session_hash)[0..47];

• master secret被extended master secret替换。
• ClientHello.random + ServerHello.random被session_hash替换。
• 需要Client Hello的扩展名中包含extended_master_secret，并且Server Hello的扩展名中返回extended_master_secret，才会使用此计算方法。

会话秘钥的计算方法

key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random +SecurityParameters.client_random);

• 用于数据传输的对称加解密。

HTTPS身份认证

• 客户端根据本地的根证书，验证从服务端来的证书信息，是否可信；如果可信，则使用证书中的非对称加密的公钥。

为什么需要证书验证

• 中间人可以替换掉服务端返回的证书为自己的证书，那么客户端使用的公钥其实是中间人的公钥。

为什么还有会其他（DH、ECDH等）算法作为秘钥交换算法？

• 攻击者，很有耐心，把所有嗅探到的传输数据都保存了下来。
• 攻击者，过了很久通过一些手段，拿到了证书的私钥。
  1、入侵系统
  2、利用协议的漏洞（如OpenSSL的漏洞）
  3、威逼利诱
  ……
• 在握手过程中，我们会通过证书公钥加密pre master secret，然后发送给服务端。
• 攻击通过私钥解密历史传输的pre master secret，然后计算master key。
• 那么历史所有的加密传输的数据都能解密拿到了o(╥﹏╥)o。

---

RSA算法交换秘钥，不支持向前保密，所以就有了DH、ECDH算法交换秘钥。

DH、ECDH怎么做到的向前保密

• 全程关键的数据没有网络传输，客户端的秘密自然数a、服务端的秘密数据b、以及双方计算出来的预主密钥k。
• 利用素数p、素数g、公钥A、公钥B，去推算a、b非常困难，所以也很难推算出k。
• a、b数据不会保存，用完即销毁，攻击者基本没可能获取到。
• 即使攻击者获取到了当前的a、b、并计算出了k，那历史的数据一样不能解密。