协议
1、HTTP 协议（HyperText Transfer Protocol，超文本传输协议）：是客户端浏览器或其他程序与Web服务器之间的应用层通信协议 。
2、HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：可以理解为HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL，用于安全的 HTTP 数据传输。
如上图所示 HTTPS 相比 HTTP 多了一层 SSL/TLS
SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。
TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。
加密算法：
据记载，公元前400年，古希腊人就发明了置换密码；在第二次世界大战期间，德国军方启用了“恩尼格玛”密码机，所以密码学在社会发展中有着广泛的用途。
1、对称加密
有流式、分组两种，加密和解密都是使用的同一个密钥。
例如：DES、AES-GCM、ChaCha20-Poly1305等
2、非对称加密
加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的。非对称加密算法性能较低，但是安全性超强，由于其加密特性，非对称加密算法能加密的数据长度也是有限的。
例如：RSA、DSA、ECDSA、 DH、ECDHE
3、哈希算法
将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多，且算法不可逆。
例如：MD5、SHA-1、SHA-2、SHA-256 等
4、数字签名
签名就是在信息的后面再加上一段内容（信息经过hash后的值），可以证明信息没有被修改过。hash值一般都会加密后（也就是签名）再和信息一起发送，以保证这个hash值不被修改。
详解
一、HTTP 访问过程
抓包如下：
如上图所示，HTTP请求过程中，客户端与服务器之间没有任何身份确认的过程，数据全部明文传输，“裸奔”在互联网上，所以很容易遭到黑客的攻击，如下：
可以看到，客户端发出的请求很容易被黑客截获，如果此时黑客冒充服务器，则其可返回任意信息给客户端，而不被客户端察觉，所以我们经常会听到一词“劫持”，现象如下：
下面两图中，浏览器中填入的是相同的URL，左边是正确响应，而右边则是被劫持后的响应
所以 HTTP 传输面临的风险有：
（1） 窃听风险：黑客可以获知通信内容。
（2） 篡改风险：黑客可以修改通信内容。
（3） 冒充风险：黑客可以冒充他人身份参与通信。
二、HTTP 向 HTTPS 演化的过程
第一步：为了防止上述现象的发生，人们想到一个办法：对传输的信息加密（即使黑客截获，也无法破解）
如上图所示，此种方式属于对称加密，双方拥有相同的密钥，信息得到安全传输，但此种方式的缺点是：
（1）不同的客户端、服务器数量庞大，所以双方都需要维护大量的密钥，维护成本很高
（2）因每个客户端、服务器的安全级别不同，密钥极易泄露
第二步：既然使用对称加密时，密钥维护这么繁琐，那我们就用非对称加密试试
如上图所示，客户端用公钥对请求内容加密，服务器使用私钥对内容解密，反之亦然，但上述过程也存在缺点：
（1）公钥是公开的（也就是黑客也会有公钥），所以第 ④ 步私钥加密的信息，如果被黑客截获，其可以使用公钥进行解密，获取其中的内容
第三步：非对称加密既然也有缺陷，那我们就将对称加密，非对称加密两者结合起来，取其精华、去其糟粕，发挥两者的各自的优势
如上图所示
（1）第 ③ 步时，客户端说：（咱们后续回话采用对称加密吧，这是对称加密的算法和对称密钥）这段话用公钥进行加密，然后传给服务器
（2）服务器收到信息后，用私钥解密，提取出对称加密算法和对称密钥后，服务器说：（好的）对称密钥加密
（3）后续两者之间信息的传输就可以使用对称加密的方式了
遇到的问题：
（1）客户端如何获得公钥
（2）如何确认服务器是真实的而不是黑客
第四步：获取公钥与确认服务器身份
1、获取公钥
（1）提供一个下载公钥的地址，回话前让客户端去下载。（缺点：下载地址有可能是假的；客户端每次在回话前都先去下载公钥也很麻烦）
（2）回话开始时，服务器把公钥发给客户端（缺点：黑客冒充服务器，发送给客户端假的公钥）
2、那有木有一种方式既可以安全的获取公钥，又能防止黑客冒充呢？ 那就需要用到终极武器了：SSL 证书（申购）
如上图所示，在第 ② 步时服务器发送了一个SSL证书给客户端，SSL 证书中包含的具体内容有：
（1）证书的发布机构CA
（2）证书的有效期
（3）公钥
（4）证书所有者
（5）签名
………
3、客户端在接受到服务端发来的SSL证书时，会对证书的真伪进行校验，以浏览器为例说明如下：
（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验
（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
（4）如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密
（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充
（7）此时浏览器就可以读取证书中的公钥，用于后续加密了
4、所以通过发送SSL证书的形式，既解决了公钥获取问题，又解决了黑客冒充问题，一箭双雕，HTTPS加密过程也就此形成
所以相比HTTP，HTTPS 传输更加安全
（1） 所有信息都是加密传播，黑客无法窃听。
（2） 具有校验机制，一旦被篡改，通信双方会立刻发现。
（3） 配备身份证书，防止身份被冒充。
Https通信详解
客户端发出握手请求(Client Hello)，包含以下信息：
- 支持的协议版本，比如TLS 1.0版。
- 一个客户端生成的随机数(random_1)，这个随机数既需要客户端保存又需要发送给服务器。
- 支持的加密方法，比如RSA公钥加密。
- 支持的压缩方法。
服务器回复(Server Hello)，包含以下信息：
- 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
- 一个服务器生成的随机数(random_2)。
- 确认使用的加密方法，比如RSA公钥加密。
- 服务器证书。
- 如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供”客户端证书”。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
客户端回应，包含以下步骤：
- 验证服务器证书的合法性，证书合法性包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；
- 客户端使用一些加密算法(例如：RSA,Diffie-Hellman)产生一个48个字节的Key，这个Key叫PreMaster Secret。该PreMaster Secret用服务器公钥加密传送，防止被窃听。
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
- 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
- 如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。
服务器回应，服务器通过上面的三个随机数(random_1,random_2,PreMaster Secret)，计算出本次会话的『会话密钥(session secret)』，然后向客户端发送下面信息
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
- 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，服务器和客户端的握手阶段全部结束，接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用『会话密钥(session secret)』对内容做对称加密。
PreMaster Secret 说明
PreMaster secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成Master secret。在客户端使用服务单的公钥对PreMaster secret进行加密之后传送给服务端，服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。
关于Master Secret的计算
至于为什么一定要用三个随机数，来生成Master Secret，由于SSL协议中证书是静态的，因此需要引入一种随机因素来保证协商出来的密钥的随机性。SSL协议不信任每个主机都能生成完全随机的随机数，所以这里需要服务器和客户端共生成3个随机数，每增加一个自由度，随机性就会相应增加。
同时需要注意前两个随机数都是明文传输的，窃听者是可以轻易获取到的，只有最后一个 PreMaster Secret 是加密传输的，只有拥有服务器私钥才能解密，一旦 PreMaster Secret 泄露，那么本次通信就就完全可被破解了。
对称加密 & 非对称加密
HTTPS 的通信过程中只在握手阶段使用了非对称加密，后面的通信过程均使用的对称加密。尽管非对称加密相比对称加密更加安全，但也存在两个明显缺点：
- CPU 计算资源消耗非常大。一次完全 TLS 握手，密钥交换时的非对称解密计算量占整个握手过程的 90% 以上。而对称加密的计算量只相当于非对称加密的 0.1%，如果应用层数据也使用非对称加解密，性能开销太大，无法承受。
- 非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是 2048 位，意味着待加密内容不能超过 256 个字节。
所以公钥加密目前只能用来作密钥交换或者内容签名，不适合用来做应用层传输内容的加解密。
非对称密钥交换算法是整个 HTTPS 得以安全的基石，充分理解非对称密钥交换算法是理解 HTTPS 协议和功能的关键。
安全性
针对 HTTPS 的攻击最主要的就是 SSL 劫持攻击，其分为两种：
HTTPS 替换为 HTTP
这种方式就是攻击者充当中间人和服务器通信，然后把相应的通信内容通过 HTTP 协议发送给客户端，由于 HTTP 协议是未加密的，于是就可以截获用户的访问数据。
这种攻击方式比较简单，通过代理，可以很容易的把 HTTPS 变成 HTTP，这个一方面需要用户留意网站是否有从 HTTPS 跳转到 HTTP 的行为，另一方面服务器也可以通过配置将所有HTTP的请求强制转移到HTTPS上。
HTTPS 劫持
这种方式攻击者为了获得 HTTPS 的明文传输内容，需要充当中间人，替换服务器发给用户的包含公钥的证书。攻击者既和用户之间建立了 HTTPS 链接，又和服务器建立了 HTTPS 链接。
在上面握手建立的过程中，由于用户的公钥是攻击者生成的，所以攻击者可以轻易获得握手中的数据。也就可以获取到和用户通信过程中的对称加密的密钥，攻击者可以通过密钥获取用户发送的数据，同时在使用和服务器通信的密钥加密后再发送给服务器。
这种攻击方式也有一个明显的问题就是攻击者生成的证书几乎是不可能被用户信任的，在这种情况下，用户浏览器通常会提示该网站的证书不可信，是否继续访问，这已经对用户进行了一个明显的警告了。
另外我们也可以通过这种对基于 HTTPS 的通信进行抓包分析。Mac 平台著名的抓包工具 Charles 就是基于这种方式，首先要求你信任一个它的证书，然后自己充当中间人对你与某个服务器的 HTTPS 通信进行抓包分析。
总结
Http请求是明文通讯的，所有信息可以通过中间人，代理一览无遗， 所以我们需要一种加密后的通讯机制， 探索过程中有下面几种方案：
- 对称加密，客户端和服务器端都维护相同的密钥，对内容进行加密解密，缺点是双方都需要维护大量的密钥，维护成本很高， 而且他们的安全性不同，很容易就会泄漏。
- 非对称加密，客户端使用公钥加密内容，服务器使用私钥解密，缺点是客户端的公钥是公开的，很容易暴露给黑客。
- 非对称加密和对称加密结合：
客户端发出握手请求(Client Hello)：
- 支持的协议版本，比如TLS 1.0版。
- 一个客户端生成的随机数(random_1)
- 支持的加密方法，比如RSA公钥加密。
服务器回复(Server Hello)：
- 确认协议版本， 比如TLS 1.0版。
- 生成一个随机数random_2，发给客户端
- 确定加密方法，比如RSA
- 服务器证书。（包括公钥，证书各种信息）
客户端回应：
- 验证证书各种有效性，包括证书有效期，域名，公钥是否正确
- 告诉服务器端以后对话使用对称加密。
- 使用一些加密算法(例如：RSA,Diffie-Hellman) 生成一个PreMaster Secret
- 使用公钥加密PreMaster Secret等信息，发送给服务器端。（也就是这里使用了非对称加密）
服务器端回应
- 收到信息后用私钥解密（也就是这里使用了非对称加密）
- 服务器通过上面的三个随机数(random_1,random_2,PreMaster Secret)，计算出本次会话的『会话密钥(session secret)』
- 服务器端开始用session secret开始对称加密返回加密方法和密钥发送给客户端
参考：
HTTPS详解
HTTPS干货