Network/Proxy Utilities, like Proxifier or Little Snitch, can block "fill" in your browser

Josh Bancroft

I ran into this issue today (and I noticed it in the beta, as well): Once I upgraded my browser extensions to version 4.x (along with 1Password 4 today), they no longer worked. Neither Cmd+\ nor clicking the icon on the toolbar would fill a saved login or password.

I found some threads (including the "Known Issues" thread for 1P4) discussing the fact that Sophos antivirus can cause this issue by blocking network communication between the browser and the 1Password helper process, but I'm not running Sophos or any other antivirus. But those posts gave me a clue.

I am behind a corporate firewall/proxy most of the time, and I use a little utility called Proxifier to force some processes that don't obey my system proxy settings to use the proxy (mostly iMessage and some iCloud stuff). I checked my logs in Proxifier, and sure enough, it was trying to force the 1Password helper process to go through my corporate proxy (instead of just connecting directly on my local machine, 127.0.0.1). I added a rule to let the 1Password helper process use "No Proxy", and it started working again, just fine.

Most of the information I found on the web about this problem relates to antivirus/antimalware software causing this problem, and I didn't immediately make the connection that some other network utilities, like Proxifier, Little Snitch, etc. might cause the same problems (and have similar solutions). Just wanted to share this here so Google can find it, and hopefully help anyone else that's having similar problems.

Thanks, AgileBits, for a great product and great support! :-)

MikeT

Hi Josh,

Thank you very much for writing this up, we'll add the information in our docs as soon as possible.

nikkne

Hey Josh,

thanks! This did the trick for me. Once I disabled GlimmerBlocker, Cmd+\ works. However, I find it quite annoying, since I need to keep it turned off, because I can't add an exception to it for 1Password...

velgor

I don't know about a workaround for LittleSnitch (need to go home and play), but you can set GlimmerBlocker to only work with specific apps:
glimmerblocker.org/wiki/LittleSnitch

MikeT

Hi Josh,

We'd like to add the info our diagnostics tool in case other folks might not know that they have it running. Can you tell me where I can find your Proxifer tool, is it this one?

We tested it but it doesn't to have a daemon running on the system, can you confirm if there's a way we can detect it via processes or any other way we can find it?

nikkne

Hi @velgor,

thanks for the tip. I already use LittleSnitch and the very same workaround, but that does not help in this case. See, the configuration described there allows specific applications to avoid going though the proxy. Hence, in my configuration, all applications (in theory) (except Safari/Chrome/Firefox) should connect directly to the net (and then through LittleSnitch). However, it seems that 1Password for some reason is also trying to go through GlimmerBlocker.

@MikeT, could you also run tests with LittleSnitch and GlimmerBlocker (or just GlimmerBlocker)?

velgor

What port is 1Password communicating on? Seems like all proxy users need do is add 127.0.0.1 plus the port to the bypass settings.

nikkne

Hi @velgor, I have no clue...

However, I don't think there is anything to add in GlimmerBlocker. My pac rule is actually a whitelist for proxy access, like this:

gb.response.contentType = 'application/x-ns-proxy-autoconfig';
gb.response.headers['Cache-Control'] = 'max-age=1800';
var ua = gb.request.headers['User-Agent']; 
ua = ua ? ua[0] || '' : ''; // deref list
var proxy;
if (ua.match(/Safari|Chrome|WebProcess|PluginProcess|Firefox|Camino/))
    proxy = 'PROXY 127.0.0.1:8228' ;
else
    proxy = 'DIRECT';
t = "function FindProxyForURL(url, host) { return '" + proxy + "'; }\n";

Hence, by default 1Password should use the direct connection. And for some reason, it doesn't.

I must admit, I'm quite disappointed in this release of 1Password, as it completely broke my workflow. Cmd+\ does not work anymore, and logging in is really, really painfull (I need to invoke 1Password through the context menu, anchor it, and copy username/password manually). I can't even explain how much pain this causes me.

Agilebits, please don't ever release something on Thursday or Friday, because you'll leave a lot of your users totally frustrated. I now need to find a way to downgrade to 1Password 3.8...

MikeT

Hi @velgor,

Here are the collection of ports it'll try to use if one isn't available: 6263, 10196, 14826, 24866, 25012, 38156, 46365, 49806, 55735, 59488

@nikkne, In your Pac Rule, you have all the browsers set to use the the proxy. The browser extension is a part of your browser and will use the browser to establish a websocket connection on the localhost via any of these ports: 6263, 10196, 14826, 24866, 25012, 38156, 46365, 49806, 55735, 59488.

nikkne

Hi @MikeT, thanks for the list of ports.

I'm still looking for a way to let 1Password establish a direct connection, but didn't make any progress. Here is an excerpt from the GlimmerBlocker's log, where Cmd+\ still does not work:

