https加密

对称加密：可以用密钥Key加密，也可以用Key解密
非对称加密：用公钥加密的内容必须用私钥解开，用私钥加密的内容要用公钥加密

 
 
如果用两组公钥密钥，是否能保证安全？（不能）
Server拥有公钥S和私钥S- , Chrome(浏览器)拥有公钥C和私钥C-
第一步   Chrome把公钥C明文传输给Server ，这时候Server拥有 、公钥C、公钥S、私钥S-
第二步   Server把公钥S明文传输给Chrome，这时候Chrome拥有 、公钥S、公钥C、私钥C-
第三步   Chrome向Server 传输的内容都用 公钥S 加密，Server收到之后用私钥 S- 解密，因为只有Server拥有私钥S- ，所以能保证这条数据链安全
      Server 向 Chrome 传输的内容都用公钥C加密，Chrome收到之后用C-解密。这样也可以保证这条链路的安全

这种方法，有漏洞，而且非对称加密非常耗时，这种方法不可取

 
一   某个网站H拥有 非对称加密 公钥H，私钥H-
二   Chrome(C)向网站H发送请求，服务器把 公钥H 明文发送给C
三   C随机生成一个用于对称加密的 密钥C，用公钥H加密后发送给网站服务器(H)
四   H拿到后用 私钥H- 解密得到 密钥C
五   这样双方就有了 密钥C ，且他人不知道，之后就可以通过 密钥C 加密解密数据

还是有漏洞

如果在数据传输过程中，中间人 劫持到了数据，此时他的确无法得到浏览器生成的 密钥C ，这个密钥本身被 公钥H 加密了，只有服务器才有 私钥H- 解开它，然而中间人却完全不需要拿到 私钥H- 就能干坏事了。请看：
 

一   某服务器网站 H 有用于非对称加密的公钥H、私钥H-。
二  Chrome(浏览器)向 H 发送请求，H 把 公钥H 明文发送给 C
三  中间人劫持 公钥H，保存，把数据包中的公钥H 替换成自己伪造的 公钥F(他肯定同时拥有 公钥F和 私钥F-)
四   C生成一个用于对称加密的 密钥C ，用伪造的公钥F加密后传输给H。
五   中间人劫持之后用 私钥F-解密得到了 密钥C ，再用 原本的 公钥H 加密后传输给 H 网站服务器。
六   H拿到后用 私钥H-解密得到了 密钥C。

这样在 H 和 C 都不会感知的情况下，中间人能得到 H 的公钥，C的密钥 ，问题来了，如果一开始的 公钥H 也需要加密传输，那么就会无限循环下去

问题的关键在于 浏览器Chrome 如何知道收到的 公钥H 是正确网站的 公钥，而不是被替换过的 公钥F。

 
这就需要一个拥有公信力的机构，给网站颁发一个身份证，这就是CA机构，如今互联网世界正常运作的前提，而CA机构颁发的“身份证”就是数字证书。

任何网站在使用Https之前，都要向CA机构申请一份数字证书，数字证书里含有 证书持有者信息、公钥信息 等，Chrome向 H 提出请求，H 向 Chrome 发送证书，Chrome 从证书中获取 公钥 ，这里又会出现如何保证 证书 在传输过程中不会被篡改。

 
 

  我们把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。这就是数

字证书的“防伪技术”，这里的“签名”就叫数字签名：

左侧是数字签名的制作过程，右侧是验证过程：

数字签名制作过程；

一   CA机构拥有非对称加密的 私钥 和 公钥
二   CA机构对证书 明文数据T 进行 hash 得到 明文数据T
三   对hash后的值 (明文数据T)用 私钥 加密，得到 数字签名S

明文数据T 和 数字签名S 共同组成了数字证书，这样一份数字证书就可以颁发给网站了。
那浏览器拿到服务器传来的数字证书后，如何验证它是不是真的？（有没有被篡改、掉包）
 

Chrome验证过程：
一   拿到数字证书，得到 明文数据T ，数字签名S

二   用CA机构的 公钥 对 数字签名S 解密（由于是浏览器信任的机构，所以浏览器保有它的公钥），得到 明文数据T。

