Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Many ClientHello packets could potentially give the Xray/V2Ray server away #192

Open
jacob-schmitt opened this issue Jan 7, 2023 · 11 comments
Open

Many ClientHello packets could potentially give the Xray/V2Ray server away #192

jacob-schmitt opened this issue Jan 7, 2023 · 11 comments

Comments

@jacob-schmitt
Copy link

Hi everyone,

Forgive me if this topic has already been discussed somewhere else, but I thought it could be useful to people in Iran, China, etc.

I was analyzing the VLESS-WS-TLS packets (Xray core v1.7.0) and it immediately caught my attention that there are just so many TLS handshakes happening in the meantime to the proxy server's IP address; and of course every time with the exact same SNI in the Client Hello message. Every connection (e.g. a website visit) triggers a new round of TLS handshake and this could, in my opinion, very well be one of the parameters based on which the GFW in Iran/China judges whether the connection is indeed heading to a circumvention server, and drops the packets or slows down the connection. I have got unfortunately no test results or proof to support this hypothesis, but I thought this could be done by freedom fighter individuals here!

One way to address this supposed issue is probably to run the V2Ray/Xray client in "Proxy" mode and pass the Wireguard/OpenVPN/etc. traffic through the proxy by using the dokodemo-doorinbound connection. I've seen they also recently added the Wireguard inbound to the Xray. This way, we'll only have 1 TLS handshake for the entire browsing/texting/calling/... session.

Please let me know what you guys think.

Best
Jacob
@free-the-internet
Copy link

Hi everyone,

Forgive me if this topic has already been discussed somewhere else, but I thought it could be useful to people in Iran, China, etc.

I was analyzing the VLESS-WS-TLS packets (Xray core v1.7.0) and it immediately caught my attention that there are just so many TLS handshakes happening in the meantime to the proxy server's IP address; and of course every time with the exact same SNI in the Client Hello message. Every connection (e.g. a website visit) triggers a new round of TLS handshake and this could, in my opinion, very well be one of the parameters based on which the GFW in Iran/China judges whether the connection is indeed heading to a circumvention server, and drops the packets or slows down the connection. I have got unfortunately no test results or proof to support this hypothesis, but I thought this could be done by freedom fighter individuals here!

One way to address this supposed issue is probably to run the V2Ray/Xray client in "Proxy" mode and pass the Wireguard/OpenVPN/etc. traffic through the proxy by using the dokodemo-doorinbound connection. I've seen they also recently added the Wireguard inbound to the Xray. This way, we'll only have 1 TLS handshake for the entire browsing/texting/calling/... session.

Please let me know what you guys think.

Best Jacob

You can use mux option only in linux and maybe windows on client side. Mobile is not supported.

@cross-hello
Copy link

cross-hello commented Jan 8, 2023 via email

@free-the-internet
Copy link

Mobile is supported also. As you can see, we run xray in termux, Linux environment in phones. You could copy the configuration from linux or windows to phone, and run with the confuguestion. Then use app like v2rayng to listen localhost HTTP or socks port. Jan 9, 2023 01:40:39 free-the-internet @.***>:
…
Hi everyone, Forgive me if this topic has already been discussed somewhere else, but I thought it could be useful to people in Iran, China, etc. I was analyzing the VLESS-WS-TLS packets (Xray core v1.7.0) and it immediately caught my attention that there are just so many TLS handshakes happening in the meantime to the proxy server's IP address; and of course every time with the exact same SNI in the Client Hello message. Every connection (e.g. a website visit) triggers a new round of TLS handshake and this could, in my opinion, very well be one of the parameters based on which the GFW in Iran/China judges whether the connection is indeed heading to a circumvention server, and drops the packets or slows down the connection. I have got unfortunately no test results or proof to support this hypothesis, but I thought this could be done by freedom fighter individuals here! One way to address this supposed issue is probably to run the V2Ray/Xray client in "Proxy" mode and pass the Wireguard/OpenVPN/etc. traffic through the proxy by using the dokodemo-doorinbound connection. I've seen they also recently added the Wireguard inbound to the Xray. This way, we'll only have 1 TLS handshake for the entire browsing/texting/calling/... session. Please let me know what you guys think. Best Jacob You can use mux option only in linux and maybe windows on client side. Mobile is not supported. — Reply to this email directly, view it on GitHub[#192 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYEDUFU5GTWJIB2DGIDWRL3ZPANCNFSM6AAAAAATUFR474]. You are receiving this because you are subscribed to this thread.[Tracking image][https://github.com/notifications/beacon/AKGBAYGQTDNZC33HV3M6VFLWRL3ZPA5CNFSM6AAAAAATUFR476WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSR6MR4I.gif]

