一种新的轻量级安全代理协议
A new lightweight secure proxy protocol
吕英豪 (Lü Yinghao), 陈嘉耕 (Chen Jiageng)
https://jcs.iie.ac.cn/xxaqxben/ch/reader/view_abstract.aspx?file_no=20210307
Online English HTML
English PDF
Original Chinese PDF
This paper presents a circumvention system called FTLSocks (“Fake TLS Socks”). It is a TLS-based tunnel, similar to HTTPT, trojan, or Cloak. The client and server have a preshared symmetric key. The client tags its TLS 1.3 Client Hello record by embedding an HMAC in the random field. The server looks for tagged Client Hellos and diverts their streams to a covert backend destination, and the server subsequently acknowledges the action by embedding another HMAC in its first downstream Application Data payload. A session key is negotiated using the TLS-native key_share extension. The client then tunnels covert data in the encrypted portion of subsequent Application Data records. As a special optimization, when a tunneled stream is itself TLS, the stream’s Application Data records are relayed verbatim, without an additional layer of encryption. Whenever a Client Hello is not tagged, the server forwards the TLS stream to some other fixed remote destination (a “disguise service”), using the built-in reverse proxy feature of Nginx. This default remote destination is what an unauthenticated user will see when they connect to the FTLSocks server.
The authors factor the “FTLS” protocol (of which FTLSocks is a particular implementation) into three modules:
- FTLSS (Section 3.3)
- A simplified, minimal SOCKS implementation, the interface between FTLSocks and network applications.
- FTLSH (Section 3.4)
- The handshake and key exchange protocol that is embedded in the TLS handshake.
- FTLST (Section 3.5)
- The transport protocol, forwarding covert data encrypted by the negotiated session keys.
The FTLSH handshake protocol employs some TLS fingerprinting resistance, taking a Firefox 71 Client Hello as a “template” into which a covert tag authenticator is embedded. How the authenticator tag works is, the client sets the random field to a random value that serves as a challenge. It sets the legacy_session_id field to an HMAC (using the preshared key) over a timestamp, the challenge, the server_name extension, and the key_exchange field. The ordinary key_exchange field is used for an X25519 key exchange with the server. The server tags its downstream as well: the first Application Data payload should be the HMAC of the challenge, server_name, and key_exchange.