Tls on Lutong's Homepage

AI自主科研案例————LLM API 代理检测：当网络管理员开始抓"API 二房东"

Sat, 09 May 2026 00:00:00 +0000

从 30 亿 tokens 说起

llm.ustc.edu.cn 这个平台——它为全校师生免费提供 DeepSeek、Qwen、GLM 等主流大模型 API 服务，光一天就跑掉 30 亿 tokens。

30 亿。一天。

这是个甜蜜又痛苦的数字。甜的是大家真的有在用 AI 做事。痛苦的是——算力有限，这些 API 本来只打算给校内师生用的。

但现实总是很骨感。总会有人把 API Key 丢给校外的朋友，或者搭个 nginx 转发一下，变成"公共代理服务"。你也许甚至能在闲鱼上搜到有人在卖"中科大 API 代理"。

所以问题就变成了：我怎么知道一个 API 请求是校内师生自己用的，还是被二次转发的？

这就像当上了"API 房东"，却发现有租客在当"二房东"。我们要做的就是——抓二房东。

检测思路

理想很丰满，现实很丰满——我们从三个层面来干这事：

层面	检测对象	一句话原理
🔒 TLS 层	JA4 指纹	每个 TLS 库握手方式不一样，像指纹一样独特
📨 HTTP 层	请求头特征	User-Agent 和各类头是客户端的身份证
💬 Prompt 层	文本前缀聚类	不同用户写 prompt 的风格不一样
🌐 网络层	IP 属地	校内 IP 还是境外 IP，一目了然

做了个 11 页的完整报告，这里挑干货说。

Wicklight protocol design

Fri, 03 Feb 2023 11:39:33 +0800

Wicklight protocol design

Abstract

This document specifies Wicklight protocol. Wicklight is a common HTTP(s) proxy with probe-resistant.

Copyright Notice

1. Introduction

Wicklight should also be Probe-Resistance and Traffic-Analysis-Resistance. It also supports UDP proxy with an additional client.

1.1. Conventions and Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Wicktls protocol design

Tue, 10 Jan 2023 15:19:59 +0800

Wicktls protocol design

Abstract

This document specifies Wicktls protocol. Wicktls allows building a tunnel based on an SSL/TLS connection with strong traffic reshaping.

Copyright Notice

1. Introduction

The primary goal of Wicktls is to build a security tunnel based on an SSL/TLS connection. It should also be Probe-Resistance and Traffic-Analysis-Resistance.

1.1. Conventions and Terminology

论文笔记| NDSS 2020 的几篇论文通读

Mon, 16 Mar 2020 15:44:37 +0800

SYMTCP: Eluding Stateful Deep Packet Inspection with Automated Discrepancy Discovery

作者： Zhongjie Wang
NDSS 2020

TCP等有状态的网络协议的实现需要使用状态机模型。但是由于文档使用自然语言描述，导致不同的网络协议实现的状态机之间会有差别。深度包检测也需要使用类似的状态机。通过利用状态机之间的差异，可以实现数据包非预期的被过滤或者放行。

文章形式化的构建了上述的操作，并符号执行的方法来自动发掘一个linux网络协议栈和特定DPI之间的状态机差异。最终实现了对于 Zeek, Snort 或者GFW的绕过。

Let’s Revoke: Scalable Global Certificate Revocation

Trevor Smith et al.
NDSS 2020

提供了一种高效、隐私、可扩展的证书撤销和查询机制。使用一个 CRV 数组来表示特定CA特定截止日期下的所有证书撤销信息。每一个证书有一个RID（CA、过期时间、统一过期时间下的递增撤销号RN）例如：RID = Let’s Encrypt : March 1, 2018 : 24561 。当撤销的时候，CRV的对应 RN的位置1。更新CRV时候，可以使用AND和OR进行增量更新、或者使用NEW操作来全量更新CRV列表。

好处是：

过期之后的CRV可以直接丢弃
时间窗口较小（1day）
网络流量较少、本地存储较小、具有较小的计算消耗
具有隐私性、不保留特定证书信息
具有可审计性等

Post-Quantum Authentication in TLS 1.3: A Performance Study

Post-Quantum Authentication in TLS 1.3: A Performance Study
作者 Dimitrios Sikeridis
NDSS 2020

文章主要将目前NIST文档中的一些候选的PQ算法结合到 TLSv1.3 中，并分析其安全性、性能等。

论文笔记| CA 体系中的 Certificate Transparency