Thanks. But If we can have it in xray in termux, why v2rayNG haven't implemented it? I'm asking this because I see many people requested to mux option, but the developer closed every single request issue with the statement like "mux is not suitable for mobile devices".

@cross-hello
Copy link

cross-hello commented Jan 10, 2023 via email

@wkrp
Copy link
Member

wkrp commented Jan 12, 2023

It is a problem with Shadowsocks too, as I noted at #9:

  • Problem: Shadowsocks opens a separate encrypted TCP connection for every connection made to the proxy. If a web page loads resources from 5 third parties, then the Shadowsocks client makes 5 parallel connections to the proxy.
    • This problem is really about multiplexing, not session/reliability, but several candidate session/reliability protocols additionally offer multiplexing, for example streams in QUIC, streams in SCTP, or smux for KCP. Tor does not have this problem, because Tor already is a multiplexing protocol, with multiple virtual circuits and streams in one TCP/TLS connection. But every system could benefit from adding multiplexing at some level. Shadowsocks, for example, could open up one long-lived connection, and each new connection to the proxy would only open up a new stream inside the long-lived connection. And if the long-lived connection were killed, all the stream state would still exist at both endpoints and could be resumed on a new connection.

The general solution, as others have noted, is to run some kind of multiplexing inside the tunnel, so that the number of proxy connections does not reveal the number of tunneled connections. But you are correct, there are many default configurations where that does not happen, and it could potentially be used as a feature by a censor.

@nirui
Copy link

nirui commented Jan 14, 2023

is to run some kind of multiplexing inside the tunnel

This might help a little, but don't expect too much from it.

I created (and then abandoned) a buggy proxy program 4 years ago and it does support some basic multiplexing features (along with other good stuffs such as frame padding etc). Based on the experience that I had with my program, I realized that even if a proxy multiplexes, if there is not enough streams on that multiplexed connection, the firewall can still detect traffic pattern. Firewalls in today's world maybe powerful enough to figure it out with even more ease.

I'd rather suggest to the developers of proxy software to treat their software as a tool that hides melodies in other melodies and noises, while their powerful and resourceful adversaries are trying to extract the hidden melodies (for example, via Fourier transform) out of all the sounds.

Also, speak of Shadowsocks, based on a few exchanges that I previously had with database64128 who maintains shadowsocks/shadowsocks-rust, I wouldn't hold my breath on multiplexing support for Shadowsocks. Or maybe they've changed their minds during the time? I don't know.

@jacob-schmitt
Copy link
Author

Thank you all for your valuable input.

@free-the-internet: You're absolutely right, I'd completely forgotten about the mux option. However, I tried it with a couple of different values, including 8, 16, 32, and 128, and unfortunately, the results are disappointing. My download speed is dropped by a factor of at least 8 when I use the mux option.

The Wireguard solution I wrote above, on the other hand, is quite performant and acceptable for me, even though in my test setup, the Wireguard was not running on the same VPS as the Xray server. Might be interesting for others.

@nirui: Very interesting analogy with music and melody! I guess the issue you describe as "melody in melody" is analogous to "TLS in TLS", and that is why e.g. the Xray developer came up with the idea of Xray-XTLS-Vision; to reduce multiple layers of encryption where it's not necessary.

@wkrp
Copy link
Member

wkrp commented Jan 14, 2023

I created (and then abandoned) a buggy proxy program 4 years ago and it does support some basic multiplexing features (along with other good stuffs such as frame padding etc). Based on the experience that I had with my program, I realized that even if a proxy multiplexes, if there is not enough streams on that multiplexed connection, the firewall can still detect traffic pattern. Firewalls in today's world maybe powerful enough to figure it out with even more ease.

