本文主要讲述了我的两点思考：
1、HTTPS凭什么保证数据的传输安全
2、为什么要使用混合加密的方式
【前言】
前段时间被同事问到一些安全相关东西，问题是这样的：我们的软件做了哪些安全相关的工作呢？我的回答是：1、采用了HTTPS加密协议，防止被截取数据进行分析；2、做了数据校验，对发送过来的东西进行过滤，以防被sql注入等；3、限流策略；之后要是有必要的话，我们还可以上个waf。
可随后被反问，我采用HTTPS加密协议，那又怎样呢？在客户端不还是会被解密出来里面的信息吗？我当时瞬间被问蒙了（只能怪我基础不扎实吧）。这个问题的方向和HTTPS加密传输粗看确实有联系，我客户端都能解密了，还要加密干嘛呢？仔细回过头来想一想，其实这个加密说的很清楚了，是为了防止被其他人从中间截获，换句话说就是为了防止中间人攻击。一句话总结，采用HTTPS目的是为了保护客户端和服务端传输的信息，不被第三方截获破解。
好了，说到这里，也就解决了同事的那个问题。既然谈到了HTTPS，那就再深入思考一下，在这里小伙伴可以看这里再了解下什么是HTTS、TLS、SSL以及HTTPS建立连接过程（点击后文即可跳转原文，统一简称为文章里）。
【HTTPS凭什么保证数据的传输安全】
深入思考一下，HTTPS在连接的过程，是如何保证安全的呢？在我个人理解主要有以下三点：
1、加密
在文章里我提到过传输时候是先用随机数对握手信息也就是传输的数据进行加密，再用公钥对随机数进行加密，用通俗的话来说就是，先用一把锁（我们称之为锁1）把信息锁起来，再用另外一把锁（称之为锁2）把这个钥匙也锁起来，而锁2的钥匙（即私钥）只有对方有。如此一来，就做到了信息加密，一定程度上有效的防止了中间人攻击，换句话说也就是用户的信息有效的得到了保护。
2、身份认证
【CA证书认证】
在文章里有我提到随ca证书一起发给客户端的有这些内容：1、证书颁发机构；2、使用机构；3、公钥；4、有效期；5、签名算法；6、指纹算法；7、指纹。那么问题来了，指纹算法和指纹是什么呢？顾名思义它们像人类的指纹一样独一无二，也是用来证明证书是它自己的。指纹就是一个证书的签名，这个签名是CA机构在发布证书之前，用证书自己的根私钥通过指纹算法对证书的内容进行计算，得到的一个hash值。可以类比为人们的签名，证明一下是自己（证书自己），那么怎么证明这个签名就是你自己（证书）的呢？很好办，我们人类可以拿你以前的签名进行对比就可以分辨出来了，这种数字签名当然也可以，用发过来的指纹算法，对证书内容进行一次hash计算，得到另外一个hash值h2，将这个签名和新的hash值h2一对比就可以知道真假了。
【URL认证】
验证了证书是真的，接下来对比一下证书中的URL和我们所请求的URL是否一致，就可以判断是不是钓鱼网站之类的了。
3、保证数据没有被篡改
【保证传输的通信数据没有被篡改】
在前面的加密里面提到了随机数，按照我个人的理解，这个随机数是Client和Server协商的对称加密的密钥，提到的用随机数给握手信息进行加密的讲法并不完整，其实被随机数一起加密的除了握手信息原始数据，还有用CA证书中的签名算法计算的握手信息原始数据的hash值。
当服务端收到上面一段操作后传过来的信息后，先用自己的私钥解密出随机值，这个随机值之后就是CS传输用的对称加密的密钥了。然后用这个随机值对传输过来的握手信息原始数据和握手信息原始数据的hash值h3进行解密，再用自己之前的签名算法，对握手信息原始数据进行一次hash计算，得到另一个hash值h4，将两个hash值h3和h4进行对比，如果一样，那么通信数据就没有被篡改。
【为什么要使用混合加密的方式】
这个时候你或许会问，我可以不可以全程都用安全性更高的非对称加密呢（非对称加密不可逆）？也就是说客户端并不是生成一个随机值作为对称加密的密钥，而是把自己生成的公钥发过去给到服务端，之后服务端每次都用这个公钥来加密数据怎样？
听起来似乎是个goot idea，但是，作为一名运维民工，对资源的消耗情况固然是敏感的，那么我们谈谈对称/非对称加解密的资源消耗吧。
众所周知，非对称加密的运算速度非常慢，比如我们常见的RSA加密算法，稍微去了解一下你就知道这个算法有多么的复杂。算法复杂了，运算起来必然就快不了，如果想要加快速度，那必然要消耗更多的资源，这样一来就有点得不偿失的感觉了。那么这个时候对资源消耗较小的对称加密（比如常见的AES）就可以缓解一下这个问题。
所以，TLS采用了对称+非对称结合这种混合加密方式。
