external connections from keepassxc-proxy #100

a-v-popov · 2018-03-31T09:31:04Z

Expected Behavior

If my understanding is correct keepassxc should not have any external communication.

Current Behavior

$ netstat -atpn | grep keepass
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:6080 0.0.0.0:* LISTEN 8307/keepassxc-prox
tcp 0 0 127.0.0.1:6080 127.0.0.1:55164 CLOSE_WAIT 8307/keepassxc-prox
tcp 1 0 192.168.1.4:55578 173.194.222.190:443 CLOSE_WAIT 8307/keepassxc-prox
tcp 1 0 192.168.1.4:48552 173.194.221.139:443 CLOSE_WAIT 8307/keepassxc-prox

Debug info

KeePassXC - 2.3.1
keepassxc-browser - 1.0.1
Operating system: Linux
Browser: Firefox/Chromium
Proxy used: YES

varjolintu · 2018-03-31T10:16:25Z

keepassxc-proxy is using only Unix Domain sockets for communication. So showing some TCP sockets open seems a bit strange..

a-v-popov · 2018-03-31T12:52:10Z

Apparently this thing is based upon high level libs and some google magic. Honestly, it is not very surprising that it can be doing a lot more than it was intended to. I suspect it might be related to extension debugging which I initiated from chromium as the extension did not work for me. Unfortunately I had to kick it out from the host and it will take me some time to repeat it in a VM.
The only thing I can say at the moment is that sha checksum on source tarball is the same as on github.

droidmonkey · 2018-03-31T13:19:47Z

Google owns the 173.194.0.0 ip range. https://ipinfo.io/173.194.222.190

When you enabled debugging you probably also enabled stats reporting and other things. The top two tcp lines are local connections.

a-v-popov · 2018-04-07T12:00:43Z

One of the components provided by keepassxc openned a connection to external IP.
Please note that it wasn't opened by Chromium or Firefox, but by you executable, which is also involved in handing sensitive data.
Can you please elaborate why it opened a remote connection?

varjolintu · 2018-04-07T12:16:54Z

Can you please elaborate where do you see this connection and where does it connect? Or is this still some Google magic? keepassxc-proxy doesn't open any other connections than the Unix Domain socket to localhost.

Also, please note that while keepassxc-proxy handles sensitive data, it is encrypted and the executable lacks the functionality to decrypt it.

Reopening the issue until this has been solved.

a-v-popov · 2018-04-07T20:22:48Z

Got the same picture with fresh ubuntu 17.10 install in VM. Steps to reproduce:

install ubuntu from official image
add keepassxc-browser plugin into Firefox
install keepassxc from "official PPA" as per keepassxc.org download page
create a new database
press reload button in plugin interface
On the first connection I saw the following:

user@ubuntu-vm:~$ sudo netstat -apn | grep keepassxc-p
tcp       32      0 192.168.2.245:58570     52.89.239.72:443        CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:47546     54.230.12.110:443       CLOSE_WAIT  3711/keepassxc-prox 
tcp       32      0 192.168.2.245:58572     52.89.239.72:443        CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:58346     54.230.14.25:443        CLOSE_WAIT  3711/keepassxc-prox 
tcp       32      0 192.168.2.245:58548     52.89.239.72:443        CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:47558     54.230.12.110:443       CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:47550     54.230.12.110:443       CLOSE_WAIT  3711/keepassxc-prox 
tcp       32      0 192.168.2.245:58574     52.89.239.72:443        CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:47552     54.230.12.110:443       CLOSE_WAIT  3711/keepassxc-prox 
tcp        0      0 192.168.2.245:60556     93.184.220.29:80        ESTABLISHED 3711/keepassxc-prox 
tcp        1      0 192.168.2.245:47548     54.230.12.110:443       CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:58344     54.230.14.25:443        CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:47554     54.230.12.110:443       CLOSE_WAIT  3711/keepassxc-prox 
tcp       32      0 192.168.2.245:46282     35.161.134.132:443      CLOSE_WAIT  3711/keepassxc-prox 
unix  3      [ ]         STREAM     CONNECTED     47161    3711/keepassxc-prox  
user@ubuntu-vm:~$

It will also open remote connections on subsequent restarts, but you might need to try a few times.

varjolintu · 2018-04-08T05:33:07Z

I'm seeing this too. All the ports are 80 or 443 so this is clearly web browser traffic. I'm pretty sure this has something to do with native messaging because the keepassxc-proxy process is started by the browser. The reason for this is unclear, and I don't like seeing this kind of behaviour.

Btw, the socket list disappears when you close your browser.

