HTTPS 加密原理探究

由于之前项目中IOS系统建议将http协议换成https协议所以查看相关资料在此记录 HTTPS 通讯过程的基本原理

问:Https是什么?

答:

HTTP 协议定义了一套规范,让客户端或浏览器可以和服务器正常通信,完成数据传输

但是,HTTP 使用明文传输,你输入的账户密码等重要信息易被中间人窃听,从而造成数据泄露,所以说 HTTP 是不安全的,为了解决安全传输的问题,人们发明了 HTTPS,即 HTTP + Secure

问:为什么 HTTPS 是安全的?

答:

只要把传输的数据加密,那么通信就是安全的,前提是除通信双方外,任何第三方无法解密

问:HTTPS 是怎么实现安全通信的?

答:

使用对称加密技术,简单而言,通信双方各有一把相同的钥匙(所谓对称),客户端把数据加密锁起来后,传送给服务器,服务器再用钥匙解密。同理,服务器加密后传输给客户端的数据,客户端也可以用钥匙解密,此处有一个新问题怎样在通信之前,给双方分配两把一样的钥匙呢?有一个简单的解决方案是:客户端在每次请求通信之前,先和服务器协商,通过某种办法,产生只有双方知道的对称密钥

这个过程就是所谓:密钥交换(Key Exchange),密钥交换算法有很多,常见的有

  • Deffie-Hellman 密钥交换算法
  • RSA 密钥交换算法

在此,以RSA算法为例进行介绍

RSA 密钥交换算法需要客户端向服务器提供一个 Pre-Master-Key,然后通信双方再生成 Master-Key,最后根据 Master-Key 产生后续一系列所需要的密钥,包括传输数据的时候使用的对称密钥。那么客户端怎么把 Pre-Master-Key 告诉服务器呢?

在此引入一种新的加密技术:非对称加密(服务器可以生成一对不同的密钥,一把私自保存,称为私钥;一把向所有人公开,称为公钥
这对密钥有这样的性质:公钥加密后的数据只有私钥能解密,私钥加密后的数据只有公钥能解密)

具体的交互过程:

  1. 客户端向服务器索取公钥 PublicKey;
  2. 服务器将公钥发给客户端(这里没有保密需求,因为公钥是向所有人公开的);
  3. 客户端使用服务器的公钥 PublicKey 把 Pre-Master-Key 加密成密文,传送给服务器;
  4. 服务器用私钥 PrivateKey 解密密文,获取到客户端发送的 Pre-Master-Key;

在此又会引发新的问题,由于互联网是公开的,服务器发送给客户端的公钥可能在传送过程中被中间人截获并篡改(所谓中间人攻击 Man-in-the-middle attack,缩写:MITM),因为中间人也可以生成一对非对称密钥,它会截获服务器发送的公钥,然后把它自己的公钥 MiddleMan-PublicKey 发送给客户端,进行欺骗。

为了解决这个问题,服务器需要到权威机构 (Authority) 办一张证书 Certificate,上面记载了服务器的域名、公钥、所属单位,还有签发机关、有效期等当客户端收到服务器发过来的证书后,只要证书不是伪造的,那么上面记载的公钥肯定也就是真的!

不过,这里又有个新问题:怎么证明证书不是伪造的?

只要服务器发送的证书上有权威机构 Authority 的签名,就可以确信证书是颁发给服务器的,而不是谁伪造的

如此看来

HTTPS 通信过程已经很明朗了:

  1. 操作系统/浏览器 自带了 CA 根证书;
  2. 客户端因此可以验证服务器发送的证书真实性,从而获取到服务器的公钥;
  3. 有了服务器的公钥,客户端就可以把 Pre-Master-Key 传送给服务器;
  4. 服务器获取到 Pre-Master-Key 后,通过后续产生的对称密钥,就可以和客户端加密通信了。
上一篇:web标准(复习)--5 超链接伪类


下一篇:rm:删除目录和文件