Fri, 06 Dec 2019 19:47:04 +0800

什么是 CT ？

在原始的 KPI/CA 体系中，并没有 CT 这样一个角色的存在。而引入这样一个角色，是为了解决 CA 体系在结构上的弊端。

这篇博文讲述了 CT 的基本体系结构，而后简要介绍 CSS 2019 的论文 Certificate Transparency in the Wild: Exploring the Reliability of Monitors。

现有 CA 体系的弊端

当前的 CA 体系，提供了一个用于确认公钥与实体对应关系的手段，是现代非对称密码学的基石之一。但是这个体系的核心信任模型就是要相信“可信第三份”，也就是 CA 。换句话说，整个 TLS 体系要求整个互联网信任几百个 CA 实体可靠诚实的工作，这个条件看起来似乎是有一点好笑的。

当发生了一些安全事件，暴露出 CA 往往不能改按照我们预想的情况可靠的工作的时候，这个问题就变得非常明显了。但是 CA 机制是非常封闭的，原始 PKI/CA 体系不能提供任何对于 CA 的审计手段。唯一的监督措施就是这样一条基本原理 ———— 当 CA 犯错的时候，由根 CA 撤销其证书。这个惩罚其实是非常弱的，而且有一种事后诸葛的感觉。

如果一个 CA 由于主观或者客观的因素，签发了一张非法证书。那么攻击者可以使用这样的一张证书来假冒受害网站，或者发起中间人攻击，从而破坏了 TLS 体系身份认证的安全性。

所以 CT （Certificate Transparency）的机制就是用于给 CA 体系补充这个审计的过程。

CT 体系的工作原理

CT 体系的工作原理是：当 CA 需要颁发一个证书的时候，需要将证书发送给 CT；由CT签名后，生成一个 SCT （签名证书时间戳）；CA 得到 SCT 后将证书颁发。与此同时，CT 将证书信息记录在一个公开日志 log 上，以备用户和使用者查询。

技术摘要| 安全的SSL/TLS配置推荐及其原理

Thu, 28 Nov 2019 00:00:00 +0000

一、SSL/TLS 背景

如今已经是 2019 年了，大部分的 HTTP 服务器都默认配置了 SSL/TLS ，以为大家提供安全的、具有隐私性的网络服务。

但是安全的配置 TLS 往往是困难的，如果配置不当可能会导致性能低下、安全性能减弱等问题。因此这篇文章以 Nginx 服务器为例，讲解如何安全的配置 ssl 服务器。

早期的 SSL（安全套接字协议）是由网景公司发布的提供安全连接的服务，发布了 SSL1.0, SSL2.0, SSL 3.0 三个版本。后来 IETF 将其标准化，并作为 TLS 协议（传输层安全协议）发布了 TLSv1.1 和 TLSv1.2 协议。 2018年，最新的 TLSv1.3 协议发布。目前主要使用的版本是 TLSv1.2 和 TLSv1.3 两个版本，早期的版本已经不再建议使用了。

TLS 协议主要使用了如下一些密码学算法来提供安全服务：

身份认证：服务器需要证明自己就是真实的服务器，防止了恶意服务器假冒真实网站提供服务。
秘钥交换：服务器和浏览器需要协商出一个秘钥，用于后续消息的加密和验证。
数据机密性保护：使用了上述协商出来的秘钥，来对信息进行加密，使得他人不能读取消息的内容。
消息完整性保护：要保护消息没有被恶意篡改（即便是加密的信息，也可能进行篡改）

二、密码学算法简介

为了完成上面这些密码学服务，需要使用一些密码学算法，来提供这些服务。将这些密码学算法组合起来，形成一个个套餐，也就形成了密码学套件（ciphers）。

TLS 协议最初是的阶段，就是通信双方对于所使用的的密码学套件进行协商，确定算法和相关参数，之后才能提供安全性服务。

2.1 身份认证

为了验证身份，TLS 使用了一种被称为“数字签名”的算法。数字签名是一种基于非对称密码的算法，可以使得一个实体（一般来说是服务器）证明他就是所声称的人。

这里就需要大家常说的证书的概念，简单来说，证书提供了关系的证明，https 服务器需要向可信第三方（CA）申请一个 ssl 证书。客户端拿到服务器的证书之后，去CA处查询，就能够觉得服务器的身份。

数字签名根据所使用的非对称算法的不同，主要有有 RSA 和 ECDSA 两种证书。

