密码学经典应用之HTTPS工作过程
文章目录
- 一、理论基础
- HTTP协议
- 对称加密算法技术
- 非对称加密算法技术
- 信息摘要算法技术（也称为消息摘要算法）
- 密钥交换算法
- 二、HTTPS协议的设计过程
- 三、SSL四次握手过程
- 1、客户端发出请求。
- 2、服务器回应。
- 3、客户端确认和回应。
- 4、服务器的最后回应。
- SSL的随机数生成对称秘钥原理，为什么需要3个随机数
- 参考文献
一、理论基础
HTTP协议
HTTP协议是属于应用层的协议，它是基于TCP/IP的，所以它只是规定一些要传输的内容，以及头部信息，然后通过TCP协议进行传输，依靠IP协议进行寻址。
客户端发出请求，服务端进行响应，就是这么简单。在整个过程中，没有任何加密的东西，所以它是不安全的，中间人可以进行拦截，获取传输和响应的数据，造成数据泄露。
对称加密算法技术
对称加密是最快速、最简单的一种加密方式，加密（encryption）与解密（decryption）用的是同样的密钥（secret key）。对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议的核心当中。
常用的对称加密算法：AES、DES
非对称加密算法技术
非对称加密使用了一对密钥，公钥（public key）和私钥（private key），私钥加密的数据只有公钥能解密，公钥加密的数据只有私钥能解密。私钥只能由一方安全保管，不能外泄，而公钥则可以发给任何请求它的人。非对称加密使用这对密钥中的一个进行加密，而解密则需要另一个密钥。
常用的非对称加密算法：RSA
信息摘要算法技术（也称为消息摘要算法）
消息摘要算法的主要特征是加密过程不需要密钥，并且经过加密的数据无法被解密，目前可以被解密逆向的只有CRC32算法，只有输入相同的明文数据经过相同的消息摘要算法才能得到相同的密文。
常用的消息摘要算法：MD5、SHA、MAC（需要秘钥）
密钥交换算法
它可以让双方在完全没有对方任何预先信息的条件下通过不安全信道建立起一个密钥。
常用的密钥交换算法：迪菲－赫尔曼密钥交换算法（Diffie–Hellman key exchange，简称DH算法）
二、HTTPS协议的设计过程
- HTTP明文传输，不安全；
- 对HTTP包一层加密层，使用对称加密技术，客户端和服务端双方都提前知道秘钥；
- HTTP一般用在多客户端，单服务端模式的程序中，那么如果只有一个秘钥，那么其他客户端也能解密其客户端的报文，所以必须设计成，对称秘钥是动态生成的，每次连接生成一个。
- 客户端在动态发送对称秘钥给服务端的过程中，可能会被中间人攻击窃取。必须要有一个能保证发送对称秘钥的过程是安全的机制。
- 使用非对称加密技术保证对称秘钥的传输是安全的，因为公钥加密的只有私钥能解密，所以客户端使用使用公钥发送对称秘钥给服务端，服务端使用私钥解密出对称秘钥，这样服务端拿到对称秘钥后就可以在以后发送的数据中使用它进行加密了。
- 因为非对称密码中的公钥和私钥是成对出现的，假如客户端是通过访问服务端拿到公钥，这个过程也是可能会被中间人攻击窃取或者篡改。公钥被掉包，是因为客户端无法分辨传回公钥的到底是中间人，还是服务器，这也是密码学中的身份验证问题。
- 如何保证拿到目标服务端的公钥是正确的呢，这里需要引入了第三方认证机构，客户端通过访问第三方认证机构去获取。
- 第三方认证机构在发送目标网站公钥给客户端的时候，第三方认证机构同样是通过使用非对称加密方式传输数据，浏览器安装后会内置一些权威第三方认证机构的公钥，比如VeriSign、Symantec以及GlobalSign等等，验证签名的时候直接就从本地拿到相应第三方机构的公钥。但是这仍然可能会受到中间人篡改，此时虽然中间人没有私钥并不能修改数据后重新加密传给客户端，但是它可以修改加密的报文再传回给客户端，客户端拿到的加密报文都是错的。
- 为了解决客户端能验证第三方机构的报文内容是合法的，这里需要引入数字签名，数字签名就是对原始报文使用消息摘要算法进行计算，然后再使用私钥进行加密，客户端收到加密后的报文和数字签名，分别解密后，计算原始报文生成的消息摘要是否跟第三方传来的消息摘要相等，这个过程也就是验证签名，如果对得上，那么得到的原始报文里面的公钥就是正确的。
- 这时可能有人会思考，假如把加密后的报文和数字签名都换掉，是不是有可能就攻击成功了，这个可能性理论是存在的，但是概率太低，因为加密后的报文和数字签名都是依靠了同一个第三方机构的私钥进行加密，客户端使用了同一个第三方认证机构的公钥进行解密，因为中间人没有私钥，它是随意修改两个加密后的报文，但是让这两个报文解密后能对得上的概率太低，几乎不可能实现。
- 这时客户端已经成功从第三方认证机构拿到了正确的目标服务端的公钥了，客户端会随机生成一个对称秘钥，使用服务器公钥加密，传输给服务端。
- 目标服务端收到客户端的报文，因为公钥加密的只有私钥能解密，所以这肯定不会被中间人窃取到对称秘钥，这时服务端解密报文，拿到客户端定制的对称秘钥，服务端下次发送消息的时候，就使用该对称秘钥进行加密和解密，客户端也是。
三、SSL四次握手过程
SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。
1、客户端发出请求。
客户端请求建立SSL链接，并向服务端发送一个随机数–Client random和客户端支持的加密方法，比如RSA公钥加密，此时是明文传输。
2、服务器回应。
服务端回复一种客户端支持的加密方法、一个随机数–Server random、授信的服务器证书和非对称加密的公钥。
3、客户端确认和回应。
客户端收到服务端的回复后利用服务端的公钥，客户端收到服务器回应以后，验证服务器证书（客户端在验证证书的时候，先看CA的根证书是否在自己的信任根证书列表中。再用CA的根证书提供的公钥来验证服务器证书中的数字签名，如果公钥可以解开签名，证明该证书确实被CA所信任。再看证书是否过期，访问的网站域名与证书绑定的域名是否一致。这些都通过，说明证书可以信任。）。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。加上新的随机数–Premaster secret 通过服务端下发的公钥及加密方法进行加密，发送给服务器。此时的客户端通过这些随机数计算得到对称加密key – session key。
4、服务器的最后回应。
服务端收到客户端的回复，利用已知的加解密方式进行解密，同时利用Client random、Server random和Premaster secret通过一定的算法生成HTTP链接数据传输的对称加密key – session key。
然后，向客户端最后发送下面信息。
（1）编码改变通知，表示随后的信息都将用双方商定的对称加密方法和密钥发送。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。
SSL的随机数生成对称秘钥原理，为什么需要3个随机数
先了解DH密钥交换算法，过程如下：
上图中，Alice和Bob通过DH算法生成秘钥K，
其中：
g、p是2个非私密数据；
a、b是私密数据；
A是根据：g、p、a算出来的非私密数据；B是根据：g、p、b算出来的非私密数据；
把A从a传到b，根据求K公式，b得到秘钥k；a同理；
注：
p是一个大素数。p的位数决定了攻击者破解的难度。
g则不需要很大，并且在一般的实践中通常是2或者5。
假如不使用DH算法进行对称秘钥生成，那么也就是直接根据服务端的公钥加密对称秘钥然后再传给服务端，这时中间人因为也有服务端的公钥也可以加密一个对称秘钥传给服务端，所以这时服务端解密虽然可以解密得到对称秘钥，但是无法验证对称秘钥合法性，这时假如用了该不合法的对称秘钥加密返回数据，那么信息就会被窃取。而DH算法是结合了客户端和服务端都产生一个随机数（随机数a和b，根据DH算法这两个随机数是不需要告诉对方的各自内部持有），同时还结合了客户端使用公钥加密的第三个随机数，真正的对称秘钥是结合了双方的内部随机数结合计算动态生成的，这时客户端和服务端加密的数据，中间人必须要知晓这三个随机数才能计算出对称秘钥来解密数据，而这几乎是不可能的。
客户端和服务端通过DH算法（明文交换2个计算结果的数）得到K，然后客户端利用第三个随机数Premaster secret与K计算出对称秘钥session key，
而Premaster secret是客户端会通过非对称加密的公钥加密传输给服务端，所以服务端也可以通过DH算法的K与Premaster secret计算出对称秘钥session key，
整个过程并没有直接传输对称秘钥session key，而且也没有直接交互DH算法的私密数字：a和b，而第三个随机数Premaster secret又是通过非对称加密传输，整个过程私密数据：a、b、Premaster secret，中间人要想破解密码，需要同时正确的碰对这三个数字。
参考文献
- 看图学HTTPS-了解HTTPS的工作流程
- 浅析Diffie–Hellman