-
Notifications
You must be signed in to change notification settings - Fork 3.1k
feat: implement anytls client and server #1844
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Perhaps you could consider adding an inbound implementation for the protocol as well (which shouldn't be too difficult from your reference implementation) |
Sure. Tomorrow I will start implementing inbound. |
Server config: listeners:
- name: anytls-in
type: anytls
port: 10000
listen: 0.0.0.0
users:
username1: password1
username2: password2
certificate: ./server.crt
private-key: ./server.key
padding-scheme: "" |
Please add the configuration file example to docs/config.yaml. |
Please cherry-pick this, it fixes some bugs with sending padding. |
You can continue to send relevant PR |
老哥 padding-scheme: "" 该怎么填呢?我瞧着格式跟anytls文档有点不一样 |
Server
Client config
Why we need this protocol?
This is a concise and clear "Any in TLS" proxy protocol. This means you can ship anything on top of TLS without having to worry about firewalls identifying it due to some side-channel leak. It provides functions for modifying packet length characteristics, which are not available in previous protocols.
It is well known that simpler protocols, such as Trojan, are already fully recognized by the GFW due to the side-channel leak so-called "TLS in TLS problem". Even with multiplexing or hard-coded padding, it still produce very fixed packet length characteristics (when you carry TLS on it).
We also took the handshake RTT into consideration, so we implemented connection reuse, but it is not like sing-mux or other earlier mux, because it only carries one stream on a single connection at the same time, so there is no head-of-line blocking problem.
All in all, this is a protocol with clear semantics, forward-looking design, and excellent performance. We hope to add it to mihomo.