UPF的DPI功能：检测加密的HTTPs应用

背景说明：

互联网中超过90%以上的流量都是基于或者封装在http协议里的。

这里边运营商基于商业需求，可能需要和互联网的第三方进行合作，

开展能力开放、Qos保障等方面的合作。

这里边的重要一环就是作为用户面节点的UPF需要能检测出这类应用。

通常UPF（以及4G的PGW-U）采用DPI技术，也就是俗称深度包检测技术来检测基于http的应用。

但问题是http有两种，一种是明文的http，一种是基于TLS协议的https。

后者是加密的，包括http的header部分和payload的部分都是加密的。

那UPF怎么检测呢？

例如：

http://v.qq.com 这个UPF能检测；那

原理说明：

1 TLS握手过程

答案是可以的。

https://v.qq.com 这个UPF还能检测吗？

这里得先说明一下HTTPs依赖的底层技术TLS（Transport layer security：传输层加密）。

和TCP一样，TLS也是需要Client和Server先握手后，才能完成数据的加密。

握手过程一般包括以下步骤：

1. ClientHello：客户端向服务器发送一个起始握手消息，该消息包含支持的SSL/TLS版本号、加密套件

候选列表和一个随机数作为之后生成共享密钥的一部分。

2. ServerHello：服务器从客户端发送的消息中选择一个合适的SSL/TLS版本号和加密套件，并生成一个

随机数。服务器还返回自己的数字证书，该证书包含其公钥用于后续的加密通信。

3. Certificate和ServerKeyExchange（可选）：服务器发送包含数字证书的消息，以便客户端验证服务

器的身份。如果服务器要求客户端发送客户端证书进行互相验证，那么还会有一个ServerKeyExchange

消息，用于向客户端传递服务器的公钥参数。

4. ClientKeyExchange：客户端使用服务器发送的公钥加密一串随机数，并将其发送给服务器。这个随

机数将用于之后生成对称密钥。

5. CertificateVerify（可选）：如果服务器要求客户端进行身份验证，客户端将发送一个包含客户端证书

及其签名的消息。

6. ChangeCipherSpec：客户端和服务器都在这一阶段表示已经完成了握手阶段，并准备开始加密通

信。

7. Finished：客户端和服务器各自计算握手过程中交换的所有消息的哈希值，然后用对称密钥加密并发

送给对方进行比较。这个过程是为了验证握手过程的完整性和正确性。

大致的流程如下图：

这里的Client可以想象成是UE，而Server可以想象成是腾讯视频服务器。

不管是移动网络还是家庭宽带固网都适用，5G只是接入。

2 TLS的扩展参数SNI

需要注意的是，从上图也可以看出。

ClientHello和ServerHello作为握手消息，是不加密的。是明文的。

同时，在RFC6066中定义了针对TLS的extensions即扩展，

允许在Client Hello消息中加入SNI（Server Name Indication：服务名字指示）扩展参数，携带

server_name参数，这个就是需要访问的目标url。

RFC6066的部分原文如下：

这就给UPF做DPI检测https应用提供了机会。

这个是明文的，是可以抓到的。所以可以识别。

UPF侧的相关DPI配置

- 由于各厂家配置命令有差异，因此做个功能抽象。

- 总体来说就是一个条件表达式。例如：

if url = https://v.qq.com

then app-id = 100

意思就是如果通过DPI检测到的url是v.qq.com的，那就打上app-id等于100的标记进行分类。

最后看一个client_hello中携带server_name的log：

引用自CSFN：

https://blog.csdn.net/sosfnima/article/details/84075098