细说HTTP与HTTPS

前言

网上已经有很多关于HTTP与HTTPS的文章，为什么我还要写这篇文章呢，源于昨天有个iOS开发同学昨天在群里面提了一个问题，如果一个人下载了一个APP，该APP与服务器是HTTPS连接，他不会信任任何来源于不明身份的证书，然后连上了我的WIFI，我有没有办法去破解里面的通信内容?

接下来我们就带着这个疑问去寻找答案，并且给出我的答案。

什么是HTTP

HTTP(HyperText Transfer Protocol)超文本传输协议，HTTP是七层网络模型中作用在应用层的协议。

HTTP的缺点：

1. 窃听风险（eavesdropping）：第三方可以获知通信内容。
2. 篡改风险（tampering）：第三方可以修改通信内容。
3. 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

因为HTTP是明文传输内容的，所以只要攻击者通过劫持你的WIFI或者你连上了不安全的WIFI那么你所有的传输内容他都可以拿到，接下来就可以篡改里面的数据。基于以上的缺点就有了HTTPS，待会我们再来说这个事儿。

HTTP的工作流程：

相信大家都听说过TCP三次握手，HTTP就是通过TCP三次握手建立连接，值得一提的是HTTP/1.0版本是默认没有复用TCP连接的，每次发送数据都要建立一个连接(需要使用keep-alive来建立长连接)，这样导致了耗时以及占用资源非常严重，后来发布了HTTP/1.1，同一个TCP通道可以复用发送多个请求，但是在该通道里面所有的请求都是按照顺序来发送的发送的，容易导致阻塞。HTTP/2在1.1的基础上改进了，不止复用同一个TCP通道并且可以并发的处理多个请求。

TCP三次握手，依照惯例，先发一个图片，看图说话

image.png

下面来解释一下上面三次握手的作用：

第一次握手：客户端发送将SYN标志位设置为1，并且随机产生一个序列号值seq=J，发送给数据包给服务端后，自身状态变为SYN_SENT

第二次握手：服务端接收到数据包之后，将发送标志位SYN设置为1，ACK应答需要为J+1表，并且再发送一个随机序列号值seq=K然后发送到客户端

第三次握手：客户端检查ACK是否为J+1，如果是的话发送一个ACK包，ACK=k+!，服务端收到之后确定ack是否等于K+1，是的话连接建立

我们先来解释一下为什么需要三次握手：
第一次握手确认客户端是具有发送消息能力的，发送消息之后客户端出于SYN_SENT状态，第二次握手服务器确定了自己有接收消息的能力，但是还不知道有没有发送消息的能力，此时服务器出于SYN_RECV的状态，也就是半连接的状态，第三次握手确定了服务器有发送消息的能力，因为客户端收到了他的消息并且回应了。此时客户端和服务端都处于establish状态，连接已经建立，可以开始收发消息。

基于HTTP的确定，后面衍生出来了HTTPS，那接下来我们来讲讲HTTPS以及他们的区别

什么是HTTPS

HTTPS（Hyper Text Transfer Protocol over Secure Socket Layer）顾名思义就是在HTTP的基础上加了SSL/TLS，以此来保证数据传输的安全性。

HTTPS的优点

HTTPS 协议旨在解决以上三个风险，因此它可以：

1. 保证所有信息加密传输，无法被第三方窃取。
2. 为信息添加校验机制，如果被第三方恶意破坏，可以检测出来。
3. 配备身份证书，防止第三方伪装参与通信。

SSL/TLS

SSL(Secure Sockets Layer)/TLS(transport Layer Security)安全套接层是保证HTTPS安全的协议，这个协议主要的思想是通过公钥加解密来实现数据传输安全。

那么我们就面临着两个问题.
1.如何保证公钥不被篡改

我们通过权威机构申请证书，将自己的公钥包装到证书里面，只要证书是可信的，那么公钥就是可信的。

2.每次都生成公钥，消耗的时间太长，如何减少消耗。

使用对称加密来替换非对称加密，每一次对话，客户端和和服务端都生成一个对话秘钥，而这个对称秘钥使用服务端的公私钥来进行加解密，这样就减少了加密运算的消耗时间。

SSL/TLS 握手的流程：

