作为一个iOS开发者，只是知道Apple要求支持HTTPS，当别人问起HTTPS具体是怎么一个流程的时候，却只能告诉人家HTTPS是在HTTP的基础上进行了SSL或者TLS的加密来保证安全性，具体流程却不甚了解，这是不够的，作为开发者，我需要更加professional的描述。被人问住的窘境促使我查了一些资料来了解这到底是个什么东西，以后再也不要丢这个人了！！！

1.HTTPS是什么

百度百科对于HTTPS的解释如下：
HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 ^[1] 。HTTPS 在HTTP 的基础下加入SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。 HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层（在 HTTP与 TCP 之间）。这个系统提供了身份验证与加密通讯方法。它被广泛用于万维网上安全敏感的通讯，例如交易支付等方面 ^[2]
简而言之，HTTPS就是在HTTP协议的基础上对传输的内容进行了加密来保证数据的安全性。

1.1 什么是HTTP？

HTTP是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准(TCP)，用于从WWW服务器传输超文本到本地浏览器的传输协议。HTTP是采用明文形式进行数据传输，极易被不法份子窃取和篡改。

1.2 HTTP和HTTPS的区别有哪些

1、HTTPS是加密传输协议，HTTP是明文传输协议;

2、HTTPS需要用到SSL证书，而HTTP不用;

3、HTTPS比HTTP更加安全，对搜索引擎更友好，利于SEO；

4、 HTTPS标准端口443，HTTP标准端口80;

5、 HTTPS基于传输层，HTTP基于应用层;

6、 HTTPS在浏览器显示绿色安全锁，HTTP没有显示;

2.HTTPS是怎么通信的

要了解HTTPS是怎么通信的，就要先了解一下它的基础，HTTP是怎么通信的。

2.1 HTTP的通信过程

建立连接的三次握手就不说了，HTTP和HTTPS都有。

image.png

可以看到，这个流程当中就是一问一答的形式，客户端没有校验服务端返回数据的合法性，服务端也没有对客户端发来的数据作校验，发送的数据也没有加密，都是明文，很容易被抓包。

2.1 HTTPS作了哪些改变？

HTTP + 加密 + 认证 + 完整性保护 = HTTPS
加密又分为对称加密和非对称加密：
1.对称加密 ： 加密和解密数据使用同一个密钥。这种加密方式的特点是速度很快，常见对称加密的算法有 AES；
2.非对称加密： 加密和解密使用不同的密钥，这两个密钥形成有且仅有唯一的配对，叫公钥和私钥。数据用公钥加密后必须用私钥解密，数据用私钥加密后必须用公钥解密。一般来说私钥自己保留好，把公钥公开给别人（一般公钥不会单独出现，而是会写进证书中），让别人拿自己的公钥加密数据后发给自己，这样只有自己才能解密。 这种加密方式的特点是速度慢，CPU 开销大，常见非对称加密算法有 RSA。
CA证书的相关知识： CA证书是由CA（Certification Authority）机构发布的数字证书。其内容包含：电子签证机关的信息、公钥用户信息、公钥、签名和有效期。这里的公钥服务端的公钥，这里的签名是指：用hash散列函数计算公开的明文信息的信息摘要，然后采用CA的私钥对信息摘要进行加密，加密完的密文就是签名。 即：证书 = 公钥 + 签名 +申请者和颁发者的信息。 客户端中因为在操作系统中就预置了CA的公钥，所以支持解密签名（因为签名使用CA的私钥加密的）。

2.1.1 HTTPS单向认证

image.png
服务端是有一对非对的秘钥 B_公钥和B_私钥
单向认证详细过程如下：
（1）客户端发起HTTPS请求，将客户端使用的SSL协议版本发送给服务端。
（2）服务端会有一份从CA签发机构申请来的证书，证书里面有服务端的公钥B和证书签名，服务端在收到客户端请求后，把这个证书返回给客户端。
（3）客户端读取服务端返回的CA证书当中的明文信息，用相同的hash散列函数去计算得到证书摘要A，然后用操作系统或浏览器内置的CA公钥去解密证书的签名（因为服务端返回的证书签名是用CA私钥加密的），得到证书摘要B，对比A和B，如果一致，就是信任的证书，如果不一致，就表明证书已经被篡改，应当立即终止通信。
此外，还会校验
-证书是否过期
-发行服务器证书的CA是否可靠
-服务器证书上的域名是否和服务器的实际域名相匹配
（4）客户端发送支持的对称加密方式到服务端，供服务端选择。
（5）服务端从中选取加密级别最高的方式，以明文形式返回给客户端。
（6）客户端从服务端返回的可信证书中，从中取出B公钥，然后通过自己的运算产生一个随机密钥F，然后把密钥F拿B_公钥加密，发送给服务器。
（7）服务端拿到加密之后的密钥F，用自己的私钥_B去解密，拿到真正的密钥F。
（8）这时候客户端和服务端就都有了用于通信的密钥F，双方可以用密钥F将通信内容对称加密后进行传输。