remspoor · 2018-04-08T15:18:19Z

I just want to let everyone know that i see the same behavior. Actually i found this bug while searching for answers.
Running Arch linux with firefox 59.0.2 (64-bit)

tcp 0 0 192.168.1.1:54300 151.101.37.105:http ESTAB 2724/keepassxc-prox
tcp 1 0 192.168.1.1:54210 172.217.19.206:http CLOSE-WAIT 2724/keepassxc-prox
tcp 0 0 192.168.1.1:45206 31.22.22.135:https CLOSE-WAIT 2724/keepassxc-prox
tcp 0 0 192.168.1.1:52286 95.101.1.104:http ESTAB 2724/keepassxc-prox
tcp 0 0 192.168.1.1:46138 66.96.160.139:http CLOSE-WAIT 2724/keepassxc-prox
tcp 0 0 192.168.1.1:35874 139.15.248.182:https CLOSE-WAIT 2724/keepassxc-prox
tcp 1 0 192.168.1.1:54206 172.217.19.206:http CLOSE-WAIT 2724/keepassxc-prox
tcp 1 0 192.168.1.1:54208 172.217.19.206:http CLOSE-WAIT 2724/keepassxc-prox
tcp 1 0 192.168.1.1:54314 172.217.19.206:http CLOSE-WAIT 2724/keepassxc-prox
tcp 1 0 192.168.1.1:54212 172.217.19.206:http CLOSE-WAIT 2724/keepassxc-prox
tcp 0 0 192.168.1.1:49150 23.62.98.18:http ESTAB 2724/keepassxc-prox
tcp 0 0 192.168.1.1:54270 151.101.37.105:http ESTAB 2724/keepassxc-prox

varjolintu · 2018-04-08T15:23:52Z

Seems these connections happen only with Firefox. I opened a bug. Let's see what they respond.

droidmonkey · 2018-04-08T17:45:35Z

After I tested this, I personally found that turning off the telemetry and usage data in Firefox prevented the sockets from being opened. @varjolintu could not replicate that fix though. Chromium does not exhibit this behavior at all.

varjolintu · 2018-04-08T18:17:36Z

For me the opened connection was a HTTP GET request to http://detectportal.firefox.com/success.txt which had a X-Amz-Cf-Id reply with encrypted data (a token perhaps).

Also, see this. This still doesn't explain why native messaging opens those TCP sockets.

varjolintu · 2018-04-23T12:18:04Z

According to this page the bug is fixed with Firefox 61.

droidmonkey · 2018-04-23T15:50:18Z

I'm closing this issue since it is clearly not a KeePassXC issue.

brzd · 2019-03-27T15:12:45Z

Could you please, reopen and investigate further. KeepassXC-Browser opens ports to several awkward addresses, non-Google, such as 104.31.74.222 (Cloudflare), 193.229.109.157, etc.

varjolintu · 2019-03-27T15:27:42Z

@brzd KeePassXC-Browser? Do you mean keepassxc-proxy? Looking at the Firefox issue few messages earlier they have fixed the bug. What browser are you using? Any details are welcome.

Just to make clear: keepassxc-proxy (or the extension, with the exception of GitHub when checking the latest KeePassXC version available) DOES NOT open any connections to anywhere. The only thing keepassxc-proxy uses is a local Unix domain socket that communicates directly with KeePassXC.

brzd · 2019-03-27T15:32:08Z

Firefox 66.0.1

So it would still be the same issue with firefox?

varjolintu · 2019-03-27T15:41:28Z

@brzd Mozilla reports it has been fixed in Firefox 61. I'll try to reproduce this myself and make another bug report if necessary. This is related to native messaging itself, not KeePassXC or the proxy.

Cherkah · 2019-04-29T12:05:56Z

i've the same issue with keepassxc-proxy & i'm running the flatpak one .
keepassxc-browser get external connections!!!! Does my passwords are send on the web???
why can't i untick the proxy option in the keepassxc?
as you can see, the sh process are related to the keepassxc-proxy'process

$ sockstat -4 -l
MEE sh 27179 tcp4 192.168.43.205:53534 23.62.98.16:80 ESTABLISHED
MEE sh 27179 tcp4 192.168.43.205:46734 138.201.81.199:443 ESTABLISHED
MEE sh 27179 tcp4 192.168.43.205:48708 93.184.220.29:80 ESTABLISHED
MEE sh 27179 tcp4 192.168.43.205:43592 143.204.192.7:443 ESTABLISHED
MEE keepassxc-proxy 27181 tcp4 192.168.43.205:53534 23.62.98.16:80 ESTABLISHED
MEE keepassxc-proxy 27181 tcp4 192.168.43.205:46734 138.201.81.199:443 ESTABLISHED
MEE keepassxc-proxy 27181 tcp4 192.168.43.205:48708 93.184.220.29:80 ESTABLISHED
MEE keepassxc-proxy 27181 tcp4 192.168.43.205:43592 143.204.192.7:443 ESTABLISHED

