江苏龙网

  1. 主页 > 生活百科 > >

如何理解HTTPS？可以收藏这一篇，足以应付面试！( 二 )

https


· 服务端收到请求，返回配置好的包含公钥 Pub 的证书给客户端 。
· 客户端收到证书，校验合法性，主要包括是否在有效期内、证书的域名与请求的域名是否匹配，上一级证书是否有效（递归判断，直到判断到系统内置或浏览器配置好的根证书），如果不通过，则显示 HTTPS 警告信息，如果通过则继续 。
· 客户端生成一个用于对称加密的随机 Key，并用证书内的公钥 Pub 进行加密，发送给服务端 。
· 服务端收到随机 Key 的密文，使用与公钥 Pub 配对的私钥 Private 进行解密，得到客户端真正想发送的随机 Key 。
· 服务端使用客户端发送过来的随机 Key 对要传输的 HTTP 数据进行对称加密，将密文返回客户端 。
· 客户端使用随机 Key 对称解密密文，得到 HTTP 数据明文 。
· 后续 HTTPS 请求使用之前交换好的随机 Key 进行对称加解密 。
 
对称加密与非对称加密
 
又是对称加密又是非对称加密，一会公钥一会私钥一会随机 Key，为什么要这么复杂呢，一套搞到底不好么？
 
对称加密是指有一个密钥，用它可以对一段明文加密，加密之后也只能用这个密钥来解密得到明文 。
 
如果通信双方都持有密钥，且天知地知你知我知，绝对不会有别的人知道，那么通信安全自然是可以得到保证的（在密钥足够强的情况下） 。
然而，在 HTTPS 的传输场景下，服务端事先并不知道客户端是谁，你也不可能在事先不通过互联网和每一个网站的管理员都悄悄商量好一个通信密钥出来 。
 
那么必然存在一个密钥在互联网上传输的过程，如果在传输过程中被别人监听到了，那么后续的所有加密都是无用功 。
 
这时，我们就需要另一种神奇的加密类型，非对称加密 。
 
非对称加密有两个密钥，一个是公钥，另一个是私钥 。一般来说，公钥用来加密，这时密文只能用私钥才能解开 。
 
那么，当客户端发起连接请求，服务端将公钥传输过去，客户端利用公钥加密好信息，再将密文发送给服务端，服务端里有私钥可以解密 。
 
但是，当服务端要返回数据，如果用公钥加密，那么客户端并没有私钥用来解密，而如果用私钥加密，客户端虽然有公钥可以解密 。但这个公钥之前就在互联网上传输过，很有可能已经有人拿到，并不安全，所以这一过程只用非对称加密是不能满足的 。注意，严格来讲，私钥并不能用来加密，只能用作签名使用，这是由于密码学中生成公钥私钥时对不同变量的数学要求是不同的 。
 
因此公钥私钥抵抗攻击的能力也不同，在实际使用中不可互换 。签名的功能在 HTTPS 里也有用到，下文中会说明 。
 
只有一组公钥私钥只能保证单程的加解密，那么如果我们准备两组公钥私钥呢，是不是可以解决这个问题？
 
来看下面这个过程：
· 服务端有非对称加密的公钥 A1，私钥 A2 。
· 客户端有非对称加密的公钥 B1，私钥 B2 。
· 客户端向服务端发起请求，服务端将公钥 A1 返回给客户端 。
· 浏览器收到公钥 A1，将自己保存的公钥 B1 发送给服务端 。
· 之后浏览器所有向客户端发送的数据，使用公钥 B1 加密，客户端可以使用私钥 B2 解密 。
· 客户端所有向服务端发送的数据，使用公钥 A1 加密，服务端可以使用私钥 A2 解密 。
 
此时，两条传输方向的数据都经过非对称加密，都能保证安全性，那么为什么不采用这种方案呢？
最主要的原因是非对称加解密耗时要远大于对称加解密，对性能有很大损耗，大家的使用体验很差 。
所以，我们才最终选用了上文介绍到非对称加密+对称加密的方案，再复习一下：
· 服务端有非对称加密的公钥 A1，私钥 A2 。
· 客户端发起请求，服务端将公钥 A1 返回给客户端 。
· 客户端随机生成一个对称加密的密钥 K，用公钥 A1 加密后发送给服务端 。
· 服务端收到密文后用自己的私钥 A2 解密，得到对称密钥 K，此时完成了安全的对称密钥交换，解决了对称加密时密钥传输被人窃取的问题 。
· 之后双方通信都使用密钥 K 进行对称加解密 。
 
看起来是一个非常完美的方案，兼顾了安全性和性能，但是，真的就安全了么？
 
CA 颁发机构


推荐阅读


上一篇：数据采集技术简介

下一篇：识破网络诈骗陷阱 保护我们的钱袋子