2013-10-07 13:12:12 [httpsrv-1503] [1] Sender writes 134 bytes client->server.
2013-10-07 13:12:12 [httpsrv-1503] [1] Receiver writes 59 bytes.
2013-10-07 13:12:12 [httpsrv-1503] [1] Sender writes 485 bytes client->server.
2013-10-07 13:12:12 [httpsrv-1505] [1] Request line: 'CONNECT 127.0.0.1:6263 HTTP/1.1'
2013-10-07 13:12:12 [httpsrv-1505] [1]   Host: 127.0.0.1
2013-10-07 13:12:12 [httpsrv-1505] [1]   User-Agent: Safari/8536.30.1 CFNetwork/596.5 Darwin/12.5.0 (x86_64) (MacBookPro9%2C1)
2013-10-07 13:12:12 [httpsrv-1505] [1]   Proxy-Connection: keep-alive
2013-10-07 13:12:12 [httpsrv-1505] [1]   Connection: keep-alive
2013-10-07 13:12:12 [httpsrv-1505] [1] Done reading request header.
2013-10-07 13:12:12 [httpsrv-1505] [1] CONNECT: 127.0.0.1:6263
2013-10-07 13:12:12 [httpsrv-1505] disables keep-alive: Method = CONNECT
2013-10-07 13:12:12 [httpsrv-1505] [1] Port: 6263
2013-10-07 13:12:12 [httpsrv-1505] [1] Connects to port 6263 on /127.0.0.1
2013-10-07 13:12:12 [httpsrv-1505] [1] Did get connection.
2013-10-07 13:12:12 [httpsrv-1505] [1] sendResponseHeaders:
2013-10-07 13:12:12 [httpsrv-1505] [1]   HTTP/1.1 200 Did get connection
2013-10-07 13:12:12 [httpsrv-1505] [1]   Content-Type: text/plain; charset=UTF-8
2013-10-07 13:12:12 [httpsrv-1505] [1]   Connection: close
2013-10-07 13:12:12 [httpsrv-1505] [1]   Proxy-Connection: close
2013-10-07 13:12:12 [httpsrv-1505] [1] Starts sender thread
2013-10-07 13:12:12 [httpsrv-1503] [1] Receiver writes 997 bytes.
2013-10-07 13:12:12 [httpsrv-1505] [1] Sender writes 277 bytes client->server.
2013-10-07 13:12:12 [httpsrv-1505] [1] Receiver writes 265 bytes.
2013-10-07 13:12:12 [httpsrv-1505] [1] Sender writes 127 bytes client->server.
2013-10-07 13:12:12 [httpsrv-1505] [1] Receiver writes 84 bytes.
2013-10-07 13:12:12 [httpsrv-1503] [1] Sender writes 885 bytes client->server.
2013-10-07 13:12:12 [httpsrv-1503] [1] Receiver writes 2117 bytes.
2013-10-07 13:12:12 [httpsrv-1503] [1] Sender writes 1029 bytes client->server.
2013-10-07 13:12:12 [httpsrv-1503] [1] Receiver writes 2896 bytes.
2013-10-07 13:12:12 [httpsrv-1503] [1] Receiver writes 4096 bytes.
2013-10-07 13:12:12 [httpsrv-1503] [1] Receiver writes 4096 bytes.
2013-10-07 13:12:12 [httpsrv-1503] [1] Receiver writes 3392 bytes.
2013-10-07 13:12:12 [httpsrv-1503] [1] Receiver writes 2896 bytes.
2013-10-07 13:12:12 [httpsrv-1503] [1] Receiver writes 4096 bytes.

So, this shows that GB lets 1Password extension actually establishes a connection to 1Password process. However, I don't understand why it does not work.

nikkne

If I'm not mistaken, I think there is no way to setup GlimmerBlocker to allow direct connections for 1Password.

Since 1Password extensions runs in the browser, every connection it tries will be carried out by the browser. Browser, on the other hand, will always first check http://localhost:8228/proxy/pac, which will return either 'DIRECT' or 'PROXY http://localhost:8228'. However, this initial request does not carry any information about the actual request. Hence, the browser will get the info to go through the proxy and establish the connection to it. Then, 1Password's request will be issued through this connection.

From GB's logs, I see how 1Password establishes the connection through GB, and receives the information back, hence there is no blocking. However, the results is that Cmd+\ does not work, and I don't know how to diagnose why 1P does not work...

nikkne

Maybe this will help developers, I found it in the system logs:

