一、简介
HTTP是我们常用的处于应用层的协议，但是HTTP协议传输数据是明文传输，任意的人抓包就能看到传输的数据，任意的人都可以提交匿名请求，这是不安全的。
为了解决上面的问题。我们对HTTP基础上增加SSL,形成了HTTPS。
《图解HTTP》这本书中曾提过HTTPS是身披SSL外壳的HTTP。HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。
二、安全的通信方式具有的特征
- 服务器认证 (客户端知道它们是在与真正的而不是伪造的服务器通话)。
- 客户端认证 (服务器知道它们是在与真正的而不是伪造的客户端通话)。
- 完整性 (客户端和服务器的数据不会被修改)。
- 加密 (客户端和服务器的对话是私密的，无需担心被窃听)。
- 效率 (一个运行的足够快的算法，以便低端的客户端和服务器使用)。
- 普适性 (基本上所有的客户端和服务器都支持这些协议)。
- 管理的可扩展性 (在任何地方的任何人都可以立即进行安全通信)。
- 适应性 (能够支持当前最知名的安全方法)。
- 在社会上的可行性 (满足社会的政治文化需要)。
三、解决安全性
1、采用非对称加密方式
采用非对称加密方式，服务器就需要生成公钥和私钥，每当客户端请求时，服务器发送公钥给客户端，接着双方通信采用非对称加密方式加密通信内容。
这样的方式是可以的，可以解决一部分的问题，解决了客户端发送内容的私密性，因为公钥加密的内容只能私钥解密，而只有服务器有私钥。但是服务器发送给客户端的就还是相当于明文，因为公钥是你签发的，并且明文发送，也就是说别人只要拦截了你这条公钥明文，你发送给客户端的内容，客户端能解开，拦截者也能解开。并且拦截者还可以使用你的公钥匿名发送请求到服务器，服务器也发现不了。
还可以更加恶意的将拦截下来的公钥换成拦截者的自己公钥，这样客户端的接收到的是拦截者的公钥，他不知道的情况下继续通信，拦截者就相当于既可以冒充服务器，也可以冒充客户端，所以也是不太行的。
2、 采用对称加密的方式
对称加密加密和解密采用同一套秘钥，可能不可能在网络中实时生成分发，只能在客户端和服务器端双方提前约定嵌入公私钥信息。这样肯定不太好，但是对称加密的计算要简单于非对称，可以节约服务器资源。
四、HTTPS
HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议，TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。
使用对称密钥的好处是解密的效率比较快，使用非对称密钥的好处是可以使得传输的内容不能被破解，因为就算你拦截到了数据，但是没有对应的私钥，也是不能破解内容的。那我们就将对称加密与非对称加密结合起来,充分利用两者各自的优势，在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。
具体做法是：发送密文的一方使用对方的公钥进行加密处理“对称的密钥”，然后对方用自己的私钥解密拿到“对称的密钥”，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。所以，HTTPS采用对称加密和非对称加密两者并用的混合加密机制。
但是这样依旧不能保证公钥的安全性，没有被人劫持。
解决方法是使用CA（数字证书认证机构）来保证，数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。
我们来介绍一下数字证书认证机构的业务流程：
1、服务器的运营人员向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;
2、CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
3、如信息审核通过，CA会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。 其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名;
4、客户端 Client 向服务器 Server 发出请求时，Server 返回证书文件;
5、客户端 Client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。
6、客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。
五、HTTPS的具体通信过程
.Client发起一个HTTPS（比如https://www.baidu.com/）的请求，根据RFC2818的规定，Client知道需要连接Server的443（默认）端口。
2.Server把事先配置好的公钥证书（public key certificate）返回给客户端。
3.Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。
4.Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。
5.Server使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。
6.Server使用对称密钥加密“明文内容A”，发送给Client。
7.Client使用对称密钥解密响应的密文，得到“明文内容A”。
8.Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”。
以上的过程都是带有数字签名的，能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。数字签名能确定消息的完整性,证明数据是否未被篡改过。
总结
1、总体来讲，我们使用非对称加密保证对称加密的秘钥，使用CA保证非对称加密的公钥，那么CA的保证谁来做？这个就是套娃，我们默认是信任数字证书机构的。
2、这样的https是可以确保服务器是我们可以访问的安全的服务器，但是客户端是不是安全的客户端这个无法保证，我们可以通过其他鉴权方式去验证，也就是说，其实是单向的。