Debug info

KeePassXC - 2.4.1
keepassxc-browser - 1.4.3
Operating system: Linux
Browser: Firefox quantum 66.0.1
Proxy used: YES

varjolintu · 2019-04-29T12:16:34Z

@Cherkah This is a Firefox bug. Your passwords are not sent anywhere. Even if that bug would leak any data (for some reason), it would be encrypted.

Cherkah · 2019-04-29T12:32:28Z

ok but why can't we untick the option keepassx-proxy (keepassxc flatpak/snap) whereas the distro app (debian) we can? the option is greyed

Even if that bug would leak any data (for some reason), it would be encrypted.

maybe, but i'm the kind of people which do not have any confidence about amazon (143.204.192.7:443 ESTABLISHED).

please make the option un-greyed.
thx

droidmonkey · 2019-04-29T16:28:30Z

@Cherkah you can just not use the browser extension. Even if there is no proxy, launching the KeePassXC application itself would cause those phantom connections to occur. We have zero control over that because, as repeatedly stated, this is a bug/feature in Firefox itself.

Cherkah · 2019-06-19T14:21:35Z

after let a ticket to mozilla foundation about this probleme ( base on your statement and my connection report) it seem that is your softwar which make bull****.

i do not understand why varjolintu tells & droidmonkey tells are so divergent?! for one it is not normal and for the other one " those phantom connections" are secure....

just to test your soft i reinstall all my system, change my browser, block ip via iptable: the issue remains.

so sorry but i' do not trust your app. results: uninstall it and change all my password.
most of people consume freely softwar in trust but few of them keep a regards on what it did.

thanks

varjolintu · 2019-06-19T14:30:54Z

@Cherkah It's a known problem in Firefox that causes this issue. Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1463873. There's still no fix available.

These phantom connections mean that KeePassXC or the proxy doesn't directly open a socket to anywhere, but when Firefox forks a process via Native Messaging, those sockets are copied to the other process. And also, KeePassXC or the proxy doesn't use those sockets for anything.