8.10.2013 1:08:32.270 PM 2BUA8C4S2C.com.agilebits.onepassword4-helper[1687]: 402002 [EXT:0x7fd935a43160:<OP4ExtensionHTTPConnection: 0x7fd935a5e2f0>] I webSocketForURI: | [ES4] Extension connected Safari-Extension 'safari-extension://com.agilebits.onepassword4-safari-2bua8c4s2c / (null)'
8.10.2013 1:08:32.272 PM 2BUA8C4S2C.com.agilebits.onepassword4-helper[1687]: 402002 [EXT:0x7fd937105c30:<OP4ExtensionClient: 0x7fd935a19090>] I didOpen | [ES4 0x7fd935a19090] Connected 'safari-extension://com.agilebits.onepassword4-safari-2bua8c4s2c:52364'
8.10.2013 1:08:32.278 PM 2BUA8C4S2C.com.agilebits.onepassword4-helper[1687]: 402002 [EXT:0x7fd937105c30:<OP4ExtensionClient: 0x7fd935a19090>] I handleHello: | Welcoming version 4.0.0 of Safari-Extension.
8.10.2013 1:08:32.279 PM 2BUA8C4S2C.com.agilebits.onepassword4-helper[1687]: 402002 [EXT:0x7fd937105c30:<OP4ExtensionClient: 0x7fd935a19090>] I sendAction:payload: | [ES4 0x7fd935a19090] safari-extension://com.agilebits.onepassword4-safari-2bua8c4s2c sendAction: 'welcome'
8.10.2013 1:08:32.336 PM 2BUA8C4S2C.com.agilebits.onepassword4-helper[1687]: 402002 [EXT:0x7fd935a43160:<OP4ExtensionClient: 0x7fd935a19090>] E findExtensionProcessForPort: | Failed to find extension process for 'safari-extension://com.agilebits.onepassword4-safari-2bua8c4s2c:52364', my PID: 1687, invalid output: '1687

'

whero

Hi @sjk,

I do have GlimmerBlocker running. Disabling proxy configuration and everything started to work. Enable the proxy configuration and it did not work again. But, I have localhost, ::1 and 127/8 on my exception list for proxy usage (with a few other domains). The proxy should not be used... Configuring any HTTP proxy actually seems to break the 1Password Browser Extension. So, as far tonights limited testing can tell, it's not related to GlimmerBlocker.

I will do some more testing on this tomorrow and also try to sniff the traffic to see what's going on.

whero

Found the error: PEBKAC

Long explanation: I use GlimmerBlocker with a PAC as I'm also running LittleSnitch. When using a PAC file proxy bypass exception is, of course, not considered.

Solution: add exceptions to the PAC for localhost.

Went from this configuration in GlimmerBlocker (from [http://glimmerblocker.org/wiki/LittleSnitch]):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<glimmerblocker-rules>
    <rule priority="2" type="request" host="127.0.0.1" host-type="is" path="/rule/pac" path-type="is">
        <comments><![CDATA[Proxy PAC file.]]></comments>
        <request language="js" version="1"><![CDATA[gb.response.contentType = 'application/x-ns-proxy-autoconfig';
gb.response.headers['Cache-Control'] = 'max-age=1800';
var ua = gb.request.headers['User-Agent'];
ua = ua ? ua[0] || '' : ''; // deref list
var proxy;
if (ua.match(/Safari|WebProcess|PluginProcess|Firefox|Camino/))
    proxy = 'PROXY 127.0.0.1:8228' ;
else
    proxy = 'DIRECT';
t = "function FindProxyForURL(url, host) { return '" + proxy + "'; }\n";]]></request>
    </rule>
</glimmerblocker-rules>

To this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<glimmerblocker-rules>
    <rule priority="2" type="request" host="127.0.0.1" host-type="is" path="/rule/pac" path-type="is">
        <comments><![CDATA[Proxy PAC file.]]></comments>
        <request language="js" version="1"><![CDATA[gb.response.contentType = 'application/x-ns-proxy-autoconfig';
gb.response.headers['Cache-Control'] = 'max-age=1800';
var ua = gb.request.headers['User-Agent'];
ua = ua ? ua[0] || '' : ''; // deref list
var proxy;
if (ua.match(/Safari|WebProcess|PluginProcess|Firefox|Camino/))
    proxy = '\
    if (isPlainHostName(host) || \
        isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") || \
        isInNet(dnsResolve(host), "172.16.0.0",  "255.240.0.0") || \
        isInNet(dnsResolve(host), "192.168.0.0",  "255.255.0.0") || \
        isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0")) \
        return "DIRECT"; \
\
    return "PROXY 127.0.0.1:8228"';
else
    proxy = 'return "DIRECT"';
t = "function FindProxyForURL(url, host) { " + proxy + "; }\n";]]></request>
    </rule>
</glimmerblocker-rules>

I have sent feedback to the GlimmerBlocker developers.

sjk

FYI, @whero's previous posts here were created from comments split from: Browser extension error: client not verified (FF, Safari & Chrome).

velgor

Brilliant!! Working here. @whero is indeed a hero:)

rowhotygyghibkorus

I also had the same problem with GlimmerBlocker/pac and 1password. I had decided to not use glimmerblocker in the meantime, which I hate because it means I have to make very promiscuous Little Snitch rules for my browser connections. But this solved it. Nice one!

nikkne

Wow @whero, this is amazing! Thanks, this addendum to the GB's rule works.

JimP

Josh: My understanding is that even though you thought that you had this fixed... the problem with Proxifier does remain. It seems that closing proxifier momentarily, and then restarting proxifier again fixes the problem until the next login. Is that what you are seeing?

/Jim