HTTPS协议详解

---

title: Https协议详解
date: 2020-04-28 14:00:25
update: 2020-04-28 14:00:25
tags:
- Https
categories:
- 网络
- Https

---

欢迎来我的个人网站，里面有最新的版本

这篇介绍了下HTTPS面试题常考内容，并做了延伸，解释了原理。

一、常见面试题

先来看看一些常见的面试题

Https的过程（对称加密和非对称加密，CA，还有随机数生成秘钥的方式）

二、Http和Https的区别

Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。二者之间存在如下不同：

端口不同：Http与Http使用不同的连接方式，用的端口也不一样，前者是80，后者是443；

资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；

开销：Https通信需要证书，而证书一般需要向认证机构购买；
　
Https的加密机制是一种共享密钥加密（SSL）和公开密钥加密（TLS）并用的混合加密机制。SSL/TLS分别为对称加密和非对称加密两种方式。

三、对称加密与非对称加密

3.1 对称加密

对称加密是指加密和解密都用同一份密钥。A和B通过协商确定加密算法（不同客户端与服务器之间的加密算法需要不同）以及密钥。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-z7zpY4Tm-1588931480213)(https://cdn.jsdelivr.net/gh/hhf443/blog-graph/img/20200508175056.png)]

但是存在着一个问题，A通过明文传输和server协商采用了加密算法A，但这条信息本身是没有加密的，密钥有可能泄漏，因此还是不安全。于是引入非对称加密对协商过程信息加密。

对称加密算法(加解密密钥相同)

名称	密钥长度	运算速度	安全性	资源消耗
DES	56位	较快	低	中
3DES	112位或168位	慢	中	高
AES	128、192、256位	快	高	低

3.2 非对称加密

在密码学跟对称加密一起出现的，应用最广的加密机制“非对称加密”，如图，特点是私钥加密后的密文，只要是公钥，都可以解密，但是反过来公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-b8GQ9L66-1588931430553)(https://cdn.jsdelivr.net/gh/hhf443/blog-graph/img/20200508175145.png)]

基于上述的特点，我们可以得出如下结论：

（1）公钥是开放给所有人的，但私钥是需要保密的，存在于服务端

（2）服务器端server向client端（A、B…）的信息传输是不安全的：因为所有人都可以获取公钥

（3）但client端（A、B…）向server端的信息传输确实安全的：因为私钥只有server端存在

因此，如何协商加密算法的问题，我们解决了，非对称加密算法进行对称加密算法协商过程。客户端用公钥对采用何种对称加密算法以及密钥进行加密，服务器接收到之后用私钥进行解密，只有服务器才知道和该客户端之间用什么加密算法以及密钥是什么。

非对称算法(加密密钥和解密密钥不同)

名称	成熟度	安全性(取决于密钥长度)	运算速度	资源消耗
RSA	高	高	慢	高
DSA	高	高	慢	只能用于数字签名
ECC	低	高	快	低(计算量小,存储空间占用小,带宽要求低)

四、HTTPS通信过程

回顾一下Http通信过程

1. 客户端连接到Web服务器。与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。

2. 发送HTTP请求
   通过TCP套接字，客户端向Web服务器发送请求报文由请求行、请求头部、空行和请求数据4部分组成。

3. 服务器接受请求并返回HTTP响应由状态行、响应头部、空行和响应数据4部分组成。

4. 释放连接TCP连接

5. 客户端浏览器解析HTML内容

Https通信过程

1. 客户端浏览器发起连接（Http通信的第一步），端口是443。
2. WEB服务器将公钥发给客户端。
3. 客户端生成一个session key，并且将session key用公钥加密后发送给服务器。
4. 服务器用私钥将session key解密出来。
5. 客户端和服务器用session key做对称加密通信。（Http通信的第二步）

实际上session key的生成是需要多次协商的结果。整个流程会有一个问题，第2步中WEB服务器发给客户端的公钥，万一被中间人修改了呢，换句话说，客户端怎么验证公钥的正确性呢？那就需要数字证书签发机构（CA）颁发的证书（SSL）

五、数字签名

五、证书、数字签名

在第 ② 步时服务器发送了一个SSL证书给客户端，SSL 证书中包含的具体内容有证书的颁发机构、有效期、公钥、证书持有者、签名，通过第三方的校验保证了身份的合法，解决了公钥获取的安全性。

（数字签名、摘要签名、摘要信息意义一样；摘要算法、哈希算法意义一样）

以浏览器为例说明如下整个的校验过程：

（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验

（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发

（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。

（4）如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密

（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比

（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充

（7）此时浏览器就可以读取证书中的公钥(这才是非对称加密的公钥)，用于后续加密了

申请者通过非对称加密算法（RSA） 生成一对公钥和密钥，然后把需要的申请信息（国家，域名等）连同公钥发送给 证书认证机构（CA）

CA机构确认无误后通过消息摘要算法（MD5，SHA) 生成整个申请信息的摘要签名M， 然后 把 签名M和使用的摘要算法 用 CA自己的私钥 进行加密

浏览器从操作系统中获取CA的公钥对数字签名进行解密，得到签名和摘要算法，用摘要算法对证书包含的公钥信息进行计算。如果计算得到的值和摘要签名m一样，说明证书中包含的公钥是正确的。

散列算法比较

名称	安全性	速度
SHA-1	高	慢
MD5	中	快

六、总结

HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。