HTTPS 加密原理探究

标签：ast   传输   中间人   中间   而不是   解密   middle   引入   bsp   

由于之前项目中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 后，通过后续产生的对称密钥，就可以和客户端加密通信了。

HTTPS 加密原理探究

标签：ast   传输   中间人   中间   而不是   解密   middle   引入   bsp   

原文地址：http://www.cnblogs.com/Fanzifeng/p/7150099.html