首先我们应该清楚，HTTPS的出现是为了解决什么问题？
谈这个之前，我们首先来了解一下HTTP
什么是HTTP
HTTP(HyperText Transfer Protocol) 超文本传输协议，是因特网上应用最为广泛的一种网络传输协议。
但是它有一个致命的缺点，就是明文传输，没有经过任何的加密，而这些明文会经过节点，类似于路由器、wifi、运营商等，如果在其中一个节点被劫持的话，传输的内容就会被暴露，我们称它为中间人劫持
举个例子说明一下：
某高中学校正在进行一次摸底考试，有个学生A坐在窗边，有同学B坐在角落，这时候A将一张写好答案的纸条传给B，这其中需要通过多个同学传递，虽然纸条折叠，但其中某个C同学打开纸条，将答案抄下来，然后改成错误的，B拿到纸条，把错误答案写下来了，然后B将他擅长的考题的答案写下来传给A，其中经过C，C又把正确答案抄下来，改成错误答案传给了A，结果A,B双方都不知道写了错误答案，C拿到了2方的正确答案
------------------------------------------------------------------------------------------------------------------------
还有我们听过说，「不要连陌生的WiFi」，如果是恶意的wifi控制者，它就能看到HTTP明文加密的信息和进行篡改
为了解决HTTP明文传输数据可能导致的安全问题，1994年网景公司提出了HTTPS（HyperText Transfer Protocol Secure）超文本传输安全协议，数据通信依然是HTTP，但是是利用SSL/TLS加密数据
什么是SSL/TLS
SSL(Secure Sockets Layer)是安全套接层，TLS(Transport Layer Security)是传输层安全协议
1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。
1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。
1996年，SSL 3.0版问世，得到大规模应用。
1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。
2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。
目前最新版的TLS协议是TLS 1.3，于2018年公布。
SSL/TLS是为了解决明文传输的几个安全风险：
1）窃听风险
2）篡改风险
3）冒充风险
相应的，SSL/TLS是采用这么几个方式进行应对的：
1）加密：非对称加密+对称加密，主要解决的是窃听风险
2）校验：数字签名，主要解决的是篡改风险
3）证书：数字证书，主要解决的是冒充风险
HTTPS实现原理
那么首先我们先来看下HTTPS的工作流程
一步一步解析：
-
客户端先向服务器端发起请求（https的默认端口号是443）
-
https会有CA证书，里面有一个公钥PUB，这个公钥会对应一个私钥private
-
服务端响应请求给客户端，包含证书信息（加密的哈希数据和明文数据）
-
客户端接收到响应请求，会验证证书的有效期，主要包括是否在有效期内、证书的域名与请求的域名是否匹配，上一级证书是否有效，如果不通过，则显示HTTPS警告信息，如果通过则继续；
-
客户端通过公钥pub对随机生成的key进行加密，并发送给服务器
-
服务器接收到密文之后，会使用私钥进行解密，获取到随机key,并且利用随机key对明文信息加密
-
将http加密的数据的数据返回给客户端
-
客户端利用之前的随机key进行解密，获取到http的密文信息
-
最后通过随机key加解密进行后续的请求和响应
浏览器如何验证证书的合法性？
浏览器发起 HTTPS 请求时，服务器会返回网站的 SSL 证书，浏览器需要对证书做以下验证：
1.验证域名、有效期等信息是否正确。证书上都有包含这些信息，比较容易完成验证；
2.判断证书来源是否合法。每份签发的证书都可以根据验证链找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证；
3.验证CA证书是否被篡改，需要跟CA服务器进行校验
4.判断证书是否已吊销。通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与 CA 服务器的交互，提高验证效率
随机数被窃取怎么办？
证书验证是采用非对称加密实现，但是传输过程是采用对称加密，而其中对称加密算法中重要的随机数是由本地生成并且存储于本地的，HTTPS 如何保证随机数不会被窃取？
其实 HTTPS 并不包含对随机数的安全保证，HTTPS 保证的只是传输过程安全，而随机数存储于本地，本地的安全属于另一安全范畴，应对的措施有安装杀毒软件、反木马、浏览器升级修复漏洞等。
对称加密和非对称加密
为什么https的工作流程一会对称加密，一会非对称加密呢？
什么是对称加密
对称加密是指有一个密钥，它可以对一段明文加密，加密之后也只能用这个密钥来解密得到明文。如果通信双方都持有密钥，那么通信安全自然是可以得到保证的（在密钥足够强的情况下）。
但是在现实的HTTPS请求中，服务器和客户端无法准确的知道对方是谁，那么就会存在一个密钥在传输的过程中，如果在传输过程中被别人监听或者篡改了，那么后续的所有加密都是无用功。
什么是非对称加密
非对称加密有两个密钥，一个是公钥，另一个是私钥。一般来说，公钥用来加密，那么密文就只能用私钥才能解开。（私钥是保存在服务器当中的）
当客户端发起请求的时候，服务端会把公钥传过去，然后客户端根据获取的公钥进行加密，再将密文传输给服务器，服务器利用私钥可以对密文进行解密，但是当服务器要返回信息的时候，如果用公钥进行加密的话，客户端没有私钥进行解密，如果使用私钥加密，那么客户端利用公钥进行解密，但是这个公钥之前在网络中传输过，它有可能已经泄露，这样并不安全
那么其实还有一个问题跟其相关，那就是竟然证书是公开的，那么在发起中间人攻击的时候，我们可以在官网上下载
一个证书作为服务器的证书，客户端肯定认为该证书是合法的，那么要如何避免这种冒用证书的情况呢？
那么这时候就要用到非对称加密的私钥了，我们不能根据一个公钥去推断出一个私钥，私钥是存储在服务器中的，那么中间人拿到证书也不能伪装成合法的服务器，因为它无法将客户端加密传输过来的内容进行解密
所以结合上述2种加密的优缺点，https选择对称加密+非对称加密的方案
也有同学可能会说，为什么不考虑2个非对称加密呢？一组公钥私钥只能保证单程的加解密，那么如果我们准备两组公钥私钥呢，是不是可以解决这个问题？
是的，其实不然，这个方案是可行的，但是非对称加密对于对称加密来说，最主要的原因是非对称加解密耗时要远大于对称加解密，对性能有很大损耗，大家的使用体验很差。
CA机构
我们可以看到，https是需要一个CA证书的，那这又是为什么呢？
还是考虑到中间人攻击，其中非对称加密是有一堆公钥和私钥的，但是由于他的算法都是公开的，所以任何人都可以生成一堆公钥和私钥
举个例子：
当浏览器A向服务器C发送请求时，中间有个运营商B，那么在C向A返回公钥A1时，B将其替换成自己的公钥B1传送给浏览器，当浏览器接收到B1的公钥时，（还美滋滋的，不知道公钥已经被替换了），利用公钥进行加密，将密文D传送给服务器，在传送的过程中，又被B截取，B通过自己的私钥，解码密文D，并通过服务器的公钥A1重新进行加密，并传送给服务器，完成了通信。而客户端和服务器对此都浑然不觉
出现这一问题的核心原因是客户端无法确认收到的公钥是不是真的是服务端发来的。为了解决这个问题，互联网引入了一个公信机构，这就是CA。
私钥除了解密外的真正用途其实还有一个，就是数字签名，其实就是一种防伪技术，只要有人篡改了证书，那么数字签名必然校验失败。具体过程如下：
服务器私钥将一段消息进行加签(对加密部分进行哈希，再用私钥对哈希进行数字签名)，然后将签名部分和消息本身一起发送给浏览器，浏览器收到消息后对签名部分利用公钥验签，如果验签出来的内容和消息本身一致，表明消息没有被篡改。
在整个过程中，浏览器中内置的CA证书和公钥成为了至关重要的环节，这也是CA机构公信身份的证明，如果浏览器中没有这个CA证书，那么客户端可以不接受服务端传回的证书，显示HTTPS警告。
所有回头一开始的提问，HTTPS是解决了什么问题？
HTTPS是为了解决HTTP明文传输过程中信息被篡改和监听的问题。
同时，为了保证公钥传输中不被篡改，又使用了非对称加密的数字签名功能，借助CA机构正式机制保证了HTTPS证书的公信力。
之前出现了好几家CA证书私钥泄露的问题，所以大家在选择CA证书的时候还需要小心
