Wicklight protocol design
This document specifies Wicklight protocol. Wicklight is a common HTTP(s) proxy with probe-resistant.
Copyright (c) 2023 Elliot Chen. All rights reserved.
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.
2. Protocol Overview
The wicklight protocol is similar to the traditional HTTP CONNECT Proxy in HTTP/1.1 [RFC2626] and HTTP/2 [RFC7540].
The server MUST be compatible with traditional HTTP/1.1 or HTTP/2 proxy clients. With a specific wicklight client, additional features can be enabled, including 0-RTT and UDP transport.
2.1. TCP Tunnel
Wicklight transport TCP traffics similar to the traditional HTTP CONNECT Proxy. However, it enables 0-RTT, probe-resistant, and padding features.
0-RTT: Unlike traditional HTTP proxies, the client sends the data right after sending the first CONNECT request to the server. If the server refuses to proxy the traffic, it will close the connection directly.
Probe-resistant: To hide the fact of an HTTP proxy server, the
server will only send the
Proxy-Authenticate head in the response when
the host (URL) is in an allowlist. Otherwise, all traffic will be forwarded
to a normal backend server. Note that
Proxy-Authenticate indicates that
the server handles the proxy traffic and requires the client to send an
authentication token (usually a base64 [RFC4648] of
Padding: the request and response can use a
Proxy-Padding head to
send random padding. The padding is a random base64-encoded string. Its
length should be large than 16 and less than 512.
2.2. UDP Tunnel
Wicklight can also be used to proxy UDP traffics. The client must send a
Proxy-UDP: udp header in the CONNECT request. Also, the url must be
wickproxy.udp. When the server receives such a CONNECT request,
the whole connection is used to transport UDP traffics.
All UDP packets are transported over the original HTTP CONNECT connection bidirectionally. The UDP packets are first encoded into a UDP associated packet similar in Socks5 [RFC1928]:
| LEN(4) | RSV(2) | FRAG(1) | ATYP(1) | DST.ADDR(VAR) | DST.PORT(2) | DATA(VAR) |
LENis four big-encoding bytes that equal to the length of the following parts
ATYPis one byte:
- IP V4 address: ‘0x01’
- DOMAINNAME: ‘0x03’
- IP V6 address: ‘0x04’
DST.ADDRis the destination host, the same as the socks5 protocol
DST.PORTis the desired destination port
DATAis the actual data
3. HTTP Header Considerations
Wicklight introduces two additional HTTP Headers:
Proxy-UDPis used to infer a UDP associate proxy
Proxy-Paddingis used to add random paddings
Other related HTTP Headers include:
Proxy-Connection: Keep-Aliveto allow the server not to close the connection.
Proxy-Authorizationto encode the authentication information
Proxy-Authenticatenotifies the client to send a
4. Security Considerations
The wicklight protocol MUST be encapsulated by the TLS [RFC8446] protocol or wicktls protocol to guarantee security.
The wicklight protocol MUST use the HTTP basic authentication and MUST NOT use anonymous mode.