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可以不通过域名所有者的同意而直接签发某域名的证书。
所以为了解决这种情况,我们会使用“钉扎”的方式解决这个问题,下一次会详细介绍