这里可以看到，HTTPS是通过非对称加密的方式把密钥传递给了双方，然后用对称加密的方式进行数据通信。之所以没有全程采用非对称加密，是因为非对称加密运算量比较大，会造成效率问题。

2.1.2 HTTPS双向认证

单向认证只是对服务端的身份进行了认证，服务端并没有对客户端身份进行认证，双向认证就弥补了这一点，顾名思义，双向认证就是不仅客户端要对服务端的身份进行验证，服务端也需要对客户端的身份进行验证。

image.png

双向认证流程如下：
（1）客户端向服务端发送请求，包含支持的SSL版本等信息。
（2）服务端给客户端返回一个CA证书（里面有服务端的B_公钥），SLL版本号等信息。
（3）客户端读取服务端返回的CA证书的明文信息，用相同的hash散列函数去计算得到证书摘要A，然后用操作系统或浏览器内置的CA公钥去解密证书的签名（因为服务端返回的证书签名是用CA私钥加密的），得到证书摘要B，对比A和B，如果相同，就是信任的证书可继续通信，如果不相同，证明证书内容经过篡改，立即终止通信。
此外，还会校验
-证书是否过期
-发行服务器证书的CA是否可靠
-服务器证书上的域名是否和服务器的实际域名相匹配
（4）客户端拿到服务端返回的证书如第三步验证通过之后，把自己的证书（含有客户端证书公钥 C_公钥）发送给服务端。
（5）服务端拿到客户端发来的证书之后，进行类似于第三步的校验，如果校验通过，就会要求客户端发送支持的对称加密方式过来。
（6）客户端将支持的对称加密方式发送给服务端，供服务端选择。
（7）服务端收到客户端支持的加密方式之后，选择加密级别最高的加密方式，用客户端公钥--C_公钥加密，发送到客户端。
（8）客户端收到服务端返回的加密方案密文后，使用自己的私钥_C进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥_B进行加密后，发送给服务端。
（9）服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。

3.HTTPS安全吗？

防君子不防小人。

以上手段只能防止一般级别的抓包，但是如果别人想搞你，还是有办法的。
常用的HTTPS抓包方式是作为中间人，对客户端伪装成服务端，对服务端伪装成客户端。简单来说：

• 截获客户端的HTTPS请求，伪装成中间人客户端去向服务端发送HTTPS请求
• 接受服务端返回，用自己的证书伪装成中间人服务端向客户端发送数据内容。
  常用的抓包工具有： Charles，fildder等。

中间人攻击(man-in-the-middle attack, abbreviated to MITM)

具体过程如下图：

image.png

以Charles为例，在客户端设置了代理之后，所有经由客户端端发出的请求都会经过Charles，再由Charles发往服务端，此时在服务端看来，Charles就是客户端。
对应的，所有经由服务端返回给客户端的请求也都会被Charles拦截，再有Charles发送给客户端，此时在客户端看来Charles就是服务端。
因此在服务端返回给客户端CA证书的时候，这个请求就会被Charles拦截，将证书替换为Charles的证书，而客户端也预装了Charles的根证书，这就相当于是用Charles的根证书去验证Charles证书的合法性。。。。WTF！！！！肯定是合法的啊。
整个通信过程从这一步开始，完全开始透明。

有没有办法防止这一切的发生呢，当然有！！！

为了防止中间人攻击，可以使用SSL-Pinning的技术来反抓包。 可以发现中间人攻击的要点的伪造了一个假的服务端证书给了客户端，客户端误以为真。解决思路就是，客户端也预置一份服务端的证书，比较一下就知道真假了。

3.1 解决办法

3.1.1 锁定证书

需要在客户端代码内置仅接受指定域名的证书，而不接受操作系统或浏览器内置的CA根证书对应的任何证书，通过这种授权方式，保障了APP与服务端通信的唯一性和安全性，因此客户端与服务端（例如API网关）之间的通信是可以保证绝对安全。但是CA签发证书都存在有效期问题，缺点是在 ** 证书续期后需要将证书重新内置到APP中**。

3.1.2 锁定公钥

提取证书中的公钥并内置到客户端中，通过与服务器对比公钥值来验证连接的正确性。制作证书密钥时，公钥在证书的续期前后都可以保持不变（即密钥对不变），所以可以避免证书有效期问题，一般推荐这种做法。

这样就万无一失了吗？NO

内置证书或者公钥的时候，常常会有对比验证的函数，直接控制这个函数的返回结果让验证通过不就好了吗。 于是就有了一个突破SLL-Pinning的经典操作：采用Xposed+justTrustme模块。 这个方案使用的是JustTrustMe这个Xposed模块，它所做的事情就是将各种已知的的HTTP请求库中用于校验证书的API都进行Hook，使无论是否是可信证书的情况，校验结果返回都为正常状态，从而实现绕过证书检查的效果。
对于APP来讲，需要逆向之类的东西。
仅作笔记。