Client app comparison for various protocols / platforms #195
Comments
|
@amircybersec Also you might like to add http injector https://play.google.com/store/apps/details?id=com.evozi.injector&hl=en&gl=US. Not only it supports v2ray config files, but it is an excellent tool for ssh proxy, shadowsocks, and even stunnel. |
|
@arandomgstring Thanks of the pointer to HTTP Injector! :) I will add that to the table. We have many users in Iran who are using Shadowsocks protocol with either Shadowsocks App or Outline app quite consistently (except during complete International traffic shutdowns or severe throttling). On the other hands, there were many other users were not able to connect to the same servers at the same time using Shadowsocks even if they were on the same mobile carrier. Since censorship tactics and intensity vary over time, region, ISP, sub-network, etc, one method that may work for one person may not work for others. I am personally a proponent of protocol diversification since if everyone ends up using the same method to connect, it will become easier to targeted and blocked it. Also, I don't think there's much difference between Outline implementation of Shadowsocks and other applications' implementations of it such as Shadowsocks, v2rayNG, etc (unless it is ShadowsocksR, i.e., ssr). In other words, in most cases, if users can connect with Outline, they can also connect with other apps supporting Shadowsocks protocol. If they are not able to connect using Outline, most likely other client apps won't connect either. |
|
I don't remember saying implementation of Shadowsocks in different applications makes any difference. What I meant was Shadowsocks protocol itself compare to TLS based proxies, such as Vless + TLS. The difference between them is that in former, no tls handshake is done, while in later we do have handshake, and it is a big difference. Other than that, there is absolutely no difference between them, because they both use usual TLS encryptions such choca or aes. I do agree with your point on the fact that people should use different protocols. However, I have seen many Iranian people claiming that an IP has become dirty (its speed has been throttled) just because someone has already used Shadowsocks on that IP, making it unavailable to other people. While I do have my doubts regarding this claim, seeing many people making this claim makes me think that maybe it's not baseless after all. At any rate, if Shadowsocks works, then it is a good tool to have. Censors will not exhaust IPv4 space, or would they? |
|
I was just trying to clarify the Outline implementation of shadowsocks part which sometimes can cause confusion. Although to be very technical, Outline-ss-server is a fork of the original shadowsocks as many other servers and they are differences in implementation. My knowledge of what works or not are mostly anecdotal and based on most high level observations rather than detailed network analysis or measurement. Overall my data points are a bit sparse. For example, I have observed vmess or shadowsocks working for a given person and that person being the first user of the server (I don't put too many people on one server). But after 100MB/800MB dn/up traffic, it would stop working. I believe there are some pre-filtering stages that select data streams based on amount of data transferred (maybe during a certain period of time), and if it is surpassed, the program performs more computational extensive protocol analysis on it. I guess if you stay behind a certain threshold, you may get away with whatever protocol you are using. Switching to Vless+TLS seemed to address the issue for these cases noting they did not block the IP addressed and only dropped the packets. It could be that blocking IP might be an escalation of several parameters. Also, it seems like that data-center IP address ranges get more attention in the pre-filtering process since it's a very small subset of IPv4 space and more data centers publish it publicly and screening every single packet that leaves the network. In essence, it's all about computation cost and what they are willing to do. Of course, super simple technical solution is to completely shut-off traffic to non-Iran IP addresses but there are other costs associated with decision. China kind of settled on what keeps most people give up on looking for VPN and adopt their domestic solutions; They realized that shutting off access to global Internet is bad for business. Of course, Iran is a completely different story.... |
Actually, V2RayN support hysteria and naiveproxy |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Grate table |
|
@RayWangQvQ Thanks for your comment. If I understand correctly, to use hysteria or naiveproxy, a plug-in must be loaded? Maybe I should include a distinction between bult-in support and plug-in support....I would appreciate your feedback. |
|
@arandomgstring A quick update on Shadowsocks. Outline Client version 1.9.0 has added support for appending access keys with a “prefix” option. The “prefix” is a list of bytes used as the first bytes of the salt of a Shadowsocks TCP connection. This can make the connection look like a protocol that is allowed in the network, circumventing firewalls that reject protocols they don't recognize. Some tests have demostrated that uisng port 53 and the prefix '\x05\xDC\x5F\xE0\x01\x20', Outline serves can be accessed on MCI, Irancell and AsiaTech. The prefix pretends to be a DNS over TCP message of size 1500. Here's an example: Try: ss://…/?outline=1&prefix=<HTTP%2F1.1%20> Or ss://…/?outline=1&prefix=<%16%03%03%40%00%02> For more information, check out the link below: https://www.reddit.com/r/outlinevpn/wiki/index/prefixing/ Please note that this is a pure client-side solution and works with any implementation of shadowsocks server (i.e. shadowsocks-rust or shadowsocks-libev, etc). Other clients currently don't support this feature. There's a lengthy discussion of pros and cons of this approach here. In a nutshell, it is recommended to use the prefix if normal shadowsocks without prefix cannot be accessed and not as default: |
Yeah, you are right. I can provide a sample, such as adding naiveproxy for V2RayN, there are two things that need to do:
then it works update: after the version of v6, you do not need download the exe file yourself. |
|
I would dispute or raise concern about the claimed protocol support for naiveproxy in ShadowRocket. I am not aware of how ShadowRocket is using the source code or binary distributions of naiveproxy. It is possible that ShadowRocket has independently implemented the "naiveproxy protocol" (i.e. Cronet http2 tunnels with padding), but so far I am not aware of public information showing this, so it is also possible that ShadowRocket has implemented something else different from naiveproxy. |
|
@amircybersec the table is very helpful, thank you! It would be nice to indicate what protocols are TLS-based. As mentioned in #195 (comment), the different protocols don't matter as much when they are over TLS. Though the implementation of TLS does matter, so it would would be great to learn more about what TLS implementation they are using. For instance, NaiveProxy uses the Chromium implementation, which makes them more resistant to TLS-fingerprinting than others. Similarly, the Shadowsocks implementation also matters. See https://github.com/Jigsaw-Code/outline-server#shadowsocks-resistance-against-detection-and-blocking for some of the changes we made to Outline in the past. For instance, coalescing the initial user data with the proxy request makes the size of the initial packet variable, which makes Shadowsocks less fingerprintable. I know shadowsocks.libev implements that, but I don't know about the other implementations. |
|
@fortuna Thanks for the feedback! much appreciated :) I made this table to help end-users in choosing the right client side application given a target platform and config/access link for a given protocol. I realized users were quite confused which application to use for what. I think based on your feedback, it make more sense that I make another table to breakdown each protocol with a given client/server implementation based on their capabilities (e.g. TLS based or not, what TLS implementation they use, resilience against fingerprinting, active probing, replay attacks, etc) |
|
@klzgrad thanks for brining that up. I will have to investigate this again and revise the table. |
|
add v2box for ios |
|
bravo guys |
|
The list need a update, ios ... |
There has been some confusion among users on what client application to install and use on a given platform/OS for a specific protocol. I made a table to bring all that information together so that it can help users better decide on which app to use. I wanted to add some information on ease of use or application quality/stability but I thought it might be difficult to do that while being 100% objective.
Application
Please share this information with others as it might help them choose the right application, and let me know if I missed any application...
The text was updated successfully, but these errors were encountered: