search

trojan-gfw / trojan

An unidentifiable mechanism that helps you bypass GFW.
https://trojan-gfw.github.io/trojan/
GNU General Public License v3.0
18.95k stars 3.04k forks source link

a problem #311

Closed wobud closed 4 years ago

wobud commented 4 years ago

I find out a problem which may expose the identity of the server.

If I supply a wrong password in the Igniter deliberatelly, and next step visit a website in chrome, a"400 bad request nginx" error is returned.

If I supply in the remote address a domain which I know doesnt have trojan running on it, a different result is returned..

Chigusa0w0 commented 4 years ago

@wobud Reproduced.

wobud commented 4 years ago

For instance,I use instan.net as the trojan server name and configure it correctly. If I write down the right password in Igniter,so i can use it successfully,right? Now,I write a wrong password, when i visit google.com in chrome and the browser return me a 400 error.

But if i write qq.com as the domain and a casual password, and the browser would return a different result.Even if qq.com runs nginx.

So a website with trojan behind it and a website without trojan behind it behaves differently.

GreaterFire commented 4 years ago

@wobud What different result did you see?

Chigusa0w0 commented 4 years ago

@wobud After some investigation, I believed that this is due to different behavior of HTTP/1.1 and HTTP/2. Thus the difference is expected and the effect on confidentiality of Trojan should be trivial.

ghost commented 4 years ago

@LimiQS i dont understand your test environment and it doesn't seem to be a problem at all.

Chigusa0w0 commented 4 years ago

@johnrosen1 It is indeed a problem. The different result he referred as "返回跟前面不一样的结果，好像是下载个首页下来" (edited) is a valid H2 SETTINGS frame. Which means Trojan client wrongly treat H2 handshake packet as user data. And the web browser downloaded it to the disk. Since it's a misbehavior of Trojan client but not server, this should not be considered as a potential information leak vulnerability.

ghost commented 4 years ago

@LimiQS Please read another issue on trojan-gfw which points to the same issue https://github.com/trojan-gfw/trojan/issues/226

Chigusa0w0 commented 4 years ago

@johnrosen1 Quote: "It's NGINX's issue actually (https://trac.nginx.org/nginx/ticket/816)." (https://github.com/trojan-gfw/trojan/issues/226#issuecomment-578519140)

wobud commented 4 years ago

I changed the web server software from Nginx to Apache, still two different results were returned.

Chigusa0w0 commented 4 years ago

@wobud It has nothing to do with what HTTP Server you are using on your Trojan server. It related to which one is deployed on the irrelevant website. Please check whether accessing http://example.com with Trojan config remote=apache.org:443, a site using Apache, remote=www.iis.net:443, a site using IIS, and remote=lwan.ws:443, a site using Lwan, will trigger the download or not. If yes, could you upload the file downloaded and state your environment information for further investigation?

According to my test, a friendly 400 will be shown when you try accessing to example.com with all above mentioned config. Proving the issue is a Nginx specific bug.

wobud commented 4 years ago

The case is what as you said.Nothing was downloading.

But my trojan server which runs Apache gives back a somewhat different result as apache.org, revealing my server is listening local 127.0.0.1 80 port. See the pics attached. mmexport1583898147987 mmexport1583898152397

Chigusa0w0 commented 4 years ago

@wobud For port display. It is not a Trojan related issue.

wobud commented 4 years ago

@LimiQS I think so.Maybe I should do some changes in the Apache files to get it solved.

wobud commented 4 years ago

Everything is Okay for me now.Turn the server signature off in default.conf. Trojan is really a great project and especially a great idea. I recommend not to use nginx to power the disguise site for the moment.