1. 首先客户端发起请求，这个时候客户端会向服务端提供一些信息，包括支持的加密的算法，支持协议的版本TLS,一个随机数（用于待会生成对称秘钥），支持的压缩算法

2. 服务端收到请求之后，向客户端发出相应，该响应也包括一些信息，确认使用的加密算法，一个服务端生成的随机数（用于待会生成秘钥）,支持的协议的版本TLS，还有一个最重要的数字证书，该数字证书包含了服务器的域名，还有服务端的公钥，以及经过加密后的摘要，该摘要是通过一定的算法对域名以及公钥进行计算得来。然后使用CA的私钥对摘要进行加密，

3. 客户端收到数据之后首先会验证该数字证书是不是权威机构申请的证书，或者证书中的域名与实际域名是否一致，证书是否已经过期，如果都不符合的话那么就会提示是否信任该未知来源证书警告。
   这里会验证证书是否被篡改，因为本地系统会内置权威机构的公钥，所以可以使 用公钥对解密出证书里面的摘要，然后通过特定的算法对域名以及公钥进行计算得到一个本地摘要，再和服务端传过来的摘要进行对比是否一致，以此来判断证书是否被篡改。
   如果校验了证书是没有问题，客户端会生成一个随机数，并且使用服务器的公钥进行加密，并且发送编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

4. 服务端获取客户端的数据，然后使用自己的私钥机密客户端发过来的随机数。至此，一共有三个随机数。

5. 客户端和服务端通过之前协议好的加密算法，使用前面生成的三个随机数生成一个真正的对称秘钥，该对称秘钥用于加密传输数据。

简单点来说以上步骤就是：

1. 客户端发送请求
2. 服务端返回证书，该证书包含服务端的公钥
3. 客户端验证证书，并且生成对称秘钥，并且使用服务端的公钥加密该对称秘钥
4. 服务端用私钥解密客户端的对称秘钥
5. 发送内容通过对称秘钥来加密

总结一下 HTTPS 协议是如何避免前文所说的三大风险的：
先用非对称加密传输密码，然后用这个密码对称加密数据，使得第三方无法获得通信内容
发送方将数据的哈希结果写到数据中，接收方解密后对比数据的哈希结果，如果不一致则说明被修改。由于传输数据加密，第三方无法修改哈希结果。
由权威机构颁发证书，再加上证书校验机制，避免第三方伪装参与通信。

答案

在我们抛砖引玉说了这么多HTTP与HTTPS的区别之后，我们得到了答案。

如果一个人下载了一个APP，该APP与服务器是HTTPS连接，他不会信任任何来源于不明身份的证书，然后连上了我的WIFI，我有没有办法去破解里面的通信内容

答案就是不行

我们想到的可以破解里面的通信内容也许就是希望能做一个中间人拦截，在服务端向客户端发送证书的时候拦截该证书，并且伪造一个和服务端域名相同并且替换将里面的公钥替换成自己的公钥，并且用自己的私钥进行签名。客户端收到伪造的证书之后，如果客户端的系统中有我们的公钥，那么就可以验证通过该中间人的证书，然后获取得到公钥，然后用该公钥对对称秘钥加密发送给服务端，此时中间件又可以拦截，并且使用自己的私钥解密出对称秘钥，然后中间人通过服务端的公钥对该秘钥进行加密，然后发送给服务端，这样中间人就拿到了对称秘钥信息，所以也可以窃取到里面的通信内容。

但是..........

前面的题目说了一个前提，不会信任任何来源于不明身份的证书，也就是说在中间人拦截了服务端的证书并且将伪造的证书发送给客户端之后，客户端并不会通过验证该证书，然后连接就到此中断了。。。。

附加：HTTPS与HTTPS的区别

1. HTTP是明文传输，HTTPS是加密传输
2. HTTP只有TCP三次握手，HTTPS是TCP三次握手+SSL/TLS
3. HTTP是使用80端口，HTTPS是使用443端口
4. HTTPS比HTTPS更加耗时
5. HTTPS需要到CA购买证书，需要一定的费用

参考文章

1 SSL/TLS协议运行机制的概述

2. 图解SSL/TLS协议
3. 深入理解HTTPS