267504 - Proxy: bypassed in some cases

Status: RESOLVED EXPIRED

(Core :: Networking: HTTP, defect)

Description

[webograph]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041011
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041011

there seems to be a trick which makes mozilla connect to a site directly via
http although there is a proxy specified (automatically via pac-script or manually)
this allows various sites to get your ip-address although you are behind a
non-transparent proxy.

Reproducible: Always
Steps to Reproduce:
1. select a non-transparent proxy
2. start a package-sniffer like ethereal, stop all distracting traffic and start
sniffing
3. visit http://www.cyscape.com/showbrow.asp, for example
4. stop sniffing and filter away packages that are not sent from your computer
to your proxy of vice versa; ethereal example (hephaistos is your computer,
poseidon is proxy: (ip.dst != poseidon && ip.dst != hephaistos) || (ip.src !=
poseidon && ip.src != hephaistos)


Actual Results:  
5. you can see that there is an http get/ok dialog DIRECTLY between your host
and the server you were connecting to -- frightening, ain't it?

Expected Results:  
in my opinion a browser that was told to use a proxy should UNDER NO
CIRCUMSTANCES connect directly anywhere except if its master told him to

i first noticed the bug in wikipedia -- there i don't have any problem with it,
but the fact that it is possible made me look up some things and find this
cyscape-test

Comment 1

[Frank Wein [:mcsmurf]]

wfm with a current Mozilla build. The only traffic that was not going over proxy
was a single DNS query, also normally that also should go over the proxy? Anyway
that site seems to use Java. Did you check if maybe your jre does not use the proxy?

Comment 2

[webograph]

i just repeated the experiment using firefox on a windows-pc (changed os to
'all'). two new results:
a) i get my ip-address in the result even if i use the personal firewall to
block outgoing traffic. in connection with your assumption concerning java this
would mean that i could close this bug and change it to invalid, BUT
b) i get the outgoing traffic even if i disable java. it also comes from the
firefox-process (according to zonealarm) and not from the java-process (from
which it ought to originate if it was a java problem)

i'll leave it unconfirmed, please check it again with java disabled

btw this bug is contrary to what i learned in the course of the ccna-curriculum
(it should be impossible to determine the ip-address that way) - any ideas?

Comment 3

[Frank Wein [:mcsmurf]]

(In reply to comment #2)

> i'll leave it unconfirmed, please check it again with java disabled

still wfm (on Win2k with Mozilla). Maybe you can create a HTTP log, see
http://www.mozilla.org/projects/netlib/http/http-debugging.html for a how-to.

Comment 4

[Robert Strong (they/them - no direct email)]

I wasn't able to reproduce this but I have in the past and with a quick search I
found some details regarding java applets having the capabilty to connect
directly and completely bypass a browsers settings. As a side note, when I
tested this before I did so with Opera and IE (both with and without the MS JVM)
with the same results of the applet providing the IP Address to that site.

Comment 5

[OstGote!]

WFM with Moz 1.8a5. Are you sure your proxy is really non-transparent? Did you
check it at the same time (!) with IE?

Comment 6

[webograph]

Attachment: log-file

i repeated the experiment on the original linux machine with java switched off
and cookies deleted. i created a logfile which i will attach (in full length
hence i don't know what is really important and what not). not knowing what the
lines mean, i simply looked through it and -- correct me if i'm wrong -- i
think that the problem shows up when running
bash$ grep nsSocketTransport::Init\  log.txt
16386[810bdc0]: nsSocketTransport::Init [this=838d740 host=poseidon:80
proxy=:0]
16386[810bdc0]: nsSocketTransport::Init [this=8503ac8 host=www.cyscape.com:80
proxy=poseidon:3128]
16386[810bdc0]: nsSocketTransport::Init [this=8b8cee0 host=schk.cyscape.com:443
proxy=poseidon:3128]
16386[810bdc0]: nsSocketTransport::Init [this=8947120 host=www.cyscape.com:80
proxy=poseidon:3128]
16386[810bdc0]: nsSocketTransport::Init [this=8ccf438 host=www.cyscape.com:80
proxy=:0]
please note that the first entry is for the automatic proxy script.
the last entry shows that no proxy is used. maybe the third line might give a
hint at how that works: it connects to a host using the default imap port, thus
maybe tricking some browsers into giving up their proxy connection -- just an
idea.

hth

Comment 7

[Frank Wein [:mcsmurf]]

It seems Mozilla "forgets" the proxy at some point:
[...]
16384[8072618]: nsHttpHandler::NewURI
16384[8072618]: nsHttpHandler::NewURI
16384[8072618]: nsHttpHandler::NewURI
16384[8072618]: nsHttpHandler::NewURI
16384[8072618]: nsHttpHandler::NewProxiedChannel [proxyInfo=0] <--proxyInfo
shouldn't be 0 here as far as i see
16384[8072618]: Creating nsHttpChannel @8cccda8
16384[8072618]: nsHttpChannel::Init [this=8cccda8]
16384[8072618]: host=www.cyscape.com port=-1
16384[8072618]:
uri=http://www.cyscape.com/brws/cyscapeBRWS.dll?ax=0&bhax=0&aol=0&aolv=0&bgs=0&beta=0&brow=Mozilla&bhbd=&bhdt=Thu%20Nov%20%204%2018:03:44%202004&bhcd=16&gz=1&bhsp=-1&bhct=&cook=1&bhce=0&bhcy=AT&craw=0&bhdh=1&em=0&fupl=Yes&bhfw=0&fcl=1&fs=1&bhfs=0&fram=1&vf=1.7.3&bhgk=1&bhgb=20041011&hdml=0&bhsh=1280&bhih=1059&bhif=1&bhim=1&ip=80.110.86.202&ja=1&bhje=0&js=1&bhjr=&bhjs=1&jsv=1.5&bhjv=&bhjm=&bhls=&lang=English&bhlu=en-us&vm=1&mou=1&bhmj=&msn=0&bhxm=-1&bhci=0&bhcv=&bhnm=&os=Linux&pda=0&plat=U
[...]

Comment 8

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 9

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.