[Windows][Desktop App] KeyApp is not working behind a company proxy

[Binnette]

Keybase is not working behind a proxy. And there is no option in menu, to configure one.

Here the error message I have:

[lamg]

I have the same problem with the Linux version.

[berot3]

me too! :(

[dabura667]

There’s really nothing you can do except tell your admin to whitelist .keybase.io and .keybase.pub so you can see them.

[Binnette]

Sorry, but you are wrong. keybase.io and keybase.pub are not blacklisted by my company. :innocent:

The fact is that I need to configure manually the proxy for each application in order to make them use my company proxy.

KeyBase App can be improve by adding a "Add a proxy" in the preferences menu.

Here is an exemple with Firefox:

So we need something similar.

Else keybase can simply use global environnement variables such as "%HTTP_PROXY%". It can be very usefull, for people that must use a proxy to access to the Internet.

[birdjumper]

Can we have a fix for this please?

[zanderz]

Have you tried setting HTTP_PROXY, HTTPS_PROXY and NO_PROXY envirionment variables?

[jedd]

As per https://github.com/keybase/keybase-issues/issues/2482 evidently proxy fiddling through the OS layer (at least on MS Windows) doesn't resolve the problem.

I suspect this ticket is a duplicate of #2482 btw.

[aureq]

To add more information...

My environment:

• Windows 10 (Keybase Client)
• I have the variables http_proxy, https_proxy, HTTP_PROXY and HTTPS_PROXY set to http://somehostname:3128
• I control the local DNS cache
• I control the proxy

What I see so far is like this :

• I can register the device. This talks through api-0.core.keybaseapi.com:443 and the proxy sees the request. 👍
• I see other DNS requests like bserver-0.kbfs.keybaseapi.com, mdserver-1.kbfs.keybase.io, chat-0.core.keybaseapi.com but no request is made on the proxy. If I run on Windows netstat -an, I see a few connections in SYN_SENT 👎

I think part of the app leverages the proxy through the environment variables, but other components don't leverage that feature.

Keybase people, your product is great (and would even consider paying for it), so let me know if you need some debug assistance on this issue.

[espoelstra]

You can try setting a proxy in the config keybase config set proxy http://yourproxy:port though if it is resigning SSL traffic you might need to also trust the certificate of the proxy and put it into a file and add keybase config set proxy_ca_certs /path/to/trusted/certs.pem. There is definitely a large hole in coverage in Keybase around proxy support.

[ruppde]

Here's a workaround for people behind a coorporate proxy, it's totally easy and I use it since ~2 years: Use keybase mainly on your smartphone. And if you have to type a longer text, type it on the PC, email it to your phone and copy&paste it into the keybase app! It's fast since we have push mail (remember when you had to pull mails ...). It's secure because of SMTP-SSL and IMAP-SSL. Please close the issue ;)

[jedd]

Insecure manual workarounds notwithstanding, this is still a major adoption pain point in the corporate world.

Please do not close this issue except to merge it with https://github.com/keybase/keybase-issues/issues/2482 -- which is slightly older than this ticket (3y4m vs 2y3m)

[maxtaco]

@jedd, we put a bunch of proxy support this summer. Have you tried the settings in the settings menu? And if yes, what errors do you see?

[jedd]

