naiveproxy is actively getting detected and filtered by the iran's DPI #404
Comments
Nyxil
changed the title
|
I prefer to believe you were talking a fake report , because naive work well in china. it's really hard to tell iran's GFW better than china GFW,it must be some other reason caused. |
|
Well let me take you to this, DNS is acting weird and today they tried to block all DOH dns, all i want from naive is to handle DNS requests and bump the chromium version faster a little. and so as you can see its device wise and it's so hard to target devices and even with vulnerabilities so maybe it's on the dns but read that talk in bbs. |
|
and about a protocol wide blockage, if they can me and some other of my friends should be blocked, but we are using it more than a month, but android situation is like you your ip is working, domain not blocked even sni is not blocked, but on your phone can't access the webpage of your naive proxy. which is weird and random. and if it's tls problem why we are solving it on windows with DOH and android is hard to fix dns to test if its on dns or tls. |
|
@alirezaac try to switch tls fingerprints on Android |
|
Let me make it more clear ! technically the issue is completely unrelated to DNS, DOH and so on, Now I will describe the flow of issue and possible causes.
Seems like maybe 1% of TLS client hello packets are passing throw the wall in desktop environment, maybe because of some random factors in packet. You can repeat the same test as i described and validate it. @klzgrad I hope you can figure out the issue by the description. |
|
@2378 @Nyxil |
|
@arandomgstring |
|
No. You know though naive proxify all overboard traffic, except one—ip of
itself.
If you use browser to open website of server, the traffic are directly
sent, without passing from traffic agent client. So the tls fingerprints
will be the browser, not traffic agent client.
If you use the traffic agent client to connect other overboard ip, the
traffic pass from client, which sent out the tls fingerprints of client.
So this is the problem.
…----------------------------------------
*From: *Nyxil ***@***.***>
*To: *klzgrad/naiveproxy ***@***.***>
*CC: *Nanyu ***@***.***>; Comment ***@***.***>
*Date: *Nov 26, 2022 01:53:38
*Subject: *Re: [klzgrad/naiveproxy] naiveproxy is actively getting
detected and filtered by the iran's DPI (Issue #404)
@arandomgstring[https://github.com/arandomgstring]
I did read whole the comments in your mentioned issue, but there is
something wrong in their tests !
As i told before there is no problem in visiting web pages via chrome
browser before running naive on the specified domain/ip.
I did serve static web pages with nginx/caddy and can confirm that the
is no problem in visiting the pages using chrome,browser (no TLS
handshake error happens),
The chrome browser handshake errors just appear after running naive on
domain/ip,
So this is obvious that naive's transmitted packets are causing the
domain/ip to get black listed, and also the chrome will face the TLS
handshake error after all,
About the CDN's mentioned in that issue the whole story is different
cause the filtering is done to ASN's of that companies like what
happened to expressvpn ip's.
—
Reply to this email directly, view it on
GitHub[#404 (comment)],
or
unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYDOF2ZXMGSZEUALFN3WKFUSDANCNFSM6AAAAAASK32B7Y].
You are receiving this because you commented.[Tracking
image][https://github.com/notifications/beacon/AKGBAYCT5SXXV6QBZZOFPLLWKFUSDA5CNFSM6AAAAAASK32B72WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSPE4B6Q.gif]Message
ID: ***@***.***>
|
|
@arandomgstring OK, net4people/bbs#153 that's interesting issue ,it has really happened, after read most comments i have to say it's more like a scary title. there weren't any strong evidence to confirm naive has been filtered by iran's DPI, excepte chrome "hello“ is unconditionally blocked. |
|
Yes, this happens in China also. You could confirm that via VMESS/VLESS
server with [SagerNet](https://github.com/SagerNet/SagerNet) opening
browser forward.
And your ssl handshake with server will fail, and you could open the
website of your server via other browsers.
…----------------------------------------
*From: *2378 ***@***.***>
*To: *klzgrad/naiveproxy ***@***.***>
*CC: *Nanyu ***@***.***>; Comment ***@***.***>
*Date: *Nov 26, 2022 03:56:48
*Subject: *Re: [klzgrad/naiveproxy] naiveproxy is actively getting
detected and filtered by the iran's DPI (Issue #404)
@arandomgstring[https://github.com/arandomgstring] OK,
net4people/bbs#153[net4people/bbs#153] that's
interesting issue ,it has really happened, after read most comments i
have to say it's more like a scary title. there weren't any strong
evidence to confirm naive has been filtered by iran's DPI, excepte
chrome "hello“ is unconditionally blocked.
I am not familiar with the Iran net environment, but if this happened
in china, i would first troubleshoot the list of chinamade
software(app) on customer's computer, sometimes they "break" the
traffic proxy more efficiently than china GFW. 😭
—
Reply to this email directly, view it on
GitHub[#404 (comment)],
or
unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYDCNGUVPV4ZF5XHZIDWKGC77ANCNFSM6AAAAAASK32B7Y].
You are receiving this because you commented.[Tracking
image][https://github.com/notifications/beacon/AKGBAYCEFTLHQLKRUTIXAJ3WKGC77A5CNFSM6AAAAAASK32B72WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSPE5DVO.gif]Message
ID: ***@***.***>
|
|
@cross-hello |
Honestly, I don't understand your test. Does Chrome Browser randomly gets SSL error, and Firefox doesn't "when proxy is activated"? It makes no sense. Reinstall your Chrome browser then. But if you get SSL error on Chrome without proxy and on Firefox it's not the case, then it is exactly what I described in that topic.
Incorrect. Chrome sends different types of Client Hellos to different websites, thus if a particular client hello get blocked, you can still open many websites with no problem. If you look at my posts in that topic, you will see that I captured two different client hellos for a single domain/ip on Chrome. I am not sure how Chrome "picks" a client hello for a website, but from my experience the website with Let's encrypt SSL often tend to get blocked on Chrome more often than other websites. So maybe Chrome picks a client hello based on the provider of SSL? You can simply check my claim on WireShark, btw. Open different websites, you will see different JA3 in their client hellos. Even for a single domain you might get different client hellos. Just set "tls.handshake.type == 1" in wireshark's filter. At any rate, you can do a simple check. Capture naive proxy client hello, and check its list of Cipher Suites, the order matters a lot. Now go ahead and open your website on the domain that naive proxy is running on Chrome. Capture its client hello and check its list of Cipher Suites. Are they same, you see the same order? |
|
Please Look at this |
|
Please discuss in net4people/bbs#153. This place is for reporting bugs not general tech support. If it's unconditional blocking of chrome fingerprint there is also nothing I can do here. If naiveproxy doesn't work, try alternatives. |
This is the naive's bug and the condition is that naive client is always getting too many SSL handshake errors before each connection on desktop and does not establish any TLS connection on android, Guess how the whole websites and our services are working very well with chrome and whenever we run the naive on healthy domain/ip cause the chrome browser to fail in handshake, How the whole internet is accessable in chrome and just naive is failing and there is no bug in naive Its totally a funny story |
|
Due to evidence, I am pretty sure that there is a critical bug in naive and you dont wanna even think about the possibilities ! According to the history of censorship in iran, Due to history and what happened to shadowsocks in past, and their technical power, its perhaps possible to detect and mark the naive servers and apply the QoS ! This is what they are doing to all other vpn protocols |
|
@Nyxil |
|
@arandomgstring |
|
The vless + tcp + tls also does not work |
|
@Nyxil
It looks like your server is behind a CDN. Naive proxy doesn't support it. If it isn't, then your problem is worth of discussing. Post it on BBS. |
|
@arandomgstring |
|
I did read your story about chrome but as i told before try to install the chrome version used by naive and run a web server and put network load on the server and check if the chrome browser fingerprint is getting blocked, What if people try to implement proxies on firefox net stack, so there will be no browser engine on planet to use in iran other than netscape 😂 |
Xray uses the most common fingerprint of Chrome, whereas Chrome itself (and naive proxy) might generate different client hellos based on the website you are visiting. Not only I checked this, but also I posted my packets on that link + their fingerprints, while I see no packet from your side; just claims. Besides, WS over TLS is literally indistinguishable from simple tcp - TLS packets, because packets are encrypted via TLS, and ISP cannot detect WS usage at all. What you are saying makes no sense. If you don't believe me, just post your issue on BBS, so that we see if other people are experiencing same issue or not.
Are you perhaps unfamiliar with reverse proxy option of Nginx? With this feature, you can run a Webserver and proxy server on the same domain, IP. One simply define a "path" on domain, and make the proxy server listen to connections on that particular path. Therefore it is indeed possible to open a domain on Chrome and capture its packets (without proxy of course) and then you can also check packets generated by proxy server from that domain and compare the results. This is what I did in that topic. If a particular and not very common fingerprint gets blocked for certain IP ranges, nobody will notice it. This is why you can use your Chrome browser normally. I have nothing else to add, this issue is closed by the owner already. Perhaps we should respect them. |
|
@arandomgstring |
![https://github.com/notifications/beacon/AKGBAYCT5SXXV6QBZZOFPLLWKFUSDA5CNFSM6AAAAAASK32B72WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSPE4B6Q.gif]Message](https://github.com/notifications/beacon/AKGBAYCT5SXXV6QBZZOFPLLWKFUSDA5CNFSM6AAAAAASK32B72WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSPE4B6Q.gif]Message){kind=link}
![https://github.com/notifications/beacon/AKGBAYCEFTLHQLKRUTIXAJ3WKGC77A5CNFSM6AAAAAASK32B72WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSPE5DVO.gif]Message](https://github.com/notifications/beacon/AKGBAYCEFTLHQLKRUTIXAJ3WKGC77A5CNFSM6AAAAAASK32B72WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSPE5DVO.gif]Message){kind=link}
I can confirm as many others in iran that the naiveproxy is actively getting detected and filtered in iran by the DPI,
Seems like the client hello is actively getting detected in few seconds and dropped (not reaching the server), so the SSL handshake error occurs and the QoS applies to the server ip,
Then the naive client will make to many connections and all fail with TLS handshake error, but sometime one can pass throw the wall and establish a very poor and slow connection on desktop, the same slow connection also doesn't even get established on android (maybe by the TLS ciphers difference caused by the hardware )
Do know the possible vulnerabilities causing it to get detected?
Don't hesitate to ask me for evidence like pcaps and so on...
The text was updated successfully, but these errors were encountered: