HTTPS的原理

WEB服务存在http和https两种通信方式，http默认采用80作为通讯端口，对于传输采用不加密的方式，https默认采用443，对于传输的数据进行加密传输

HTTP协议

HTTP协议（HyperText Transfer Protocol，超文本传输协议）是基于TCP协议的应用层协议。只要用于主机之间的通讯，HTTP协议属于无状态协议，即每次通信都要通过3次TCP握手，来建立连接，通信结束后，4次挥手断开连接，这样做最初的目的是为了保持HTTP协议的简单性，从而能够快速处理大量的事务, 提高效率。

HTTP协议其实分为两个部分，分别是请求和相应两部分，一次请求对应一次响应

TCP三次握手

下面是TCP报文的结构，其中ACK、SYN、FIN是TCP结构中的控制位

确认位ACK：

ACK=1表示确认号（下一个TCP报文的序号）有效，建立连接后每个TCP报文ACK都等于1，直到最后一个ACK为0

同部位SYN：

SYN=1表示请求/接受TCP连接。两个主机建立连接时，前两次握手就会发送这个字段，之后都为0

终止位FIN：

FIN=1表示发送数据完毕

TCP四次挥手

为什么客户端需要等到2MSL（2*最大报文段生存时间）时间后才能彻底关闭连接？

可能会有些TCP包因为网络问题丢包了，客户端通知服务端重传到客户端接收到这个包时间不会超过2MSL。如果提前关闭了连接，可能会导致旧数据包被新连接错误地接收
如果2MSL时间内客户端继续接收到了包，客户端会像正常情况一样，继续返回ACK确认，并重新计时2MSL

HTTPS协议

因为HTTP协议采用明文传输数据，所以具有安全问题，所以出现了HTTPS协议，HTTP协议通过和 SSL（Secure Socket Layer, 安全套接层 ）或 TLS（Transport Layer Security, 安全层传输协议）的组合使用，将整个通信线路中的数据加密。

HTTPS协议使用对称密钥和非对称密钥混合加密的方式，来进行通信。过程类似于下图，主要分为两个部分

使用非对称加密协商，安全的分配对称密钥
通信使用对称密钥加密

HTTPS图片地址

对于上图，有下面几点需要知道：

服务端返回的证书结构：证书明文信息+公钥+签名
公钥和私钥是一对的，服务端开发者从CA申请的证书中有私钥，而对应的公钥在客户端，只不过对应的客户端有大量CA颁发的公钥，需要通过上图的方式让客户端知道该使用哪个公钥
公钥加密的信息，只有私钥能解密。私钥加密的信息，只有公钥能解密
并不是所有的服务端的SSL证书在客户端都有对应的证书，例如：早期的一些国内银行的SSL证书，这种往往需要手动将他的证书下载到客户端中，并设置信任该证书，客户端才能在本地找的对应的公钥

为什么要大费周章的使用非对称加密呢？为什么需要CA颁发的证书呢？

对称加密的目的是为了安全的传输对称密钥，使的上方的通讯是被加密的。CA作为一个权威的第三方团体，具有一定的可信度，其颁发的证书中的私钥不可能随意泄漏出去，公钥也能预置在大部分系统的根证书中（市场占有率小的CA机构，有可能会出现证其证书，没有被预置在某个客户端中），且出于安全性考虑，现在的大部分浏览器强制要求使用HTTPS传输数据，如果服务端开发者不使用SSL证书，那网页的访问就会受到影响，以chrome为例子，使用HTTPS协议，但是返回的证书在本地找不到，就会被强制终止访问

从网上找了个图，大体描述了中间人攻击的手段，

这里的核心是中间人把自己的证书安装到了客户端，中间人持有一对假的公钥和私钥，而AC颁发的证书的私钥只有服务端能获取。

如果中间人不在客户端安装自己的证书，而是直接从客户端取出证书，再伪装成服务端跟其他客户端通信，它发送给客户端的这个证书不就能通过验证吗？确实可以通过验证，但后续的流程走不下去，因为下一步客户端会用证书里的公钥加密，中间人没有这个证书的私钥就解不出内容，也就截获不到数据，这个证书的私钥只有真正的服务端有，中间人伪造证书主要伪造的是公钥。