That is true—multiplexing breaks the 1:1 correspondence between user streams and tunnel streams (with the addition of a session protocol it can even be M:N), but the general concept of traffic analysis encompasses more than just the number of connections. But there's also a fair amount of existing research on traffic shaping and resistance to traffic analysis.

  • Traffic morphing (PDF) (2009) shows how to change one packet size distribution so that it looks like a different distribution, with the constraint that packets can only be padded or split into smaller pieces. It does not send "chaff" packets during idle times and does not otherwise modify timing—in that it resembles the implementation of iat-mode=1 and iat-mode=2 in obfs4.
  • ScrambleSuit (2013) was one of the first deployed circumvention systems to incorporate traffic shaping as a default feature. See Section 4.3 and the important point that every server should have a different packet size and timing distribution, so that if a censor trains a classifier on one server, it does not work against a different server.
  • obfs4 inherits the traffic shaping features of ScrambleSuit (but in practice most servers leave them disabled). The implementation in obfs4proxy is like traffic morphing in that it never delays packets or generates "chaff" packets that do not correspond to an input packet, but the protocol actually allows for almost arbitrary shaping.
  • I haven't seen any implementations take advantage of it, but arbitrary shaping is possible in Shadowsocks too, by encrypting zero-length plaintexts to generate padding whenever needed.
  • Traffic replacement systems, like Slitheen, Protozoa, and Balboa, work by parasitizing an existing real traffic stream and selectively replacing parts of it with tunnel data. OUStralopithecus proposes a way of automatically generating a cover stream.

The field of "encrypted traffic analysis" is concerned with traffic shaping features like packet size and timing (as well as other features like TLS header values). There's a small survey of work by Anderson and McGrew at #7. A good one to start with is Deciphering malware's use of TLS (preprint); Section III-B2 is about packet size and timing.

Circumvention researchers and developers should know about the field of "website fingerprinting", which is probably more attuned than we are to inferring the contents of encrypted tunnels based on externally visible characteristics. There's an IETF draft draft-irtf-pearg-website-fingerprinting-01.html that has a good survey of existing research and proposed defenses, like BUFLO, Tamaraw, and WTF-PAD.

While it's good to be aware of the possibility of traffic analysis attacks, I still think it's more important for circumvention systems to focus on the fundamentals first: address distribution, protocol obfuscation, active probing. I haven't yet seen strong evidence that classifiers of this nature are cheap and effective enough to be used in practice. Even where limited evidence exists, as with the speculations about tunnelled TLS in #129, classification is likely to focus only on the first few seconds of a connection.

@arandomgstring
Copy link

As @jacob-schmitt said, too many TLS client hellos can give a server away.

Actually in current situation of Iran, I don't think that mux option helps much, because from my observation any long connection (+5min) receives random RST packets, forcing re-handshaking, thereby client sends more client hellos. Naturally, such RST packets don't affect web browsing at all, since after a webpage is loaded, there is no need for re-establishment of connection.

It has affected normal download usage however, to the point that in file download manager one might see a fluctuation of speed between 0 and another number (I mean without using proxy of-course, simply downloading a big file from a foreign server is enough to observe this). Messengers user might experience random loss of connection. I cannot demonstrate a strong evidence for such cases, but I believe I am not only one to see such behavior. I wonder if there is anyway to ignore these injected RST packets.

@diwenx
Copy link

diwenx commented Jan 15, 2023

"TLS in TLS", and that is why e.g. the Xray developer came up with the idea of Xray-XTLS-Vision; to reduce multiple layers of encryption where it's not necessary.

I think XTLS-Vision tackles the problem of TLS in TLS by padding small packets (<900bytes). Removing the outer layer of TLS encryption has no effect on the TLS in TLS problem as it only happens after the inner TLS done handshake.

@klzgrad
Copy link

klzgrad commented Jan 23, 2023

speculations about tunnelled TLS in #129, classification is likely to focus only on the first few seconds of a connection.

There have been several straightforward and easy to implement countermeasures proposed for the problem of first few seconds classification in 129. But I haven't seen any of them implemented and there has been no news on gfw upgrades around this. If the time comes it's not too late get back to them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@klzgrad @nirui @wkrp @cross-hello @diwenx @free-the-internet @jacob-schmitt @arandomgstring