https详解

https详解

首先，说一下http，其实这个没什么说的，超文本传输协议，大家都知道。

但是后来为什么引进了https呢？是因为人们在使用http的时候，发现http是明文传输的，设想一下，假如你和你的老板商谈公司要事，结果有个人在中间直接截获了你和你老板的聊天信息，这样，你们公司的机密完全被人给窃取了。（这种行为我们称他为中间人攻击）

所以，有什么办法能够解决这个问题呢？

在讲解决方案之前，首先我们了解一个概念：

**：**是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。可以简单的想象为函数给他不同的参数，就会有不同的运行结果，给一个加密算法不同的**，就会加密出不同的结果。

有了**，我们就有了一个解决方案了，那就是把数据用**加密，只有传输双方知道**，那么第三方不就没法知道数据内容了吗！！例图：

貌似好像有点道理啊！但是仔细一想，这根本是行不通的！

难道你只和你公司老板通信吗，你不要和你女朋友通信吗？你不要和其他人通信吗？难道你和其他人通信也使用这个**？那你老板不就可以拿这个**看你和你女朋友通信数据了吗？

这个时候有人说，那简单，和每个人通信都单独设置一个**，有这种想法，那你真的是个麻瓜！全世界有多少人使用http，难道我们和每个人的通信都要单独设置一个**吗？

所以这个方案肯定不行！

注：以上这种加密算法叫做对称加密，因为加密和解密使用的都是同一个**！

再来看第二种方案：
现在不使用一个**了，而是使用两个**，这两个**，一个叫做公钥，任何人都可以知道，一个叫做私钥，只有自己能够知道。使用公钥加密的，只能用私钥解密，使用私钥加密的，只能使用公钥解密！

于是乎，我们可以这样，如图：

这样，由于公钥加密的消息，只有私钥可以解密，而私钥只有小红自己知道，所以就能够确保消息不被别人发现啦！

但是这也是有问题的，就是每次传输都使用这种非对称加密的方式，是比较耗费资源的，而对称加密则是比较快速的，于是乎，有了这样一种方案：

在第一次传输的时候，使用非对称加密传输一个**，然后以后传输，都使用这个**，进行对称加密传输！
这样，只有第一次是非对称加密，后来都是对称加密了，就比较节约资源了！
如图：

但是采用以上这个方案就解决了安全问题吗?
其实还是没有!!!

废话不多说,看图:

没想到吧,饶了一大圈,居然还是没有解决安全传输的问题

于是,又有了一个方案,我们只要在第一次传输公钥的时候,确保小明接收到的公钥是小红传的,而不是中间人传的不就行了嘛!!!
但是怎么去实现呢?

我们每个人都有一个身份证,这个身份证可以证明你是你,不是他!而且这个身份证是权威机构(政府)发的,我们都信任他!
所以,只要找一个权威机构,给第一次传输的公钥一个身份证,那么我只要检查这个身份证,不就能知道这个公钥是不是被中间人给改过了嘛!

这个权威机构就是CA

那么这个身份证,ca又是如何实现的呢?他为什么不会被伪造呢?

在讲这个问题之前,先讲一种Hash算法的其中的 一个特性:

对于A,不可能有一个B (B != A),使得Hash(A) == Hash(B)

下面上图:

A将他的数字证书发给B，B将数字证书中的 A的公钥和A的一些其他信息 使用相同的Hash算法生成一个消息摘要，将数字签名，使用CA的公钥解密，再次生成一个消息摘要，对比这两个消息摘要，就可以知道，A的公钥有没有被人更改过！！！

那么ca的公钥是我们是如何得到的呢？如果有人在我们传输ca公钥的时候，发起中间人攻击，那么这个方案还不是玩完？其实是这样的：

CA 也拥有一个证书(内含公钥和私钥)。网上的公众用户通过验证 CA 的签字从而信任 CA ，任何人都可以得到 CA 的证书(含公钥)，用以验证它所签发的证书。
如果用户想得到一份属于自己的证书，他应先向 CA 提出申请。在 CA 判明申请者的身份后，便为他分配一个公钥，并且 CA 将该公钥与申请者的身份信息绑在一起，并为之签字后，便形成证书发给申请者。
如果一个用户想鉴别另一个证书的真伪，他就用 CA 的公钥对那个证书上的签字进行验证，一旦验证通过，该证书就被认为是有效的。证书实际是由证书签证机关(CA)签发的对用户的公钥的认证。

那讲了这么多，接下来https就很简单了，借用别人的一张图：

那么这个问题解决之后，新的问题又来了！！ 我们都知道fiddler等抓包工具，是可以抓到https请求的，并且可以明确的看到明文，不是说https是加密的吗，为什么抓包软件还能抓到呢？想了解这个问题，关注博主下回分解！