问题描述：HTTP的请求和响应都是明文传输，有安全隐患

HTTPS：HTTPS并不是一个单独的协议，是在 TCP 和 HTTP 之间加入了 SSL/TLS 安全协议，使得报文能够加密传输，SSL是TLS的前身，现在使用的大多都是TLS。

对称加密与非对称加密

对称加密：发送方和接收方约定一个同样的规则也就是同一个密钥来对传输的信息进行加密和解密。
非对称加密：用两个密钥来进行加密和解密，公钥是所有人都可以得到的密钥，私钥是只有持有方才知道的密钥。一般情况下服务器拥有公钥和私钥，然后公布自己的公钥在网络上，客户端用这个公钥进行数据加密，此时只有服务器上的私钥才能进行解密。

TLS握手过程

TLS是同时使用了对称加密和非对称加密。
首先服务器需要向CA（证书授权中心）申请TLS证书来表明自己是经过验证的真实服务器，而不是伪造的。TCP三次握手的过程还是不变的，然后开始TLS握手。

1. 客户端向服务器发送自己支持的TLS版本，支持的加密算法和一个随机数（第1个随机数）。
2. 服务器响应自己确认的TLS版本，加密的算法和自己生成的一个随机数（第2个随机数），然后服务器继续发送自己的证书和公钥。
3. 客户端验证了服务器的证书后，会生成一个预主密钥（第3个随机数），并且用收到的公钥加密然后发送出去。
4. 服务器收到后用私钥进行解密得到客户端的预主密钥，此时只有客户端和服务器知道这个预主密钥是什么，除非私钥被泄漏了。
5. 然后客户端和服务器都使用预主密钥+第1随机数+第2随机数 计算出一个会话密钥。
6. 也就是到了这一步，前面的加密都是非对称加密，目的就是得到这个会话密钥，之后的实际数据传输都使用这个会话密钥进行加密解密，所以正常的数据传输部分用的就是对称加密了。

HTTPS连接过程一定可靠吗

有这么一种情况，客户端通过浏览器向服务端发起 HTTPS 请求时，被「假基站」转发到了一个「中间服务器」，客户端是和「中间服务器」完成了 TLS 握手，然后这个「中间服务器」再与真正的服务端完成 TLS 握手。
从客户端的角度看，其实并不知道网络中存在中间服务器这个角色。那么中间服务器就可以解开浏览器发起的 HTTPS 请求里的数据，也可以解开服务端响应给浏览器的 HTTPS 响应数据。
但这有个前提，就是用户点击接受了中间服务器的证书。
因为中间服务器与客户端的 TLS 握手过程中，会发送自己伪造的证书给浏览器，而这个伪造的证书是能被浏览器识别出是非法的，于是就会提醒用户该证书存在问题。