PSM hooks using network to local daemon are routing through Proxy Server



20 years ago
3 years ago


(Reporter: jelwell, Assigned: dougt)


1.0 Branch
Windows NT

Firefox Tracking Flags

(Not tracked)


This causes an error which makes it so I can't edit my security settings or
import/export certificates.

Steps to reproduce:
1) Edit... Preferences... Proxies
2) Change your HTTP Proxy to
3) Click OK
4) Click on the security (lock) icon next to the build number.
Actual Result:
PSM window pops up and is unusable. I can NOT select tabs or edit preferences or
view certs. Instead I receive a popup window that says this:
"ERROR: The requested URL could not be retrieved

While trying to retrieve the URL:

The following error was encountered:
ERROR 312 -- Cannot connect to the server

This means that:
The server might be down, or it could be inaccessible because of a temporary
problem. Please try again later. If you receive this message frequently, contact
your system administrator."

Expected Result:
PSM window pops up and is usable. I can select tabs and edit preferences as well
as view certs.

If PSM is going to be accessed via a connection to localhost then it should do
so without trying to use the webproxy! Otherwise users that have webproxys that
aren't smart enough to route localhost requests back to the localhost will not
be able to manage their security.
cc'ing cbegle at request. and marking major as there is a major loss of
functionality for users with proxy servers.
Severity: normal → major
*** Bug 31174 has been marked as a duplicate of this bug. ***
31174 is related to this bug, but not a duplicate.  For PSM UI to work 
correctly with a proxy setup (what's relevant here is regular proxy, not secure 
proxy), mozilla should isolate the PSM UI type URLs and make a direct 
connection (i.e. bypass proxy).  This problem should be handled by the http 
protocol handler (or a proxy protocol handler if there is such a component).

The "signature" of the PSM UI URLs is of the form 
http://x:noncexxxxxx@ where x is a number.  I believe it 
would be sufficient to use "@" part as the matching criteria.  This 
has an implication that any URL that happens to contain such an element will 
not go through the proxy server, but I would think that is very very rare, if 
any, and it will still connect (although directly).
For non-proxy users (and without a firewall), this is also a security problem,
as PSM starts a server on the client without the user even noticing.
Could you elaborate on the security risk?  If your concern is about others 
trying to connect to the PSM port, we have a number of safeguards against that 
to make sure that doesn't happen.  For example, no non-localhost client can 
connect to the port.
See bug 31510, which I just filed (before I saw this bug :() I don't know if you
want to mark this as a dupe.
*** Bug 31510 has been marked as a duplicate of this bug. ***
we can not restrict usage by since a lot of 3rd party utilities run on
localhost as proxies. 
yes, that was my concern.
- What else precautions did you take?
- Can you be sure, the IP isn't faked?

is it possible specifiy a host *and port* in the exclude list?
I have a bad feeling with this running as server.
It's now much more secure than that.  We gave it more security considerations 
for the final PSM 1.1 that will come out shortly.  We now bind these PSM ports 
completely locally so that non-localhosts can't even connect to the ports in 
the first place.  We also have been using nonces (session passwords) to 
authenticate each individual connection on top of that.  Getting all of that 
would be pretty difficult, if not impossible.
Workaround for the initial bug: If you include the host to the list of
No proxy for, it will work fine.

assigning to me.
Assignee: lord → dougt
if you are running through a proxy, cartman does not work.  
Keywords: nsbeta2
Closed: 20 years ago
Resolution: --- → FIXED
QA Contact: lord → junruh
Product: PSM → Core
Version: psm1.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.