消息摘要算法、对称加密算法、非对称加密算法之应用场景
上一篇文章主要向大家介绍了三种加密算法和它们的特点，这篇文章作为上一篇文章的续就来讲讲它们的应用场景，也顺带着讲一下HTTPS相对于HTTP的安全性是做了哪些防护。
数字信封
首先假定一个场景，应用的开发需要加密大量的数据，且要密钥需要在使用过程中传输。在这种情况下使用非对称加密能够保证分发密钥的安全性，因为只需要将公钥分发给用户，私钥保存在自己手里，只要不被盗窃走或者被破解是没有问题的。但是别忘了，这里的要求是对大量的数据进行加密，这种情况下使用非对称加密会使得加密的时间变得漫长，所以这里显然是不适合非对称加密的。再来看看对称加密，速度加快了，这很好，但是别忘了密钥传输的问题，一旦密钥在传输过程中被截取，数据的安全性也无从谈起了，这就必须专门安排安全的信道给密钥，似乎也不是一个很好的方法。
这个情况下不同解密算法的灵活结合就成了更为合理的解决方式。数字信封这种结合的一个优秀典范。数字信封采用对称加密算法加密数据，非对称加密算法加密对称密钥的方式解决了以上的问题，也适用于一些其他的加密场景。以下是其示意图。
SSL协议
SSL（Secure Sockets Layer）协议是HTTPS协议的安全性基石，相较于HTTP，HTTPS正是加入了SSL层来确保数据传输的安全性。以下通过模拟几种数据传输过程来了解SSL协议。
Round 1
客户端 >>>> 服务器：你好！
服务器 >>>> 客户端：你好！这是我们传输过程中需要的公钥{公钥|RSA}
客户端 >>>> 服务器：收到公钥，让我们来验证一下，这是我加密的一个随机数，解出来给我看看。{加密过的随机数}[公钥|RSA]
服务器 >>>> 客户端：{解密过的随机数}[私钥|RSA]
客户端 >>>> 服务器：验证成功，这是我的账号和密码，给我看看我的私密日记{用户名，密码}[公钥|RSA]
服务器 >>>> 客户端：{我喜欢xxx}[私钥|RSA]
这种加密方式粗看起来没有问题，数据都是加密后再传输，但是仔细想想，似乎有很大的问题。首先回忆一下，RSA的公钥是共享的，一旦数据在传输过程中被抓取，再通过公开的公钥进行解密，数据的安全性就不能得到保障了。在数据传输过程中，单独使用非对称加密似乎是不可靠的，这种情况下上面介绍的数组信封就起作用了。
Round 2
<pre><code>
客户端>>>>服务器：你好！
服务器>>>>客户端：你好！这是我们传输过程中需要的公钥{公钥|RSA}
客户端>>>>服务器：收到公钥，让我们来验证一下，这是我加密的一个随机数，解出来给我看看。{加密过的随机数}[公钥|RSA]
服务器>>>>客户端：{解密过的随机数}[私钥|RSA]
客户端>>>>服务器：验证成功，这是数据传输过程中需要用到的对称密钥，{对称密钥}[公钥|RSA]
服务器>>>>客户端：{收到密钥}[密钥|AES]
客户端>>>>服务器：这是我的银行卡号和密码，给我查查余额{卡号，密码}[密钥|AES]
服务器>>>>客户端：{你的银行卡余额，五毛}[密钥}|AES]
</code></pre>
相比Round1,Round2的数据传输的安全性得到了保障，只要不发生密钥被盗或者破解，就不会出现数据安全问题，但是这样就真的安全了吗？来看看Round3。
Round 3
<pre><code>客户端>>>>黑 客：你好！
黑 客>>>>客户端：你好！这是我们传输过程中需要的公钥{公钥|RSA}
客户端>>>>黑 客：收到公钥，让我们来验证一下，这是我加密的一个随机数，解出来给我看看。{加密过的随机数}[公钥|RSA]
黑 客>>>>客户端：{解密过的随机数}[私钥|RSA]
客户端>>>>黑 客：验证成功，这是数据传输过程中需要用到的对称密钥，{对称密钥}[公钥|RSA]
黑 客>>>>客户端：{收到密钥}[密钥|AES]
客户端>>>>黑 客：这是我的银行卡号和密码，给我查查余额{卡号，密码}[密钥|AES]
黑 客>>>>客户端：嘿嘿，你上当了</code></pre>
所以在实际的数据传输中存在一个问题，当前的服务器真的是真正的服务器吗？怎么才能确定这个服务器的身份？这个时候，数字证书的作用就显现出来了。大家都知道，使用HTTPS需要申请数字证书，这个证书是保证HTTPS安全数据传输的基石。这个证书就是SSL证书，在这个证书中包含以下内容：
证书的发布机构
证书的有效期
公钥
证书所有者（Subject）
签名使用的算法
指纹以及指纹使用的算法
在了解数字证书的内容后，下面一轮模拟数据传输将会使用到上一篇文章讲到的三种加密方式，也能大致了解到HTTPS的安全机制。
Round 4
<pre><code>客户端>>>>服务器：你好！
服务器>>>>客户端：你好！这是我的数字证书
客户端>>>>服务器：我已收到并验证了数字证书的合法性，验证你是证书的合法拥有者，这是证书的公钥加密的随机数{随机数}[公钥|RSA]
服务器>>>>客户端：{解密过的随机数}[私钥|RSA]
客户端>>>>服务器：验证成功，这是数据传输过程中需要用到的对称密钥，{对称密钥}[公钥|RSA]
服务器>>>>客户端：{收到密钥}[密钥|AES]
客户端>>>>服务器：这是我的银行卡号和密码，给我查查余额{卡号，密码}[密钥|AES]
服务器>>>>客户端：{你的银行卡余额，一个亿}[密钥}|AES] </code></pre>
在Round4，服务器发送给客户端的数字证书中，包含数字摘要算法产生的指纹以及所使用的数字摘要算法，这部分使用来验证数字证书的完整性以及合法性的。如果指纹（可以认为是MD5或者SHA对证书加密产生的字符串）能够与客户端对证书加密产生的指纹对应（使用证书中的数字摘要算法对证书加密），就能够证明证书没有被篡改过，其合法性也就得到验证。一下的步骤就与上面介绍的数字信封类似了。通过以上的模拟，能够知道使用SSL协议的HTTPS协议既能保证数据传输中的安全，也能保证客户端与服务器连接的安全。
总结
HTTPS虽然安全，但不能完全保护数据安全，它能够做的是在数据传输过程中保护数据的安全，服务器和客户端中数据安全也是需要注意的。
通过这两篇文章的介绍，大家能够大体了解到现在主要的加密方式以及它们的使用场景，也稍微接触到了HTTPS的安全加密机制，虽然这在开发中的使用机会不大，但能够了解到这些优秀的机制，以后在有加密需求的时候也能够多一些思路。 |
