1.HTTPS的由来  HTTP +加密+认证+完整性保护

我们知道HTTP是明文进行传输的，所有就有很多不安全性

. 重要信息可能被明文获取。

. 通信双方可能被仿冒。

. 数据信息被篡改。

一般信息如果是为了展示，安全性可能不用考虑那么多，但是诸如支付，银行这些数据信息就要考虑安全性的问题，这就出现了HTTPS。

1.1.HTTPS在OSI7层 的作用位置.

我们知道http是在应用层，tcp是传输层。由于职责单一、职责分离这样的思想 。所以应该就是这样，HTTP与TCP之间再加上一层SSL/TLS（Secure Sockets Layer/Transport Layer Security）协议。

图1 截自《图解HTTP》

2.SSL和TLS是什么东东。

图2 截自wikipedia

可以看书TLS和SSL是在应用层，

2.1 SSL和TLS 发展历程

SSL是TLS的前身，SSL从1.0、2.0到3.0一步步修订，但安全性都不是非常完美。知道后来SSL3.0摇身一变变成TLS1.0，发展至今已经达到TLS1.2的稳定版本。另外18年今年，TLS1.3的草案也已经提出，在不断开发中吧

SSL 1.0，未发布公开，因为严重的安全性漏洞

SSL 2.0，1995.02，包含一些需要在SSL3.0解决的安全漏洞

SSL 2.0 在2011年被RFC 6176禁止

SSL 3.0，1996，代表着该协议的完整重新设计，

SSL 3.0也在后来June 2015被RFC 7568禁止.

TLS 1.0在January 1999首次在RFC 2246中定义，作为SSL 3.0的升级版本

TLS 1.1April 2006在RFC 4346中定义

TLS 1.2August 2008 在RFC 5246定义，基于TLS 1.1进行升级

3 TLS/SSl工作机制

3.1 加密方法

共享密钥方式加密 = 对称加密 = 处理速度较快

公开密钥方式加密 = 非对称加密 = 更复杂，处理速度较慢

共享密钥方式加密只要密钥ok就足够安全，服务器只要把密钥交给客户端，然后通信过程中和客户端使用同一把密钥进行加密解密即可。毕竟是HTTP通信过程肯定是需要速度尽量快才是最好。

Q1：但是共享密钥如何安全地递交给对方？比如服务端如何把共享密钥安全交给客户端？

这时候就需要使用公开密钥方式加密。想用密文和公钥恢复到信息原文是异常困难的，相当于对离散对数进行求值，这不是轻而易举能达到的。（还是没有一个很好的概念，总之这很安全就对了）

发送方使用接收方的公钥对数据进行加密，然后接收方收到密文后使用密钥对数据进行解密。

接上一个问题：通信双方持有对方的公钥，发送共享密钥时使用公钥加密，就不怕共享密钥被获取了。

Q2：公钥毕竟是要发放出去的，如何证明发给客户端的过程中，公钥没有被替换掉呢？假如公钥被替换掉，伪冒者就可以假装成服务端和用户进行通信。

接下来就是数字证书认证机构出场。

HTTPS中，服务端将公钥发给数字证书认证机构进行安全认证并对公钥进行数字签名，完成后公钥和签名组合成数字证书。在和客户端通信时，服务端将数字证书发给客户端，客户端通过第三方安全认证机构发布的公钥（一般会在浏览器开发时，内置在浏览器中）对数字证书上的签名进行验证，假如验证通过，则能证明以下事实：

认证该服务器的公钥的机构是真实有效的数字证书认证机构

该服务器发过来的公钥是值得信赖的

因为通信双方都需要证明自己发出的公钥真实可靠，所以也就存在两种目的性不同的数字证书：可证明组织真实性的EV SSL证书、用以确认客户端的客户端证书

由于能力有限，分享到这。

参考文献 https://www.jianshu.com/p/6c981b44293d