https 公钥 私钥 证书 签名

转载我看到的内容，然后加上自己的想法：

 

先粗略解释一下：

一、公钥加密 

假设一下，我找了两个数字，一个是1，一个是2。我喜欢2这个数字，就保留起来，不告诉你们(私钥），然后我告诉大家，1是我的公钥。

我有一个文件，不能让别人看，我就用1加密了。别人找到了这个文件，但是他不知道2就是解密的私钥啊，所以他解不开，只有我可以用数字2，就是我的私钥，来解密。这样我就可以保护数据了。

我的好朋友x用我的公钥1加密了字符a，加密后成了b，放在网上。别人偷到了这个文件，但是别人解不开，因为别人不知道2就是我的私钥，只有我才能解密，解密后就得到a。这样，我们就可以传送加密的数据了。
 

二、私钥签名
如果我用私钥加密一段数据（当然只有我可以用私钥加密，因为只有我知道2是我的私钥），结果所有的人都看到我的内容了，因为他们都知道我的公钥是1，那么这种加密有什么用处呢？

但是我的好朋友x说有人冒充我给他发信。怎么办呢？我把我要发的信，内容是c，用我的私钥2，加密，加密后的内容是d，发给x，再告诉他解密看是不是c。他用我的公钥1解密，发现果然是c。
这个时候，他会想到，能够用我的公钥解密的数据，必然是用我的私钥加的密。只有我知道我得私钥，因此他就可以确认确实是我发的东西。
这样我们就能确认发送方身份了。这个过程叫做数字签名。当然具体的过程要稍微复杂一些。

用私钥来加密数据的摘要，用途就是数字签名。

 

总结：公钥和私钥是成对的，它们互相解密。

公钥加密，私钥解密。

私钥数字签名，公钥验证。

要发给我的东西，你们用我的公钥加密，私钥只有我才有，其他哪怕拥有我公钥的人是解不开的。

我想要发出去的东西，用私钥来加密，就是数字签名，凡是拥有我公钥的人都能解开。

 

具体点再解释一下（开始烂大街的例子，百度全一样）：

1.公钥与私钥原理
1)鲍勃有两把钥匙，一把是公钥，另一把是私钥

2)鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。

3)苏珊要给鲍勃写一封保密的信。她写完后用鲍勃的公钥加密，就可以达到保密的效果。

4)鲍勃收信后，用私钥解密，就看到了信件内容。这里要强调的是，只要鲍勃的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。

5)鲍勃给苏珊回信，决定采用"数字签名"。他写完后先用Hash函数，生成信件的摘要（digest）。

个人批注：为什么不直接加密文档（信件）本身？假如这个文档是一个很大的视频呢？非对称加解密本身就慢，大文档更是难以操作，所以只加密文档的哈希而不是整个文档本身。如果你想检测签名是否有效，可以解密签名并自己对文档进行哈希转换（生成摘要），看看这两个值（摘要）是否匹配，这样我们就知道所接收的文档与服务器发送是否完全一样。如果文档在传输中被更改了，则哈希与服务器作为签名提供的值（摘要）不匹配，这叫做无效签名。

6)然后，鲍勃使用私钥，对这个摘要加密，生成"数字签名"（signature）。

7)鲍勃将这个签名，附在信件下面，一起发给苏珊。

8)苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。

9)苏珊再对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。

10)复杂的情况出现了。道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成"数字签名"，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。

11)后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找"证书中心"（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。

12)鲍勃拿到数字证书以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字证书就行了。

13)苏珊收信后，用CA的公钥解开数字证书，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。

这里存在的问题是：如果道格想冒充鲍勃发信给苏珊，于是把自己的公钥和一些相关信息一起加密，信息由证书中心审核，身份一定真实，然后生成一份"数字证书"。苏珊用CA公钥解开，发现这不是鲍勃，然后系统就会提示，此消息颁发的数字证书是为别人准备的，其他人可能尝试向您发送欺骗的数据，请忽视它。此时苏珊只知道这是别人的信息，但是不知道这是道格冒充的。

或者苏珊只有A,B,C机构的公钥，苏珊只相信了A,B,C机构，道格可能用不是很正规的D机构来生成“数字证书”，然后苏珊收信后发现这封信用自己所信任的机构公钥解不开。这个时候系统提示这张数字证书不是由受信任的机构颁发的，可以查看证书以便确认您是否信任该验证机构。只有信任了，能打开查看信息。

如还有疑惑，请见数字证书讲解：数字证书应用综合揭秘（包括证书生成、加密、解密、签名、验签）

 

2.HTTPS
HTTP协议的网站容易被篡改和劫持，如一些不良的运营商会通过代理服务器在你的页面中植入广告等。
因此很多网站选择使用HTTPS协议。HTTPS协议通过TLS层和证书机制提供了内容加密，身份认证，数据完整性三大功能。

1)下面，我们看一个应用"数字证书"的实例：https协议。这个协议主要用于网页加密。

2)首先，客户端向服务器发出加密请求。

3)服务器用自己的私钥加密网页以后，连同本身的数字证书，一起发送给客户端。

4)客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。

5)如果数字证书记载的网址，与你正在浏览的网址不一致，就说明这张证书可能被冒用，浏览器会发出警告。

6)如果这张数字证书不是由受信任的机构颁发的，浏览器会发出另一种警告

 

 

 

https=http+ssl，两种协议的合体，ssl协议升级版为tls，ssl位于http应用层与tcp中间，注意ssl只保证安全(不被破解)，并不保证可靠(即消息是否送达)，这一点有tcp保证。

计算机七层网络模型其实就是把复杂的系统设计拆分成一个个小的任务，再加以组装(模块化设计)，好处就是标准化、便于理解，定位问题，以及只提供接口不管实现等。

https采用非对称加密算法+对称加密算法来保证数据的安全。

以下是SSL协议握手的一个主要过程，主要分为4个阶段。

• SSL客户端（也是TCP的客户端）在TCP链接建立之后，发出一个ClientHello来发起握手，这个消息里面包含了
  -- Client支持的SSL协议版本；
  -- Client生成的随机数c1，稍后用于生成"对话密钥"；
  -- Client支持的加密方法；
  -- Client支持的压缩方法；

• SSL的服务器端会回应一个ServerHello，这个消息里面包含了以下内容
  -- Server确认使用的加密通信协议版本；
  -- Server生成的随机数s1，稍后用于生成"对话密钥"；
  -- Server确认使用的加密方法；
  -- Server 的SSL证书。

• Client收到服务器回应以后，首先验证Server的证书是否有效，如果没问题，从证书里面取出Server的公钥，然后发送消息给Server，包含以下内容
  -- Client生成的随机数c2，需要注意的是，这个随机数c2是经过Server公钥加密过的；
  -- 告知Server 握手结束

• Server收到Client消息后，使用私钥解密Client发过来的第二个随机数，同时也会发送握手结束的消息给Client。

此时，client和server都持有3个随机数，客户端和服务端用商定的算法利用3个随机数生成一个对话秘钥（session key），随后的通信就用这个秘钥进行加密解密。之所以用3个随机数，因为证书是静态的，增加随机数可以使得密钥更加有随机性。SSL协议传输过程中，使用的是由相同的3个随机数生成的对话秘钥（session key），而生成的规则是client与server商议好的算法，所以这个对话秘钥（session key）是相同的，这个加密方法称为对称加密。