If you want to get rid of the bug or you are concerned (assuming you don't trust our application), all you can do is to switch to another browser. You are also always welcome to inspect our source code if you think our applications are making some phantom connections.

jurisbu · 2019-08-29T17:23:10Z

Any updates on this? This is suspicious.

phoerious · 2019-08-29T17:42:40Z

We cannot do anything about that. It's a Firefox bug. We neither open nor use these connections.

j1warren · 2019-10-28T10:32:28Z

but when Firefox forks a process via Native Messaging, those sockets are copied to the other process.

@varjolintu, ok, then why don't make keepassxc-proxy explicitly close any leftover fd's on start?

varjolintu · 2019-11-06T16:56:50Z

@j1warren That could be possible yes, but I wonder if there's a solid cross-platform way to do that.

droidmonkey · 2019-11-06T17:38:15Z

Can we close a socket owned by a parent process?

varjolintu · 2019-11-06T17:42:41Z

We should investigate if the socket is indeed a copy. In that closing them would probably cause more bad than good.

aadrian · 2019-12-01T11:24:52Z

Would you please reopen this issue?

This issue still exists: the keepassxc-proxy processes still have connections outside the local machine in the latest versions of Firefox + Keepassxc + keepassxc plugin :( .

This alone put KeepassXC in a few companies on the ban list :( .

Thank you.

varjolintu · 2019-12-01T11:27:12Z

@aadrian Again: this is not a KeePassXC issue. It's a Firefox bug.

aadrian · 2019-12-01T12:06:31Z

@varjolintu This issue affects KeePassXC however, even if (technically) the source of the Bug is Firefox.

Also because of this: not Firefox landed on the ban list, but KeePassXC :( .

IMO until the problem is fixed, the issue should not be "closed" but kept open with a tag/label of "waiting for 3rd party".

If there's a simple temporary workaround until FF is fixed (e.g. a simple iptables rule), it might also greatly help.

varjolintu · 2019-12-01T12:14:28Z

@aadrian I'll open this with the label added.

0xpr03 · 2020-07-11T00:41:31Z

Same here on firefox, browser plugin creates open sockets

172.65.251.78:https (CLOSE_WAIT)
ec2-52-26-249-11.us-west-2.compute.amazonaws.com:https (ESTABLISHED)

Just for documentation

varjolintu added the not a bug label Apr 1, 2018

varjolintu closed this as completed Apr 7, 2018

varjolintu reopened this Apr 7, 2018

droidmonkey closed this as completed Apr 23, 2018

varjolintu mentioned this issue Oct 26, 2019

Network connections to sites I browse from keepassxc-proxy #651

Closed

varjolintu added 3rd party bug and removed not a bug labels Dec 1, 2019

varjolintu reopened this Dec 1, 2019

keepassxreboot locked as resolved and limited conversation to collaborators Jul 11, 2020

varjolintu closed this as completed Aug 29, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

external connections from keepassxc-proxy #100

external connections from keepassxc-proxy #100

a-v-popov commented Mar 31, 2018 •

edited by droidmonkey

varjolintu commented Mar 31, 2018

a-v-popov commented Mar 31, 2018

droidmonkey commented Mar 31, 2018 •

edited

a-v-popov commented Apr 7, 2018

varjolintu commented Apr 7, 2018 •

edited

a-v-popov commented Apr 7, 2018

varjolintu commented Apr 8, 2018 •

edited

remspoor commented Apr 8, 2018 •

edited

varjolintu commented Apr 8, 2018

droidmonkey commented Apr 8, 2018

varjolintu commented Apr 8, 2018

varjolintu commented Apr 23, 2018

droidmonkey commented Apr 23, 2018

brzd commented Mar 27, 2019

varjolintu commented Mar 27, 2019 •

edited

brzd commented Mar 27, 2019

varjolintu commented Mar 27, 2019

Cherkah commented Apr 29, 2019

varjolintu commented Apr 29, 2019

Cherkah commented Apr 29, 2019 •

edited

droidmonkey commented Apr 29, 2019

Cherkah commented Jun 19, 2019

varjolintu commented Jun 19, 2019

jurisbu commented Aug 29, 2019

phoerious commented Aug 29, 2019

j1warren commented Oct 28, 2019 •

edited

varjolintu commented Nov 6, 2019

droidmonkey commented Nov 6, 2019

varjolintu commented Nov 6, 2019

aadrian commented Dec 1, 2019

varjolintu commented Dec 1, 2019

aadrian commented Dec 1, 2019

varjolintu commented Dec 1, 2019

0xpr03 commented Jul 11, 2020

external connections from keepassxc-proxy #100

external connections from keepassxc-proxy #100

Comments

a-v-popov commented Mar 31, 2018 • edited by droidmonkey

Expected Behavior

Current Behavior

Debug info

varjolintu commented Mar 31, 2018

a-v-popov commented Mar 31, 2018

droidmonkey commented Mar 31, 2018 • edited

a-v-popov commented Apr 7, 2018

varjolintu commented Apr 7, 2018 • edited

a-v-popov commented Apr 7, 2018

varjolintu commented Apr 8, 2018 • edited

remspoor commented Apr 8, 2018 • edited

varjolintu commented Apr 8, 2018

droidmonkey commented Apr 8, 2018

varjolintu commented Apr 8, 2018

varjolintu commented Apr 23, 2018

droidmonkey commented Apr 23, 2018

brzd commented Mar 27, 2019

varjolintu commented Mar 27, 2019 • edited

brzd commented Mar 27, 2019

varjolintu commented Mar 27, 2019

Cherkah commented Apr 29, 2019

varjolintu commented Apr 29, 2019

Cherkah commented Apr 29, 2019 • edited

droidmonkey commented Apr 29, 2019

Cherkah commented Jun 19, 2019

varjolintu commented Jun 19, 2019

jurisbu commented Aug 29, 2019

phoerious commented Aug 29, 2019

j1warren commented Oct 28, 2019 • edited

varjolintu commented Nov 6, 2019

droidmonkey commented Nov 6, 2019

varjolintu commented Nov 6, 2019

aadrian commented Dec 1, 2019

varjolintu commented Dec 1, 2019

aadrian commented Dec 1, 2019

varjolintu commented Dec 1, 2019

0xpr03 commented Jul 11, 2020

a-v-popov commented Mar 31, 2018 •

edited by droidmonkey

droidmonkey commented Mar 31, 2018 •

edited

varjolintu commented Apr 7, 2018 •

edited

varjolintu commented Apr 8, 2018 •

edited

remspoor commented Apr 8, 2018 •

edited

varjolintu commented Mar 27, 2019 •

edited

Cherkah commented Apr 29, 2019 •

edited

j1warren commented Oct 28, 2019 •

edited