上一章看了HTTP，它存在的不足如下
- 通信使用明文(不加密),内容可能会被窃听
- 不验证通信方的身份,因此有可能遭遇伪装，如抓包
- 无法证明报文的完整性,所以有可能已遭篡改
二、HTTPS
2.1 HTTPS 的格式
针对HTTP的缺点 HTTPS 的结构如下模式：
HTTPS = HTTP + 数据加密、证书校验、数据完整性
而对于加密，认证和完整性验证这些特点，TCP/IP协议族中已经提供了一个用于数据安全传输的协议——SSL（Secure Socket Layer）安全套接层，SSL3.0后改名为TLS，TLS相对与SLL在安全上有了改进，可见HTTPS的实现格式如下：
HTTPS = HTTP + SSL/TLS
2.2 HTTPS 验证过程
参考如下图：
我们知道HTTPS是在HTTP的基础之上，而HTTP由于基于TCP进行数据传输的，可见HTTPS的验证过程也是在建立TCP握手完成之后进行。并且也知道了解HTTPS的验证过程重点是SSL/TLS的握手过程
三、 SSL协议
3.1 SSL协议概述
SSL协议是基于TCP、位于应用层、传输层层之间，提供数据加密、用户验证和保证数据完整性的一种网络协议。TLS是SSL3.0时候的称呼。分为handshark（握手）、record（记录）两种协议，这里我们主要分析握手协议。
3.2 SSL/TLS 加密方式
验证过程是 非对称加密和对称加密结合
理解对称加密和非对称加密：
1> 加密算法一般分为两种: '对称加密' 和 '非对称加密'。
2> '对称加密': 也叫'密钥加密'，就是指加密和解密使用的是相同的密钥。
3> '非对称加密': 也叫'公钥加密'，就是指加密和解密使用的是不同的密钥。
3.3 SSL/TLS特性
- 认证用户和服务器，确保数据发送到正确的客户机和服务器；
- 加密数据以防止数据中途被窃取；
- 维护数据的完整性，确保数据在传输过程中不被改变。
3.4 SSL 的握手过程
参考微软官网说明：
- The client sends the server the client's SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL.
- The server sends the client the server's SSL version number, cipher settings, session-specific data, and other information that the client needs to communicate with the server over SSL. The server also sends its own certificate, and if the client is requesting a server resource that requires client authentication, the server requests the client's certificate.
- The client uses the information sent by the server to authenticate the server (see Server Authentication for details). If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds to step 4.
- Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher being used) creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.
- If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.
- If the server has requested client authentication, the server attempts to authenticate the client (see Client Authentication for details). If the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.
- Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection).
- The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.
- The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.
- The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.
- This is the normal operation condition of the secure channel. At any time, due to internal or external stimulus (either automation or user intervention), either side may renegotiate the connection, in which case, the process repeats itself.
详细步骤：
总体步骤：
由图可知: 『握手阶段』涉及4次通信，我们一一来解读。需要注意的是，『握手阶段』的所有通信都是明文的。
第一步：客户端发出请求(ClientHello)
包含如下信息：
1> 客户端支持的协议版本，比如 TLS1.0版。
2> 一个客户端生成的随机数，稍后用于生成'对话密钥'。
3> 客户端支持的加密算法，比如RSA公钥加密。
4> 客户端支持的压缩方法。
5> session id （用于失败重连）
第二步： 服务端发送 Server Hello
包含如下信息：
1> 服务端支持的协议版本，比如 TLS1.0版。
2> 一个服务端生成的随机数，稍后用于生成'对话密钥'。
3> 选择一种客户端支持的加密算法，比如RSA公钥加密。
4> 选择一种客户端支持的压缩方法。
5> session id （用于失败重连）
6> 服务端认证的证书
除了上面的信息，如果服务器需要确认客户端的身份，就会再包含一项请求，
7> 要求客户端提供'客户端证书'。 可选的
比如: 金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
第三步： 客户端回应
-客户端收到服务器回应以后，首先验证服务器证书。
-如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
-如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
1> 产生一个随机数，用服务器证书公钥进行加密，这个随机数用于后期生成堆成密钥；
2> 通知编码改变，后期都使用按约定加密方式生成的堆成密钥master_secret进行数据加密；（master_secret使用客户端第一次随机数、本次随机数、服务端随机数按照约定的加密方式合成）
3> 如果服务器验证自己的话，客户端需要加上自己的CA证书；
4> 客户端握手结束通知
注意：
- 上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。
- 之所以使用 客户端第三个随机数（即pre-master key）、和其他两个随机一起合成是因为，这样提高绝对的随机性，破解几率更小
第三步：服务器的最后响应
服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
1> 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
2> 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"对通信内容进行加密。
客户端和服务端校验过程 双向概括步骤：
图中第4步、第五步，服务器会对客户端进行校验是否是合法的用户；
HTTPS 真的安全么?
这里需要对抓包过程的原理做一个简单的介绍，Charles，Charles相对于客户端和服务器来说充当了客户端/服务端的角色，当客户端进行第一次握手的时候被Charles拦截，被截取了随机数，当服务器握手返回时，截取了随机数、证书以及公钥，然后替换成自己的证书以及公钥发给了客户端，客户端手机如果下载好了Charles的证书，这时校验证书是合法的，客户端会产生Pre_master_secret 用charles 公钥加密发出，这时被Charles拦截，Charles用自己的私钥解密得到Pre_master_secret，然后又使用服务器证书的公钥加密发给服务器，随后客户端虽然都可以生成对应的对称密钥，但是殊不知Charles也利用随机数和他们的加密方式导出对称密钥。具体步骤如下：
Charles 抓包Https原理
参考我的 Charles 抓包Https原理 ：https://www.jianshu.com/p/a7d9710ce46d
HTTPS 有防止策略吗？
答案：是，有的，但是不能绝对的安全，这是破解的成本提高；
- 使用自定义协议；
- 使用SSL Pinning;
自定义协议-基于TCP
使用自定义协议，也就是以TCP/UDP为基础，使用Socket进行通信（具体可参考网络编程之理论篇），这种方式由于不是使用的Http/Https协议，所以可避免Http类型的抓包工具（如Charles, Fiddler）进行抓包, 但不可避免WireShark，毕竟它太强大，可抓取网络模型中各层的数据。
使用SSL Pinning
看着很陌生，其实也不是啥新技术，只需要将服务端的公钥证书一起打到APK中，在网络请求时，与服务端的公钥证书进行比较，即可避免抓包工具使用构造证书进行抓包的情况。
-参考：
微软官网： [https://support.microsoft.com/en-us/help/257591/description-of-the-secure-sockets-layer-ssl-handshake](https://support.microsoft.com/en-us/help/257591/description-of-the-secure-sockets-layer-ssl-handshake)
掘金： [https://juejin.im/post/5aeee624f265da0b8e7f4cdb#heading-2](https://juejin.im/post/5aeee624f265da0b8e7f4cdb#heading-2)