三   用证书里指明的 hash算法 对 明文数据T 进行 hash 得到 明文数据T

四   显然通过以上步骤 ，显然可以得到两份 明文数据T 应该是一样的，表明证书可信

  
  
  
  
所以最终的过程可以是这样

  

1、 客户端向服务端发起 SSL 连接请求
  
2、 服务器把 公钥(在证书中) 发给客户端，并且服务器保存着唯一的 私钥
  
3、 客户端使用根证书验证合法性，客户端用 公钥 对双方通信的 对称密钥 进行加密，并发给服务器
  
4、 服务器利用自己唯一的 私钥 对客户端发来的对称密钥进行解密
  
5、 进行数据传输，服务器和客户端双方用公有的相同的 对称密钥 对数据进行加密解密，可以保证在数据收
  发过程中的安全，

  
  
  

为什么这样可以保证证书可信呢？

 

  
  

中间人会不会也篡改证书呢？

假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡

改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从

而终止向服务器传输信息，防止信息泄露给中间人。

 
 

中间人有可能把证书掉包吗？

假设有另一个网站B也拿到了CA机构认证的证书，它想劫持网站A的信息。于是它成为中间人拦截到了A传

给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，

这确实会导致上文“中间人攻击”那里提到的漏洞？

  其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的

域名比对一下就知道有没有被掉包了。

 

为什么制作数字签名时需要hash一次？

我一开始看的时候也不知道为啥需要hash一下，感觉没有必要，直接对 明文数据T 加密不行吗？看参考博客的评论知道了，因为

可以保持性能，证书信息也就是 明文数据T 一般较长，比较耗时，hash之后能得到固定长度的信息（比如用md5算法hash后可以

得到固定的128位的值），这样之后用 私钥 进行非对称加密的时候提升性能，还有一点，非对称加密可以加密的消息体长度有上

限（public key length in bits / 8 - 11），否则会报错，所以必须先hash保证定长结果。

当然也有安全上的原因，这部分内容相对深一些

 
 
怎么证明CA机构的公钥是可信的？

上文中说到CA机构的公钥，几乎一笔带过，" 浏览器保有它的 公钥 ”，这是个什么保有法？怎么证明这个公钥是否可信？

  让我们回想一下数字证书到底是干啥的？没错，为了证明某公钥是可信的，即“该公钥是否对应该网站”，那CA机构的公钥是

否也可以用数字证书来证明？没错，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中会有CA机构的根证书，这样

就可以拿到它对应的可信公钥了。

  实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链。也就是一连

串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。

 
 
每次进行HTTPS请求时都必须在SSL/TLS层进行握手传输密钥吗？

  服务器会为每个浏览器（或客户端软件）维护一个session ID，在 TLS 握手阶段传给浏览器，浏览器生成好密钥传给服务器

后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的

密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！
 
 
 
 
为什么要用对称加密+非对称加密？
  对称加密虽然性能好但有密钥泄漏的风险

为什么不能只用非对称加密？
  非对称加密（2组公钥+2私钥双向传输）安全但性能低下

为什么需要数字证书？
  考虑用非对称加密来传输对称加密所需的密钥，然后进行对称加密，但是为了防止非对称过程产生的中间人攻击，需要对服务器公钥和服务器身份进行配对的数字认证，CA数字证书就是含有
签发者

证书用途

网站的公钥

网站的加密算法

网站用的HASH算法

证书到期时间等等

验证了是否为C真实请求的服务器H

 

为什么需要数字签名？
  CA会将数字证书发给网站，但这其中存在一个问题。CA在将数字证书发给网站的过程中，如果被第三人篡改，证书的存在也就没有意义了，因为第三人可以利用这一点，肆无忌惮的篡改数据。为了保证这一过程能顺利进行，不被篡改。CA把数字证书的内容再进行一次HASH，就得到了数字证书。最后，CA会将数字证书附在证书的末尾，一起传输给网站。这样一来，任何试图篡改证书的操作，都会被数字签名发现。

 
 

参考文章

彻底搞懂HTTPS的加密原理