对称加密、非对称加密、数字证书、数字签名都是用来干什么的？

想必大家都遇到过访问网站时，浏览器会提示不安全的情况，我们都知道这是因为没有使用https导致问题，但是究竟哪里不安全？举个简单的例子来说，当我们登录只使用了http协议的门户网站时，我们将用户名密码发送给门户网站，门户网站在用户名密码校验通过后将带有个人信息的网页发送给你。这个过程听起来很合理，但是又感觉不太对劲。

如果有个黑客截取了你的网络收发信息，我们的用户名和密码就会完全暴露出来。聪明的同学这时想到对"用户名和密码"加密，如下图所示

这种双方使用同一个私钥进行加解密的方法称为对称加密，但是还是存在问题，我和网站之间如何传递秘钥？如果黑客截取了网站发给我的秘钥并伪造出一个秘钥给我，让我使用错误的秘钥来进行加解密，我的信息还是会被一览无遗。

聪明的工程师想到利用公私钥的方式来解决这个问题，网站将公钥发给发送给用户，用户接收到公钥之后，使用公钥对"用户名和密码"进行加密，虽然黑客也有我们的公钥，但是公钥只能用来加密不能用来解密，这样解决了会话秘钥传输的问题。这种采用了公私钥的加解密方式，我们称为非对称加密。

但是这样真的安全吗？如果黑客伪造了一套公私钥，把自己的公钥发给我们，让我们使用错误的公钥去加密信息，这样仍然会导致我们的信息对黑客来说是透明的。

这样又衍生出来一个问题，我们如何确定拿到的公钥是网站发给我们的，而不是中间人发给我们的。这时候就需要第三方介入了，第三方相当于一个公证处（CA），证明我们的公钥是由网站发给我们的。这样我们的流程就发生了变化，网站首先把公钥发送给第三方，第三方把公钥和其他信息结合起来生成了"数字证书"，网站将数字证书发送给用户，用户接收到证书后，从证书中提取出来公钥，使用公钥对信息进行加密，听起来好像很合理，但是真的没有问题吗？

我们如何确定证书是由信任的第三方颁发的呢？证书上要是有CA的人工签名就好了，但是很显然不行，我们只能另寻办法。再来捋一边数字证书的流程，网站将公钥以及其他信息发送给CA，CA收到信息后，可以对信息进行hash计算，我们都知道，如果原始信息中任何一个值发生变动，那么hash计算后的hash值就会天差地别，然后CA会生成一对自己的公私钥，使用私钥对计算的hash值进行加密。然后将加密后的信息和网站的公钥和其他信息结合起来生成数字证书，这样就完成了数字签名的过程。

我们再来走一遍流程，网站将数字证书发送给中间人和用户，用户收到之后，使用CA的公钥对加密后hash值进行解密得到原始的hash值，再对公钥用同样的算法进行hash计算，比对两者的hash值，如果一样就证明数字证书是由我们信任的CA颁发的。又要但是了，如何确定我们获取到的CA的公钥是对的？根据上面的流程，很显然CA也需要数字证书，这份数字证书由根CA颁发，根CA也需要数字证书，好像可以一直循环下去，哈哈哈哈哈。其实操作系统在安装的时候就已经预置了根CA，（所以不要安装盗版系统哟），这样整个证书链就完成了闭环。