HTTPS 初步介绍

背景：

非对称加密：

基于数学方法，生成一个公钥-密钥对，来对数据做加密-解密，被公钥加密的数据只能被私钥解密，

同样，被私钥加密的数据也只能被公钥解密。所以可以用别人公开的公钥加密一段信息然后发送出去，

只有拥有对应密钥的那个人才能解密。但是缺点是加密-解密的计算成本高，比较占用cpu资源

对称加密：

和非对称加密相比，只生成一个密钥，加密-解密都用这个密钥，所以需要通信双方都拥有该密钥才能正常加/解密，优点是计算成本低，加/解密速度比非对称加密快很多

HTTPS：

HTTP+SSL/TLS，本质上就是将原本由HTTP发送的明文通信内容，通过加密后发送，从而保证通信安全

CA：

全称：certification authority ，证书颁发机构。是权威、可信的机构，可以视作是HTTPS可靠性的基石

HTTPS连接建立过程：

* 客户端先预置CA的公钥(CA-pub.key)，一般会是各浏览器自带，用户不关心

* 服务器生成公钥(SRV-pub.key)，并将公钥和各种信息(公司、地址、国家、邮箱等)发送给CA做认证，CA认证通过之后会用CA自己的私钥(CA-pri.key)加密这些信息以及证书的hash值(hash-A)，生成完整证书，返回给服务器，服务器自行保存。

* 客户端向服务端发起连接请求(ClientHello)，包含各种参数，这里有一个客户端生成的随机数，我们把它叫做R1，后面会用到

* 服务端返回响应(ServerHello/Certificate/ServerKeyExchange/ServerHelloDone)，包含证书、服务端生成的随机数R2、服务端选择的加密算法、加密通信协议版本

* 客户端拿到证书，用自身预置的CA公钥(CA-pub.key)解开，得到对应的信息，将解开后得到的服务器信息做hash后得到hash-B，然后与解开证书后得到的hash-A进行对比，对比一致后则确认该证书未经篡改，就从证书中取得服务器的公钥(SRV-pub.key)，并记录下服务端生成的随机数R2、以及服务端所选择的加密方式

* 客户端产生第三个随机数R3(预主密码)，此时客户端拥有了三个随机数R1/R2/R3，然后通过商定的加密方法使用R1/R2/R3生成对称密钥，然后将R3以及将握手消息hash后得到的hash值(verify_data1)通过服务端公钥加密，加密后的内容发送给服务端(ClientKeyExchange/ChangeCipherSpec/ClientFinished)

* 服务端使用自身的私钥进行解密，得到预主密码R3，此时，服务端也拥有了R1/R2/R3，以及和客户端商定好的加密方法，于是使用商定好的加密方法和这三个随机数，生成对称密钥

* 服务端将握手消息做hash得到verify_data2，和客户端发来的verify_data1做对比，如果一致，则认为握手过程没有被篡改，然后通过生成的对称密钥加密verify_data2，返回给客户端(ServerFinished)

* 客户端收到服务端返回的消息，使用对称密钥解密后得到verify_data2并和自身计算出的verify_data1做对比，如果一致，则认为握手过程没有被篡改，至此，密钥交换成功

* 双方使用对称密钥对通信内容进行加密，开始通信

建立连接的细节：

对服务器身份验证的完整握手过程（包信息）

1、ClientHello

客户端发起请求到服务器，其中包含了自身支持哪些加密方式和功能

其中包含：

1. Version：客户端支持的最佳协议版本2. Randon：随机数，32字节的数据，其中28字节为随机生成，剩余4字节包含额外信息，受   客户端时钟的影响；在握手时，客户端和服务器都会提供随机数，可以防止重放攻击，并   确认初始数据交换的完整性3. Session ID：首次会话时，该字段为空。这个字段表示会话的唯一标识，服务器可以借助它   从自己的缓存中找到对应的会话状态，可以用于恢复会话4. Cipher Suites：密码套件，这是由客户端支持的所有密码套件组成的列表，按照优先级排列5. Compression：客户端可以提供多个自身支持的压缩方法，默认为null，代表没有压缩6. Extensions：扩展

2、ServerHello

服务器将自身选择的连接参数回传给客户端，这个消息的结构和1中类似，但每个字段只包含一个值；

服务器无需支持客户端支持的最佳版本，如果服务器不支持客户端相同的版本，可以提供某个其他版本以期待客户端能接受

3、Certificate

发送服务器的x509证书链，证书链指的是由根证书(也就是CA签名后的那个证书)派生而成的一系列证书

4、ServerKeyExchange

根据选择的密钥交换方式，服务器发送生成主密钥的额外信息

5、ServerHelloDone

服务器通知自己完成了协商过程，在此之后，服务器会等待客户端发送消息

6、ClientKeyExchange

客户端发送生成主密钥所需的额外信息

7、ChangeCipherSpec

已取得用以生成对称密钥的足够信息，已生成加密密钥，并将切换到加密模式

8、Finished

双方计算发送和收到的握手消息的MAC并发送，这个消息包含verify_data字段，
它的值是握手过程中所有消息的散列值，以验证握手消息没有被第三方篡改

* 至此，对称密钥交换完毕，后续的应用数据传输都以此对称密钥加密后发送。从而实现安全

问题：

1、为什么要用三个随机数来生成对称密钥？

因为计算机所生成的随机数其实是伪随机数，通过统计学的方法是有规律可循的。
但是分别由服务端、客户端生成共三个随机数，其随机性可以大大提高，基本可以视作是真随机数。

2、为什么Finished消息要带有verify_data字段？

主要是为了验证整个握手过程没有被第三方所篡改，确认Client和Server之间是否有攻击者

3、为什么不完全使用非对称加密来做？

因为非对称加密的CPU消耗很大，而对称加密的消耗要小得多。并且通过非对称加密交换的对称密钥并不是永久的，
当攻击者暴力破解后，本次使用的对称密钥早就失效了，所以安全性是很有保障的。

总结：

HTTPS本质上就是通过使用非对称加密方式交换对称密钥，从而实现安全性。

HTTPS的可靠性由CA作为基础，客户端和服务端之间通过对CA的信任从而建立信任关系，

但需要考虑的是CA可以不通过域名所有者的同意而直接签发某域名的证书。所以为了解决这种情况，我们会使用“钉扎”的方式解决这个问题，下一次会详细介绍