RSA(DSA) 是最简单的一种非对称算法，可以用于签名，但是其秘钥比较长（通常有 2048 位或者 4096 位），计算的开销比较大。因此近些年搭建广泛使用 ECDSA 来取代 RSA 算法。

论文阅读| Safely Exporting Keys from Secure Channels: On the Security of EAP-TLS and TLS Key Exporters

Sun, 22 Sep 2019 15:23:49 +0800

Safely Exporting Keys from Secure Channels: On the Security of EAP-TLS and TLS Key Exporters

Christina Brzuska, Håkon Jacobsen, and Douglas Stebila

Define: ACCE

ACCE protocal: authenticated and confidential channel establishment (ACCE)

Examples: TLS,SSH,QUIC(TLS-like)

理论上已经证明了这些协议所派生出来的主秘钥是 indistinguishability 的。

Define: TLS-like

TLS-like protocal:

双方产生随机数
协商出一个 master key
Session key 由 master key 派生

Define: AKE

AKE: authenticated key exchange

指在认证的信道上进行秘钥交换和派生的协议。

主要工作

主要是两方面工作：

理论证明了在最广泛情形下 ACCE 安全的信道上，使用 master key 派生进行秘钥交换是 indistinguishability 的且可以独立于master key。以往的工作是在给定的（如TLS1.2基础之上的安全证明）
给出了在通用 TLS-like 的协议上的最一般 AKE 协议的形式。
具体应用与 EAP-TLS 协议

论文笔记：The use of TLS in Censorship Circumvention

Wed, 18 Sep 2019 15:56:49 +0800

The use of TLS in Censorship Circumvention

Network and Distributed Systems Security (NDSS) Symposium 2019
Sergey Frolov, Eric Wustrow.
University of Colorado Boulder

Abstract

collect and analyze TLS Client Hello messages
analyze existing censorship circumvention projects that use
develop a library, uTLS, that allows developers to easily mimic arbitrary TLS handshakes of popular implementations

真实访问TLS的特征

Client Hello
Server Hello
Connection-specific information
BroserStack

获取了诸如 chrome 等ssl客户端的tls指纹。

Client Hello fingerpoints

99.96% of all connections use one of top 5000 Client Hello fingerprints, and one of top 1310 Server Hello fingerprints.

论文笔记| maTLS: How to Make TLS middlebox-aware?

Wed, 18 Sep 2019 15:55:49 +0800

maTLS: How to Make TLS middlebox-aware?

Hyunwoo Lee, Zach Smith, Junghwan Lim†, Gyeongjae Choi, Selin Chun, Taejoong Chung, Ted “Taekyoung” Kwon
Network and Distributed Systems Security (NDSS) Symposium 2019

Current Solution

MITM:

Client: fake root certificate
Server: CDNs request server private keys.

=> Increased risks in MITM attack
=> How to work honestly?
 1. encryption-based
 2. TEE-based
 3. TLS extension-based

SplitTLS:

authentication: client can not authenticate the intend server
Confidentiality: weak ciphersuite
Integrity：Not behaved Middlebox

maTLS:

论文阅读| Hybrid key exchange in TLS 1.3 or SSH

Tue, 17 Sep 2019 15:55:49 +0800

Hybrid key exchange in TLS 1.3 or SSH

Draft-stebila-tls-hybrid-design-01

Motivation of hybrid key exchange

tranditional algorithms: have risks in face of quantum computers and cryptanalytic advances
next-generation algorithms: have less confidence in security (due to less studies)

Prototyping post-quantum and hybrid key exchange and authentication in TLS and SSH

hybrid key exchange and hybrid signatures

1.Key Exchange is listed above. 2.Authentication：

extension signature_algorithms_cert and signatur_algorithms

both algorithms should sign the same message.

RFC 8446| Transport Layer Security 1.3

Wed, 11 Sep 2019 21:04:49 +0800

Transport Layer Security 1.3 (RFC 8446)

1. Major differences from TLS 1.2

All legacy algorithms have been deprecated. TLS 1.3 uses AEAD instead.
0-RTT (zero round-trip time) mode was added.
All public-key based key exchange mechanisms now provide forward secrecy.
Simplified the handshake state machine (removed ChangeCipherSpec in most common cases).
Cryptographic improvements.
- KDF: HMAC-based KDF
- RSA padding
- DSA removed
- Ephemeral Diffie-Hellman removed
Session resumption has beed replaced by a simple PSK exchange

AEAD: Authenticated Encryption with Associated Data