HTTP(s)实验

HTTP & HTTPs 介绍

HTTP

HTTP（HyperText Transfer Protocol：超文本传输协议）是一种用于分布式、协作式和超媒体信息系统的应用层协议。 简单来说就是一种发布和接收 HTML 页面的方法，被用于在 Web 浏览器和网站服务器之间传递信息。

HTTP 默认工作在 TCP 协议 80 端口，用户访问网站 http:// 打头的都是标准 HTTP 服务。

HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。

HTTPs

HTTPs（Hypertext Transfer Protocol Secure：超文本传输安全协议）是一种透过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

HTTPs 默认工作在TCP协议的443端口，用户访问网站 https:// 打头的都是标准 HTTP 服务。

HTTPS网站建立的工作流程，除了TCP的三次握手外，还有如下步骤：

  1. 客户端验证服务器数字证书

  2. DH 算法协商对称加密算法的密钥、hash 算法的密钥

  3. SSL 安全加密隧道协商完成

  4. 网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。

实验

实验方式：用电脑开放热点，使用手机连接，通过手机上网访问HTTP和HTTPS的网站，用WireShark 截获传输的数据包。

HTTP

现在大部分的网站都使用了HTTPs，所以我将以自己搭建的课程中心任务管理网站(http://www.ddlkiller.top:8000为例) 为例：

TCP三次握手

  1. 第一次握手：可以看到里面规约了MSS等信息，首部多了option选项，长度达到了32字节。

  1. 第二次握手，服务端向客户端发送确认ACK

  1. 第三次握手：客户端向服务端发送ACK

HTTP数据传输

三次握手确定连接之后，开始HTTP的传输，由于是非加密的传输，所以我们可以很清楚地看到传输的请求(GET)和应答(200/OK) ：

从客户端发出请求的动作(API)和cookies都被暴露在外面：

可以看到里面服务器响应返回的字段都是明文存储，具有信息泄露的风险：

HTTPs

这里我们以登陆北航计算机学院面向对象课程网站(https://www.course.buaaoo.top为例)为例：

TCP三次握手

  1. 第一次握手：可以看到里面带有MSS等信息，首部多了一些option选项，长度达到了40字节。

  1. 第二次握手：由服务器向客户端回传了ACK，对第一次握手进行了应答

  1. 第三次握手：表示双方都能正常发送和接收报文，可以开始传输数据。

HTTPs数据传输

HTTPS的TCP的三次握手与HTTP的完全一致，只是服务器的端口号有所不同，HTTP是访问的80端口，HTTPS是访问的443端口。在建立连接之后开始HTTPS与HTTP不同的地方：

可以看到在建立连接后，传输数据前，有一段协议为TLSv1.2的报文传输：

通过查询资料我们可以知道：

传输层安全性协议（英语：Transport Layer Security，缩写作TLS），及其前身安全套接层（Secure Sockets Layer，缩写作SSL）是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。网景公司（Netscape）在1994年推出首版网页浏览器，网景导航者时，推出HTTPS协议，以SSL进行加密，这是SSL的起源。IETF将SSL进行标准化，1999年公布第一版TLS标准文件。随后又公布RFC 5246 （2008年8月）与RFC 6176（2011年3月）。在浏览器、邮箱、即时通信、VoIP、网络传真等应用程序中，广泛支持这个协议。主要的网站，如Google、Facebook等也以这个协议来创建安全连线，发送数据。目前已成为互联网上保密通信的工业标准。 SSL包含记录层（Record Layer）和传输层，记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证，之后利用非对称加密演算来对通信方做身份认证，之后交换对称密钥作为会谈密钥（Session key）。这个会谈密钥是用来将通信两方交换的数据做加密，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。

TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）就是HTTPS的加密核心。

筛选TLSv1.2协议可以绘制出一个加密建立的过程：

步骤如下（客户端简写为Client，服务端简写为Server）：

  1. Client向Server发出Client Hello报文

  2. Server向Client回复Server Hello报文

  3. Server向Client发送Certificate报文进行校验

  4. Server向Client发送同时携带由Certificate Status，Server Key Exchange，Server Hello Done 的报文

  5. Client向Server回复Client Key Exchaneg, Change Cipher Spec, Encrypted Handshake Message 报文

  6. Server向Client应答Change Cipher Spec, Encrypted Handshake Message 信息

加密建立到此结束，下面传输经过加密的Application Data报文

利用图可表示如下（图源网络）：

图注：安全要求比较高的服务器可能需要客户端也提供Certificate，所以会在自己提供Certificate之后发出CertificateRequest报文，这种情况下，客户端也会和服务端一样对Certificate进行回应，发送Certificate和CertificateVerifty报文。在我们的测试中并没有服务端并没有发出证书的请求。

从截获的报文也可以看出，后面的所有数据传输都是使用了TLSv1.2协议，都是以Application Data的形式呈现，都是加密过后的报文，不能通过WireShark看到具体的信息：

具体的，我们筛选其中的Client Hello报文，可以看到里面关键的字段 Session ID，Cipher Suites，Compression Method等加密参数：

而Server Client报文则是回应确定了使用的Ciper Suites信息：

拆解字段我们可以看到：

  • 密钥协商交换使用的是 ECDHE_RSA —— 基于椭圆曲线签密方案（EC, Elliptic Curve）的 Diffie-Hellman（DH）密钥协商协议，最后的E是Ephemeral 首字母，表示协商的是临时会话密钥。

  • 传输对话加密使用的是GCM 模式的 AES-128 算法，AES_128是使用128位的对称加密算法，GCM全称Galois计数器模式，结合消息验证码MAC实现保障信息传输的完整性。

  • SHA256：安全散列算法，是一种消息认证码算法，基于有密钥的加密散列函数，用于创建消息摘要/指纹，摘要可以保证传输的数据的完整性。

TLS的握手次数之多，是否每一次都是必要的呢，我们逐个分析报文的作用:

  1. Client->Server Client Hello ：提供客户端支持的加密算法和Client Random number等信息

  1. Server->Client Server Hello ：确认一种加密方案和提供Server Random number 信息

  1. Server->Client Certificate ：提供自己的数字证书给Client校验

  1. Server->Client Server Key Exchange ：服务端生成一对公钥和私钥

  1. Server->Client Server Hello Done ：表示Server的确认信息结束

  1. Client->Server Client Key Exchange ：客户端通过CA确认服务端的证书的合法性、正确性与完整性，并通过证书中的公钥对Server Key Exchange中的签名进行RSA解密校验，校验通过则取出Server Key Exchange中的PubKey，通过算法计算得到一个Pre-Master Secret。将Pre-Master Secret和前面的Hello报文中传输的两个Random number一同计算得出后续的会话中的会话密钥session-key。然后通过证书的公钥加密Pre-Master Secret传送给服务器。

  1. Client->Server Change Cipher Spec ：客户端确认加密方式，表示接收加密的方式

  2. Client->Server Encrypted Handshake Messgae ：该Message中携带一段已经加密的数据(Finished Message)，传送给服务端进行正式传输前的密钥验证。

  3. Server->Client Change Cipher Spec ：表示服务器端也支持约定的加密算法。

  4. Server->Client Encrypted Handshake Message ：在收到Client发送的 Client Key Exchange 后，服务端根据两个Hello报文的Random Number 和通过证书的私钥解密出来的 Pre-Master Secret 按照约定算法生成会话密钥session-key，然后将Client 发送的 Encrypted Handshake Messgae 进行解密，如果能正确得到 Finished Message说明从C->S的加密传输是可靠的；但是此时还不能确定S->C的加密传输，所以还需要发一个Encrypted Handshake Message来确认S->C的加密传输。

以上就是关于报文的作用的梳理，从中引发了两个疑问：

  1. 9 中 Server->Client 的 Change Cipher Spec 是否有必要？因为在 2 的 Server Hello 中就已经确定了使用的加密算法，这个算法是 1 的 Client Hello 提供的，为什么还需要再传输加密数据前再发送一次？

通过查询RFC8446文档，我们可以知道，TLS握手的示意图中使用中括号括起来的报文是可选发送报文，并没有强制要求发送

  1. 10 中的 Encrypted Handshake Message 是否有必要？如果有必要，是否还需要一个Client->Server 的确认报文来确认 Server->Client 的加密传输是正确的？如果没有必要是否能够删除？

猜想：Server 收到 Client 的Encrypted Handshake Message之后，只有拿到Pre-Master Secret 生成了双方会话的 session key 并且通过 session key 取得了 Finished Message 才发出自身的 Encrypted Handshake Message，这时候其实能够解密已经能说明两者可以会话了，在发出一个没有应答的Encrypted Handshake Message其实是多余的。

查询RFC8446结论：为了确认Server->Client端的加密传输正常，Server发出的Encrypted Handshake Message并不是多余的，实际上Client端是有应答的，应答体现在：

  • 如果传输过来的Encrypted Handshake Message正常，则Client端可以开始发送ApplicationData报文。

  • 如果传输过来的Encrypted Handshake Message异常，则Client端发送“decrypt_error”警告并终止连接。

除了上面所提到的在TLS的加密建立初期传输的报文之外，其实在传输的过程中还有一种特殊TLS报文——Encrypted Alert，常用于服务端通知客户端SSL传输已经完成，是SSL传输的结束信号，后面通常跟着断开连接和四次挥手。

总结

通过对HTTP和HTTPs的报文的抓取，我们可以清晰地看到不同协议下信息的传输：在HTTP协议下，客户端的请求和服务端的数据应答都是都是以明文的形式传输，中间人可以在同一网络下通过报文的抓取获取到用户的数据，可能导致用户隐私的泄漏，并且中间人还可以通过伪造服务端对客户端进行应答进行欺骗，破坏了数据的完整性和正确性；然而HTTPs通过TLS的握手进行了数据加密连接的建立，通过双方维护的会话密钥进行传输数据的加密传输，第三方在不能破解会话密钥的情况下对截获的报文无法进行解密，保障了数据的安全性和完整性，这也是为什么苹果公司在2017年1月1日开始要求所有AppStore上架的App都强制使用HTTPs协议。

虽然HTTPs相对于HTTP而言有安全方面的优势，但是HTTPs协议的加密范围也是有限的，在黑客攻击、DDOS攻击、服务器劫持等方面几乎无法起到作用；此外，SSL证书的信用链体系并不安全，没有一个全球化的CA机构，在某些国家可以控制CA根证书的情况下，知晓CA证书的公密钥情况下，中间人攻击也是可行的。还有处于成本的考虑，SSL证书需要购买申请，而且需要绑定IP，HTTPs的连接缓存也不如HTTP高效，流量使用的成本高，在服务器端占用资源也更高。在TLS的建立阶段比较费事，需要多个报文来回传输，对网站的响应速度也存在一定的影响。如12306等网站的解决方式是：在主页使用HTTP协议，在关于用户的信息等设计隐私的方面使用HTTPs协议。

参考资料

  1. HTTP和HTTPS区别

  2. 我是这样理解HTTP和HTTPS区别的

  3. TLS握手协商流程解析

  4. Wireshark 抓包理解 HTTPS 请求流程

  5. RFC8446

Previous应用层Next[Practice]

Last updated