[Peer Review Request]Restls: 对TLS握手的完美伪装

[3andne]

@wwqgtxx @H1JK
Hi there,
I hope you are having a good day.
First off, many thanks to the Clash.Meta project. We couldn't build a prototype quickly without your efforts.
We're currently working on a brand new protocol named Restls which can be used as an extension to Shadowsocks. It shares a similar goal with ShadowTLS to circumvent GFW whitelisting but tries to fix ShadowTLS' fundamental flaw of not being able to provide server authentication.
If that sounds good, you might want to take a look at the draft:
Restls: A Perfect Impersonation of TLS Handshake
You can find a proof-of-concept implementation in the same repo.
----------------------
你们好，
希望你们一切顺利。
首先很感谢Clash.Meta的平台，不然我们无法快速实现这个想法。
我们正在设计一个新的协议，名为Restls，它可以作为Shadowsocks的插件使用。它的目标与ShadowTLS类似——绕过GFW的白名单机制，但它试图解决ShadowTLS在协议设计中未能实现的服务端认证，从而避免被准确封杀。
如果你觉得这听起来还行，你或许想看一看这个协议的设计稿：
Restls: 对TLS握手的完美伪装
这个仓库同样包含了一个实现以及其使用方式。

[H1JK]

Is it possible to use BLAKE3 as the hash algorithm instead of SHA1? Although HMAC-SHA1 is still considered safe, SHA1 itself is no longer safe and formally deprecated by NIST and not used by high-version TLS. This is also a point that I complaint about ShadowTLS.

x := hmac.New(sha1.New, []byte("hello"))
fmt.Println(hex.EncodeToString(x.Sum(nil)))
// result: f0779069bc6870453951e14d5a28be6031c2f9a0

x = hmac.New(func() hash.Hash {
	return blake3.New(20, nil)
}, []byte("hello"))
fmt.Println(hex.EncodeToString(x.Sum(nil)))
// result: 9de511243ba00b248f7c63c339f99a8e32f02f66

I'm using lukechampine.com/blake3 as BLAKE3 library. This library was optimized and has a good performance.

Compare to SHA256, BLAKE3 is faster and has a customizable size.

[RPRX]

既然你是发出来让大家评价一下，那我也来评价一下应该问题不大，我的评价：远不如 REALITY

[H1JK]

An important thing to do with TLS parroting/impersonating is to correctly handle TCP redirect attacks. Coia proposed a PoC for ShadowTLS, mentioning that TCP redirection attacks can accurately identify it.

Firewall sniffs out the SNI and redirect the TCP connection to the real server (like "override destination"), then the client is actually handshaking with the real server. For ShadowTLS v2, the real server does not recognize the payload (HMAC and inner protocol handshake etc) sent by client so it would forcibly close the connection (RST), which shows that it is ShadowTLS and can be easily identified by firewall.

It seems that Restls has designed a relatively complete authentication, but what will happen if the server authentication fails (such as facing a TCP redirect attack mentioned above)? Does the client close the connection when it finds out that it is not connecting to the proxy server? Then this is also a clear characteristic.

If not, what should be sent to the server? Just use HTTP to request its root directory and close the connection? Most of the countermeasures are not completely safe, if you use the exact same behavior across all connections, across all implementations, sooner or later this will be identified by censors, because they are using machine learning.

[3andne]

Is it possible to use BLAKE3 as the hash algorithm instead of SHA1? Although HMAC-SHA1 is still considered safe, SHA1 itself is no longer safe and formally deprecated by NIST and not used by high-version TLS. This is also a point that I complaint about ShadowTLS.

x := hmac.New(sha1.New, []byte("hello"))
fmt.Println(hex.EncodeToString(x.Sum(nil)))
// result: f0779069bc6870453951e14d5a28be6031c2f9a0

x = hmac.New(func() hash.Hash {
	return blake3.New(20, nil)
}, []byte("hello"))
fmt.Println(hex.EncodeToString(x.Sum(nil)))
// result: 9de511243ba00b248f7c63c339f99a8e32f02f66

I'm using lukechampine.com/blake3 as BLAKE3 library. This library was optimized and has a good performance.

Compare to SHA256, BLAKE3 is faster and has a customizable size.

That's a nice suggestion. We will try out other hash algorithms and blake3 looks great.
We acknowledge that SHA1 is vulnerable to collision attacks. Note that although SHA1 is no longer considered secure for collision attacks, it doesn't break the HMAC. https://crypto.stackexchange.com/questions/26510/why-is-hmac-sha1-still-considered-secure

[3andne]

An important thing to do with TLS parroting/impersonating is to correctly handle TCP redirect attacks. Coia proposed a PoC for ShadowTLS, mentioning that TCP redirection attacks can accurately identify it.

Firewall sniffs out the SNI and redirect the TCP connection to the real server (like "override destination"), then the client is actually handshaking with the real server. For ShadowTLS v2, the real server does not recognize the payload (HMAC and inner protocol handshake etc) sent by client so it would forcibly close the connection (RST), which shows that it is ShadowTLS and can be easily identified by firewall.

It seems that Restls has designed a relatively complete authentication, but what will happen if the server authentication fails (such as facing a TCP redirect attack mentioned above)? Does the client close the connection when it finds out that it is not connecting to the proxy server? Then this is also a clear characteristic.

If not, what should be sent to the server? Just use HTTP to request its root directory and close the connection? Most of the countermeasures are not completely safe, if you use the exact same behavior across all connections, across all implementations, sooner or later this will be identified by censors, because they are using machine learning.

Great question!
The complete client implementation should make this behavior customizable IMHO. Users provide a list of HTTP requests and we'll make them randomly. The connection shouldn't be closed deterministically. It should behave like a long connection and close later. The goal is to make it similar to regular proxy traffic.
We all know there's no silver bullet solution. If the GFW believes that your traffic to the proxy is suspicious, and redirects every connection away. Restls won't help you to reach your server. What Restls can do is to let us know when we're being attacked and act as if we're not affected. The GFW might need multiple redirections plus offline analysis to make its final decision. That's way more costly than a single redirection.
There are a lot of questions that remain unanswered in this draft, e.g., how to hide the proxy behavior, how to throw TLS alerts when the subsequent data stream is being modified. These probably require support from the Shadowsocks community. Once we get these done, we might get a TCP based solution that's more sneaky than what we currently have.