@maxtaco Wow - you really have, sorry I missed this when it came up. I'm forced to use Windows laptops somewhat intermittently, and hadn't noticed the new options. I set up a new one this morning, works a treat - thank you! (I'm using a non-auth proxy for http and https out through a single port)

[ViperGeek]

@jedd, we put a bunch of proxy support this summer.

I can also confirm that SOCKS5 to 127.0.0.1:8080 using an SSH tunnel to an AWS VM works perfectly. Kudos!

- Dave

[aureq]

I'm still having one issue with proxy. When I access the Files section, Keybase doesn't make any use of the proxy. I still see sockets with SYN_SENT pointing to IP addresses that belong to Keybase. If I flush the firewall fromt its filtering rules that blocks traffic not directed to the proxy, then Keybase file transfer works fine.

Though, for general chat, it works really well.

[maxtaco]

@aureq we are surprised by this, can you try shutting down keybase and starting it back up again? What platform are you on?

[aureq]

@maxtaco I'm using Windows 10 (latest patch) and keybase (as installed yesterday).

I just closed Keybase and opened it again and when I go into "Files", there's a blue ribbon saying "You are offline". The firewall logs are like this

IPT: ALL=DROP: IN=eth0 OUT=inet0 MAC=00:c0:08:8f:c4:56:10:62:e5:ea:98:84:08:00 SRC=192.168.2.22 DST=52.1.32.236 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=5586 DF PROTO=TCP SPT=58830 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0 
IPT: ALL=DROP: IN=eth0 OUT=inet0 MAC=00:c0:08:8f:c4:56:10:62:e5:ea:98:84:08:00 SRC=192.168.2.22 DST=52.203.138.150 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=50417 DF PROTO=TCP SPT=58832 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0 
IPT: ALL=DROP: IN=eth0 OUT=inet0 MAC=00:c0:08:8f:c4:56:10:62:e5:ea:98:84:08:00 SRC=192.168.2.22 DST=52.203.138.150 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=50422 DF PROTO=TCP SPT=58832 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0 
IPT: ALL=DROP: IN=eth0 OUT=inet0 MAC=00:c0:08:8f:c4:56:10:62:e5:ea:98:84:08:00 SRC=192.168.2.22 DST=52.1.32.236 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=5593 DF PROTO=TCP SPT=58837 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0 
IPT: ALL=DROP: IN=eth0 OUT=inet0 MAC=00:c0:08:8f:c4:56:10:62:e5:ea:98:84:08:00 SRC=192.168.2.22 DST=52.1.32.236 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=5597 DF PROTO=TCP SPT=58839 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0

If I purge my firewall and remove all rules (so it becomes a simple packet forwader), then the offline message disappears within a second or two and file transfer is working as expected.

If I load my firewall rules, then Keybase shows again the offline message in the File section.

[maxtaco]

OK, thanks for the feedback. Pinging @songgao who knows more about this!

[songgao]

That blue offline banner is solely driven by connection status with the mdserver. So this seems to suggest we aren't respecting proxy settings somehow for connections to the mdserver. Will investigate.

[songgao]

@aureq are you using the HTTP proxy or SOCKS5?

[aureq]

@songgao I'm using an HTTP proxy (squid-cache).

What's the DNS named for the mdserver? I might be able to check if the IP addresses I'm seeing in my firewall match the DNS resolution for that name.

[songgao]

@aureq It eventually goes to elb-mdserver-1380743448.us-east-1.elb.amazonaws.com, which has multiple A records and you just get a random one. I tried to reproduce but couldn't on macOS -- all KBFS connections went through the proxy (both HTTP and SOCKS5). I think @mmou did some tests on Linux as well. But I'll try on Windows sometime.

[aureq]

@seojangho Looking at my DNS logs, I found that the top URL for the file share is mdserver-0.kbfs.keybase.io. It definitely resolves to the ELB hostname you mentioned above. I searched in my squid-cache logs, and couldn't find any connection attempts (CONNECT ...) to the host name mentioned above, nor the ELB host name or the associated IP addresses.

One last piece of information, my proxy does MitM, though, the CA is deployed system wide. It appears that Keybase for Windows fails to retain the Allow Interception in the UI. I can't tell if it respects the setting though. I temporarily disabled the MitM (to be extra sure) but it doesn't change anything. The Files section is shown as offline, and no visible attempts to connect to the mdserver via my proxy.

[Ewarren7]

Sadly the Allow TLS Interception does not retain value or work on windows client I just discovered. I get untrusted cert error when it tried to connect.

[aureq]

I agree with @Ewarren7. I noticed the same.

[taruti]

@aureq does the following help you:

Proxy support is implemented using golang's http library's built in support for proxies. This supports http connect based proxies and socks5 proxies. Proxies can be configured using: CLI flags, config.json, or environment variables. See keybase help advanced for information on using CLI flags. To configure a proxy using config.json run:

keybase config set proxy-type <"socks" or "http_connect">
keybase config set proxy <"localhost:8080" or "username:password@localhost:8080">

To configure a proxy using environment variables run:

export PROXY_TYPE=<"socks" or "http_connect">
export PROXY=<"localhost:8080" or "username:password@localhost:8080">

Internally, we support proxies by setting the Proxy field of http.Transport in order to use http's built in support for proxies. Note that http.Transport.Proxy does support socks5 proxies and basic auth.

By default, the client reaches out to api-0.core.keybaseapi.com which has a self-signed certificate. This is actually more secure than relying on the standard CA system since we pin the client to only accept this certificate. By pinning this certificate, we make it so that any proxies that MITM TLS cannot intercept the client's traffic since even though their certificate is "trusted" according to the CA system, it isn't trusted by the client. In order to disable SSL pinning and allow TLS MITMing proxies to function, it is possible to switch the client to trust the public CA system. This can be done in one of three ways:

keybase config set disable-ssl-pinning true
# OR
export DISABLE_SSL_PINNING="true"
# OR
keybase --disable-ssl-pinning

Note that enabling this option is NOT recommended. Enabling this option allows the proxy to view all traffic between the client and the Keybase servers.

[aureq]

@taruti

Thanks a lot for the follow up ! Here is my feedback on version 5.2.0-20200130015427+cf82db8320

Using keybase config set proxy-type and keybase config set proxy works really well. I used an unauthenticated HTTP proxy and my traffic appears to go through the proxy. Also, I'm now able to upload and delete files as you would normally expect.

On the advanced settings screen, I see the proxy details being set and displayed correctly. And the settings are retained across restarts.

I also used keybase config set disable-ssl-pinning true and I came across a few problems: 1 - The Advanced setting page doesn't display the correct flag value. As in, the checkbox All TLS interception is never checked regardless of the value.

2 - the CA certificate doesn't appear to be trusted by default by Debian 10 ca-certificates package. So, I tried to quickly download the certificate chain using openssl s_client -showcerts -servername chat-0.core.keybaseapi.com -connect chat-0.core.keybaseapi.com:443 but only the server certificate is returned, not the entire certificate chain. This is the CA that signed the certificate that fails verification Keybase KBFS CA prod. Maybe Keybase uses its own CA?

On that point, I understand that SSL interception is bad and I agree with this. The proxy in place does interception but also validates the certificate issuer accordingly using a local cert db as provided by ca-certificates package. That's why I haven't been able to test this thoroughly. If there's a way to download the CA certificate, I might be able to test this and provide feedback.

Finally, and quite minor... it's a bit unclear if Keybase should be closed when invoking keybase config .... The first time I tried I got the error message Only one instance of keybase GUI allowed, bailing!.

On my second attempt (after closing keybase), I go the message

Version: 5.2.0-20200130015427+cf82db8320
(electron) 'setAutoHideMenuBar function' is deprecated and will be removed. Please use 'autoHideMenuBar property' instead.

But there's no indication whether the flag/arguments were valid and taken into account or not. The way I tested everything above was to close keybase each time, and then running each config command one at a time.

[kvandermast]

@taruti, @aureq, we've been playing around with Keybase for the last days, and we stumbled on the same Corporate proxy problematic. When I apply the

keybase config set proxy-type <"socks" or "http_connect"> keybase config set proxy <"localhost:8080" or "username:password@localhost:8080">

I see that the loading works, but that the chat - which is the primary use for us - is still not able to connect. Could it be that the chat connection is not using the same proxy settings? WebSockets etc work (tested).

We're using it on a W7 laptop with the latest version of Keybase.

Thanks for any help. Cheers /kris

[aureq]

@kvandermast Yes, I have my proxy also set in the app.

Basically, the proxy you set from the GUI works fine with the chat feature and most of the app, except the file transfer (aka mdserver).

The proxy you set from the command line, allows the file transfer to work.

Could you please confirm this ?

[kvandermast]

@aureq, I'm afraid it is not working. I can for example lookup users in the "People" section, which shows that the proxy config is indeed working. Chat does not, I got a "API network error: doRetry failed, attempts: 1, timeout 5s, last err: context deadline exceeded".

FYI, version is 5.3.0-20200310141357

[Stean]

I can confirm that this issue also affects the macOS App.

[kg4zow]

@taruti @aureq and anybody else who finds this ...

The option is disable-cert-pinning, not disable-ssl-pinning.

The only place disable-ssl-pinning appears in the source code is in a comment, and this pull request will correct that comment. It looks like that was just a typo that nobody caught because it's in a comment.

On my machine (well, $DAYJOB's machine) which is stuck behind the over-zealous corporate firewall, I did this ...

keybase config set -b disable-cert-pinning true

... and after fully quitting and restarting Keybase, I was able to log in and make use of KBFS again. It wasn't nearly as fast as if the MITM attack wasn't happening, but it did eventually work.

[aureq]

Great to know @kg4zow Thank you for pointing out.