Enhancements regarding Trojan Protocol that might be done in the future

[GreaterFire]

According to some issues, here is a list of improvements to be made to the protocol only if necessary. You are welcomed to contribute to this list.

• Pad payloads (Looks like a simple proxy over TLS, but there are two notable problems #9, Can GFW detect TLS over TLS? #12)
• Eliminate TLS Handshake fingerprint (TLS fingerprinting vulns #11)
  • Manipulating TLS cipher list
  • Manipulating other extensions in Client Hello
• Use TLS session reuse to accelerate connection
• OCSP stapling

Since some strategies cannot be proven effective, further discussions are required.

Thank @klzgrad and @micooz for their great proposals.

[klzgrad]

I think in theory the TLS state machine in specific implementations will also have identifying information from its state transition.

I guess The Parrot is Dead still holds. I just found the above is not just theory.

Nginx doesn't implement TLS False Start. Chromium does. I tried to add SSL_CTX_set_mode(ssl->ctx, SSL_MODE_ENABLE_FALSE_START) in Nginx to enable it. Nginx will use False Start but lose the ability of session resumption (because it was caching the wrong session during False Start because it was not implemented with False Start in mind). Chromium is able to do both False Start and session resumption.

This is a dynamic feature in the TLS state machine. This should be fairly hard to detect and not having much discriminating power if detected and I could patch this issue in Nginx, but it shows that imitation is always imperfect and subject to detection.

This is a continuum. If we use the identical binary of Chrome it is a perfect "imitation" and impossible to distinguish but the installation size and performance suffer. On the other side the binary size and performance are great but imperfect imitation is easier to detect.

(There are other unique dynamic behaviors in Chromium: It sends separate TLS requests for OCSP; It starts non-content TLS sessions just to get the session tickets; etc. In the same thought even Trojan using Chrome or Tor using Firefox will have differentiating behaviors from a user using a browser, though that should be hard and expensive to detect.)

I believe continuous updated mitigation should be an acceptable compromise.

Edit:

Tor's meek attempted to use Chrome extensions for proxying TLS connections https://trac.torproject.org/projects/tor/ticket/11393. Chrome extension API creates TLS sockets in extensions/browser/api/socket/tls_socket.cc but Chrome browser itself creates TLS sockets from net/socket/ssl_client_socket_pool.cc. The latter has detailed pooling logic (Default to allow up to 6 connections per host (but kDefaultMaxSocketsPerProxyServer = 32 so just the number of connections can distinguish a user browser vs. a proxy!), TLS 1.3 version interference probe (dynamically downgrade to TLS 1.2 if TLS 1.3 fails)) and the former does not.

[laoyur]

Hi, any progress on OCSP stapling ?

[GreaterFire]

@laoyur This has been excluded from our plan a few years ago.

[blip]

If trojan is behind nginx as described in #131, should stapling be disabled on nginx?

A more general question: if trojan is behind nginx, should it match as many TLS options as possible with those in nginx? Is failing to achieve that considered leaky?