HTTPS 协议基础知识

Http协议的缺点

在没有经过任何加密手段的HTTP通信中，面临着三大危险：消息监听、消息篡改、冒充身份。

• 消息监听

我们发送的消息需要经过很多的中间路由器，我们无法确保网络中每一个节点都是安全的，所以我们发送的数据会被恶意的对象截取到。假如我们的消息没有经过任何加密，那么恶意用户就可以监听到我们通信的所有数据。

解决的方法是：对通信数据进行加密。

• 消息篡改

我们发出的数据会经过危险的中间节点，黑客可以监听我们的数据，也可以对我们的数据进行修改。

解决的方法是：利用MD5等hash算法手段来检验数据的完整性。

• 冒充身份

HTTP并没验证身份的流程，我们无法保证我们接收到的数据是服务器响应的，服务器也无法鉴别请求的用户是否是恶意用户。

解决的方法是：使用证书来检验对方的身份 。

Https协议概念

Https协议是进行加密传输、身份认证的网络协议。在HTTP协议基础之上加入加密以及认证机制的HTTP。

Https相较Http不是一种新协议，只是在Http通信接口部分使用了SSL(Secure Socket Layer)和TLS(Transport Layer Security)协议来实现。使得Http先与SSL通信，再由SSL和TCP通信，而不是Http直接与 TCP 通信。

加密算法

对称加密算法

指加密和解密使用相同密钥的加密算法。客户端和服务器共用同一个密钥，对称加密的优点是加解密效率高，但是在安全性方面可能存在一些问题，因为密钥存放在客户端有被窃取的风险。在大多数的对称算法中，加密密钥和解密密钥是相同的，所以也称这种加密算法为秘密密钥算法或单密钥算法。常见的对称加密有:DES、AES、RC4、IDEA。

对称加密的一个致命问题就是密钥的传输问题。由于加解密过程都使用同一个密钥，所以通信一方必须将密钥首先传给另一方，双方才能正常的进行通信。可是，如果有可靠的方法来传输密钥，那么用同样的方法就可以安全的传递通信内容。使用对称加密，只是把 如何安全的传输通信内容转化为了如何安全的传输密钥，本质上并没有解决任何问题。这个时候我们需要将非对称加密引入进来，解决安全的传输密钥问题。

非对称加密算法

非对称加密也称为公钥加密，在密钥对中，其中一个密钥是对外公开的，所有人都可以获取到，称为公钥，其中一个密钥是不公开的称为私钥。非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）,并且加密密钥和解密密钥是成对出现的。

公钥通常存放在客户端，私钥通常存放在服务器。使用公钥加密的数据只有用私钥才能解密，反过来使用私钥加密的数据也只有用公钥才能解密。非对称加密的优点是安全性更高，因为客户端发送给服务器的加密信息只有用服务器的私钥才能解密，因此不用担心被别人破解，但缺点是加解密的效率相比于对称加密要差很多。

非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048位，意味着待加密内容不能超过256个字节。非对称加密的代表算法有：RSA、ElGamal等。

非对称加密通过公私钥完美解决了密钥传输问题。发送方使用公钥进行加密，接收方使用私钥进行解密。公钥可以公开存在于网络中，私钥由接收方保管，不能泄露。私钥是通信安全的重要保障，一旦泄露，加密通信都会被破解。非对称加密的性能只有对称加密的几百分之一。在浏览器或者即时聊天的场景下，这个速度可能是用户所接受不了的。所以真正使用时，往往是对称加密和非对称加密结合使用。如图所示：

用非对称加密来保护对称加密的密钥，既解决了对称加密的密钥传输问题，又解决了非对称加密速度慢的问题。

到此我们的网络传输依旧不是安全的，因为我们还是差了非常关键的一步，浏览器该怎样才能获取到网站的公钥呢？虽然公钥是属于公开的数据，在网络上传输不怕被别人监听，但是如果公钥被别人篡改了怎么办？如图所示

中间人通过特定技术手段拦截了双方的通信链路，然后调包了发送给客户端的公钥，神不知鬼不觉的拦截并伪造了通信内容。客户端无法确定收到的公钥到底是不是服务端的，服务端也无法识别到消息被篡改。

在防止通信内容被篡改和认证对方身份的问题上，此时依然无法解决。此时，引入数字证书来证明信息发送方的身份，并且防止信息被篡改。

数字证书

数字证书是由公认第三方数字签发机构(CA) 颁发给服务器的一个用于验证身份的数字认证。证书中包含有服务器信息例如公钥、证书签名、证书机构信息等。

基础概念

• 数字摘要

数字摘要是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。“数字摘要“是https能确保数据完整性和防篡改的根本原因。

• 数字签名

数字签名就是对“非对称密钥加解密”和“数字摘要“两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

数字签名流程图：

请求证书验证流程

客户端验证证书流程

客户端拿到证书后根据证书上的方法自己生成一个证书编号，如果生成的证书编号与证书上的证书编号相同，那么说明这个证书是真实的。同时，为避免证书编号本身又被调包，所以使用第三方的私钥进行加密。
数字证书制作流程图：

使用MD5对证书的内容求值就可以得到一个证书编号

数字证书解析流程图：

当客户端拿到证书后，开始对证书中的内容进行验证，如果客户端计算出来的证书编号与证书中的证书编号相同，则验证通过

现实中，浏览器和操作系统都会维护一个权威的第三方机构列表（包括它们的公钥）。因为客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。

SSL(安全套接字层)

SSL协议可分为两层：

• SSL记录协议(SSL Record Protocol)

它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持

• SSL握手协议(SSL Handshake Protocol)

它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等

HTTPS安全连接建立流程

1. 客户端请求服务器建立安全连接，附加客户端支持的SSL与TLS版本、支持的加密算法版本、随机数。
2. 服务器响应请求，附加选择的协议版本、加密算法版本、服务器随机数。
3. 服务器向客户端发送证书。
4. 服务器发送hello done表示hello阶段结束。
5. 客户端验证证书，拿到服务器公钥；利用两个随机数，生成pre-master secret，并使用服务器的公钥加密发送给服务器。
6. 客户端发送changeCipherSpec提示服务器此后使用pre-master secret产生的密钥加密通信。
7. 客户端发送FIN报文，表示结束。
8. 服务器也发送changeCipherSpec报文。
9. 服务器也发送FIN报文，表示结束。
10. 双方可以开始安全通信了。

总结

HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。