算法
一、认识
https 通过数字证书验证服务器是否为信任的服务器, 采用非对称加密的方式交换密钥，然后使用对称加密的方式对数据进行加密，并且对消息的内容采用摘要算法得到消息摘要，这样对端在解密数据后可以通过相同的消息摘要算法对计算后的消息摘要和传过来的消息摘要进行对比，从而判断数据是否经过篡改。
以密码学为基础的信息安全包含主要的五个方面：机密性，可用性，完整性，认证性，不可否认性。
为了保证安全，TLS 就需要保证这五个特性。简要说明下这个五个特性：
- 机密性：保密信息不会透露给非授权的用户或实体；
- 可用性：指的是加密服务的高可用；
- 完整性：信息不回被非法篡改，有对应的篡改检测机制；
- 认证性：参与信息交换的两个主体需要确认对方的身份是否可信，避免信息被不怀好意的人给窃取或者篡改；
- 不可否认性：指的是用户在事后无法否认曾经进行的信息交换、签发；
每种算法，在TLS中都有其特定的用处。
二、对称加密算法
所谓对称加密，就是使用同一个密钥进行加解密。最常见的就是 AES加密算法 和 DES加密算法。加解密过程：
-
浏览器给服务器发送一个随机数
client-random和一个支持的加密方法列表 -
服务器给浏览器返回另一个随机数
server-random和双方都支持的加密方法 -
然后两者用加密方法将两个随机数混合生成密钥，这就是通信双上加解密的密钥
但是对称加密，加解密双方如何安全的传递密钥是一个问题。如果服务器直接把密钥传输给客户端，然后才进行加密通信，可能在传输密钥的过程中，密钥就被窃取了。
三、非对称加密算法
非对称加密通常包含一对密钥，称为公钥(public key)和 私钥(private key)。其中一个密钥加密后的数据，只能让另一个密钥进行解密。如 RSA、ECDHE。 加解密过程：
-
浏览器给服务器发送一个随机数
client-random和一个支持的加密方法列表 -
服务器把另一个随机数
server-random、加密方法、公钥传给浏览器 -
然后浏览器用公钥将两个随机数加密，生成密钥，这个密钥只能用私钥解密
使用公钥反推出私钥是非常困难，但不是做不到，随着计算机运算能力提高，非对称密钥至少要 2048 位才能保证安全性，这就导致性能上要比对称加密要差很多
TLS 实际用的是两种算法的混合加密。通过 非对称加密算法 交换 对称加密算法 的密钥，交换完成后，再使用对称加密进行加解密传输数据。这样就保证了会话的机密性。过程如下：
-
浏览器给服务器发送一个随机数
client-random和一个支持的加密方法列表 -
服务器把另一个随机数
server-random、加密方法、公钥传给浏览器 -
浏览器又生成另一个随机数
pre-random，并用公钥加密后传给服务器 -
服务器再用私钥解密，得到
pre-random -
浏览器和服务器都将三个随机数用加密方法混合生成最终密钥
这样即便被截持，中间人没有私钥就拿不到pre-random，就无法生成最终密钥。可又有问题来了，如果一开始就被DNS截持，我们拿到的公钥是中间人的，而不是服务器的，数据还是会被窃取，所以数字证书来了，往下看，先简单说一下摘要算法
四、摘要算法
摘要算法 主要用于保证信息的完整性，相当于信息的指纹信息。常见的 MD5算法、散列函数、哈希函数都属于这类算法。其特点就是单向性、无法反推原文。为了保证安全性，目前 TLS 推荐使用 SHA-2 摘要算法，禁止使用 MD5 和 SHA-1。
有了摘要算法就能保证完整性了吗？
假如信息被截取，并重新生成了摘要，这时候就判断不出来是否被篡改了，所以需要给摘要也通过会话密钥进行加密，这样就看不到明文信息，保证了安全性，同时也保证了完整性。
五、数字证书(数字签名)
数字证书 可以帮我们验证服务器身份。因为如果没有验证的话，就可能被中间人劫持，假如请求被中间人截获，中间人把他自己的公钥给了客户端，客户端收到公钥就把信息发给中间人了，中间人解密拿到数据后，再请求实际服务器，拿到服务器公钥，再把信息发给服务器。这样不知不觉间信息就被人窃取了，所以在结合对称和非对称加密的基础上，又添加了数字证书认证的步骤，让服务器证明自己的身份。
中间人攻击如图所示:
数字证书需要向有权威的认证机构(CA)获取授权给服务器。首先，服务器 和 CA机构 分别有一对密钥(公钥和私钥)，然后是如何生成数字证书的呢？ 过程如下:
-
CA机构 通过摘要算法生成服务器公钥的摘要(哈希摘要) -
CA机构通过CA私钥及特定的签名算法加密摘要，生成签名 -
把签名、服务器公钥等信息打包放入数字证书，并返回给服务器
最后，CA 机构把生成的数字证书返回给服务器。服务器配置好证书，以后客户端连接服务器，都先把证书发给客户端验证并获取服务器的公钥。
5.1 签名工作流
客户端接收到服务器发送的数字证书和 CA机构 的公钥，通过 CA机构 的公钥对数字证书上的签名进行验证。过程如下:
-
使用
CA公钥和声明的签名算法对CA中的签名进行解密，得到服务器公钥的摘要内容 -
再用摘要算法对证书里的服务器公钥生成摘要，再把这个摘要和上一步得到的摘要对比，如果一致说明证书合法，里面的公钥也是正确的，否则就是非法的
谁来保证CA的公钥的正确性?
服务器验证的时候，需要拿到数字证书发布机构的CA公钥，但是怎么证明这个CA公钥是正确的呢？这个时候就需要有更大的CA帮小的CA的公钥做认证了，一层一层的背书，最顶层的CA，Root CA，称为根证书，作为信任链的根，是全球皆知的的极大著名CA，这些根证书一般会内置到操作系统中。类似于这样:
即使证书验证通过了，这样就能够保证安全了么，想想还有没有其他原因导致请求的网站身份不可信的？
有了CA机构，就没法进行中间人攻击了吗？
六、沉 淀与总结
https 通过数字证书验证服务器是否为信任的服务器, 采用非对称加密的方式交换密钥，然后使用对称加密的方式对数据进行加密，并且对消息的内容采用摘要算法得到消息摘要，这样对端在解密数据后可以通过相同的消息摘要算法对计算后的消息摘要和传过来的消息摘要进行对比，从而判断数据是否经过篡改。