Corporate proxy

[elestedt]

Hi,

I am behind a corporate proxy which has to be used for DNS resolves as well as connecting. I'm getting

- ERROR API network error: Get https://api.keybase.io/_/api/1.0/user/lookup.json?fields=basics%2Cpublic_keys%2Cpictures&multi=1&username=<snip>: dial tcp: lookup api.keybase.io: getaddrinfow: No such host is known. (error 1601)

When I try to login. Directly after entering the username. I have set the proxy in config.json after reading #4071 , didn't help.

[jerodg]

Isn't working for me either

• Win7, used keybase config set proxy
• The proxy works fine for anything else I've had to configure.

I'm getting:

There was an error provisioning

Unknown error: API network error

[hargikas]

I have the same error.

[PedanXr]

Can replicate

[arcenik]

I have the same error, even when starting with --proxy.

I started like keybase with:

C:\Users\xx>keybase --proxy http://192.168.0.1:3128/ ctl start

And the process is started

C:\Users\xx\AppData\Local\Keybase\keybase.exe \ --debug \ --proxy http://192.168.0.1:3128/ \ --log-file C:\Users\xx\AppData\Local\Keybase\keybase.service.log \ service \ --chdir C:\Users\xx\AppData\Local\Keybase \ --auto-forked

And the debug log file show this

2018-07-27T10:43:54.986250+02:00 - [DEBU keybase config.go:230] 120 HelloIAm: 1 - {11404 command-line client [keybase --proxy http://172.31.254.75:3128/ ctl start] 2.3.0-20180710101247+64615d6258}

But the proxy setting is not effective and direct communication with 52.22.229.68:443 is observed (with wireshark).

The version:

C:\Users\xx>keybase version Client: 2.3.0-20180710101247+64615d6258 Service: 2.3.0-20180710101247+64615d6258

[irb]

I am having similar issues with keybase ignoring my proxy settings. I have polipo sitting in front of shadowsocks. This is on Arch Linux.

▶ ERROR API network error: Get https://api-0.core.keybaseapi.com/_/api/1.0/merkle/path.json?last=3223606&load_deleted=1&load_reset_chain=1&poll=10&sig_hints_low=5&uid=f79b6d10fc0d9cc329f47e2d27608919: x509: certificate signed by unknown authority (code 1601)

[arcenik]

Hello @irb,

your error seam to be different as it say «x509: certificate signed by unknown authority».

So it's likely that the keybase client is connecting to the proxy but does not accept the certficate of your proxy.

Could you confirm with tcpdump or wireshark if the keybase client if connecting or not to the proxy ?

Best regards.

[irb]

Pardon, it looked like proxy issues were all getting marked as dupes of this one. My fault.

openssl s_client gives me the same error (Verify return code: 21 (unable to verify the first certificate)); it seems that the CA cert for api-0.core.keybaseapi.com doesn't exist on this system. It does connect through my proxy/tunnel setup.

I'm not familiar enough with how that CA cert is bundled with the software on Arch Linux; it works on other installations. I'm still investigating but if the answer is obvious to those who know the software better, please add your insights.

This may be a dupe of https://github.com/keybase/keybase-issues/issues/2371

[Neo23x0]

The missing proxy support hinders the professional use and adoption of keybase - a lot.

[hargikas]

I think the error is that Corporate Proxies are not doing the Name Resolutions and using the normal DNS protocol.

[Neo23x0]

the error is that Corporate Proxies are doing 

No. The error is that the keybase client resolves names.

https://serverfault.com/questions/169816/how-dns-lookups-work-when-using-an-http-proxy-or-not-in-ie

[hargikas]

If DNS name resolution fails and there is a configured proxy:

the keybase client should connect to its configured proxy, and send a request of the form:

GET http://fulldomainname.example.com/something.htm HTTP/1.1

The proxy resolves that host name using its own DNS, connects to the target site, etc, etc

[elestedt]

If a proxy is configured it probably shouldn't even try to resolve the host on it's own, just directly go to the proxy... A local DNS system behind a corporate proxy has a tendency to not resolove at the best or in the worst case send you somewhere else.

[arcenik]

I don't agree. If a proxy is configured, is should be used.

The internal DNS can do the resolution but only some selected services can go through the firewall, the other must use the proxy.

On 9/11/2018 11:09 AM, Charalampos Gkikas wrote:

If DNS name resolution fails and there is a configured proxy:

the keybase client should connect to its configured proxy, and send a request of the form:

GET http://fulldomainname.example.com/something.htm HTTP/1.1

The proxy resolves that host name using its own DNS, connects to the target site, etc, etc

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/keybase/client/issues/4557#issuecomment-420203197, or mute the thread https://github.com/notifications/unsubscribe-auth/AB0UW9OqafPV6i0nRPTVwE4Hjdo5iX6oks5uZ32xgaJpZM4KQr5d.

[Nyamiou]

I'm also using Keybase with a corporate proxy using the "--proxy" parameter with "http://user:pwd@proxyhost:proxyport", and I'm also encountering this issue.

Piece of log (from keybase.service.log) :

2018-09-12T15:36:06.505100+02:00 - [DEBU keybase connection.go:488] 3230 (CONN gregor 17383df0) Connection: dialing transport 2018-09-12T15:36:06.506035+02:00 - [DEBU keybase connection.go:217] 3231 (CONNTSPT 1cec201e) Dialing chat-0.core.keybaseapi.com:443 2018-09-12T15:36:06.511119+02:00 - [WARN keybase connection.go:494] 3232 (CONN gregor 17383df0) Connection: error dialing transport: dial tcp: lookup chat-0.core.keybaseapi.com: no such host 2018-09-12T15:36:06.511119+02:00 - [DEBU keybase gregor.go:870] 3233 ++Chat: | PushHandler: should retry on connect, err dial tcp: lookup chat-0.core.keybaseapi.com: no such host 2018-09-12T15:36:06.511119+02:00 - [DEBU keybase gregor.go:827] 3234 ++Chat: | PushHandler: connect error dial tcp: lookup chat-0.core.keybaseapi.com: no such host, reconnect throttle duration: 2s 2018-09-12T15:36:06.516114+02:00 - [DEBU keybase gregor.go:1376] 3235 ++Chat: | PushHandler: isReachable: error: terminating connection: dial tcp: lookup chat-0.core.keybaseapi.com: no such host 2018-09-12T15:36:06.517105+02:00 - [DEBU keybase gregor.go:1395] 3236 ++Chat: | PushHandler: Reconnect: skipping reconnect, already disconnected

Is there any workarounds ?

[maxtaco]

@Nyamiou what sort of proxy are you behind, and does do MITM on TLS connections?

[Nyamiou]

@maxtaco The proxy has BasicAuth authentication, does not have a blocklist, does not block traffic over HTTPS and does not override SSL certificates. I like @hargikas think that the problem come from the fact that the DNS provided by DHCP is only good for resolving intranet hostnames and that DNS resolving for Internet hostnames is supposed to be done by the proxy but Keybase does seems to try and resolve the target hostname prior to initiating a connection and stop the connection attempt when this fail.

Signal Desktop does work on the same computer and we are using that for now, but we would like to try Keybase since it does seems to have nice features like GIT integration.

[maxtaco]

Thanks, this is helpful.

[maxtaco]

Does your proxy support Web sockets?

[Nyamiou]

I have no problem running this test: https://www.websocket.org/echo.html from my computer, so I guess the proxy supports it.

[hargikas]

This is exactly my problem as @Nyamiou describes. I can resolve only intranet names with DNS and all internet Name to IP resolving happens at the proxy.

Although my proxy is more restrictive than @Nyamiou and while my browser is capable for web-sockets, while trying to check the functionality with https://www.websocket.org/echo.html, I get the error:

ERROR: undefined

DISCONNECTED

[arcenik]

My case is a bit different, as I can resolve the names but can't connect without passing by the proxy.

$ telnet api-0.core.keybaseapi.com 443
Trying 52.22.229.68...
Trying 52.23.190.140...
telnet: Unable to connect to remote host: Connection refused

But using the proxy on port 3128

$ curl -vsk https://api-0.core.keybaseapi.com/
*   Trying myproxy...
* TCP_NODELAY set
* Connected to (nil) (myproxy) port 3128 (#0)
* Establish HTTP proxy tunnel to api-0.core.keybaseapi.com:443
> CONNECT api-0.core.keybaseapi.com:443 HTTP/1.1
> Host: api-0.core.keybaseapi.com:443
> User-Agent: curl/7.52.1
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied OK to CONNECT request
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=US; ST=NY; L=New York; O=Keybase, Inc.; OU=Hosting; CN=api-0.core.keybaseapi.com; emailAddress=certs@keybase.io
*  start date: Mar 26 19:02:32 2018 GMT
*  expire date: Mar 25 19:02:32 2022 GMT
*  issuer: C=US; ST=NY; L=New York; O=Keybase LLC; OU=Cert Authority; CN=keybase.io; emailAddress=ca@keybase.io
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: api-0.core.keybaseapi.com
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 13 Sep 2018 06:46:16 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 15753
< Connection: keep-alive
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block

The keybase service log show it try to connect directly, ignoring the --proxy parameter

2018-09-13T08:31:30.993261+02:00 - [DEBU keybase api.go:693] 06e - api.doRequestShared -> API network error: doRetry failed, attempts: 5, timeout 1m0s, last err: Get https://api-0.core.keybaseapi.com/_/api/1.0/key/fetch_per_user_key_secrets.json?device_id=8e4555aebc23f20704ff8f688eda7b18&generation=0: dial tcp 52.23.190.140:443: connectex: No connection could be made because the target machine actively refused it. [time=10.1678765s] [tags:API=c20HxzmCpD8O]

[espoelstra]

I haven't tested this on Windows (haven't actually used it for work in a couple years), but there is some wonkiness with Golang and certificate trust on OSX, and it might have similar goofiness on Windows (or the app just isn't honoring the proxy settings for all the components properly). See #14307 for a potential workaround for OSX and more details on the bug.

[vermi]

My case is a bit different, as I can resolve the names but can't connect without passing by the proxy.

Confirmed I am having the same issue as @arcenik -- I can resolve and connect to keybaseapi.com using cURL with my corporate proxy; however, Keybase app is trying to connect directly via IP.

[BobuSumisu]

Same issue as @Nyamiou. It looks like the problem is that the chat uses framed rpc? This isn't proxy-aware as it simply tries to open a TCP/TLS-connection directly to the IP.

Edit: Somewhat of a workaround in my case: If I start keybase and open chat before connecting to work VPN, the chat will continue to work after connecting to my work VPN (where I use proxies).

Guess this solution isn't worth much for people not able to directly connect to the internet first though...

[phillip-white-jarden]

This works for me on Linux:

#!/bin/bash

## Export http proxy's as ip's DNS lookup does not work
export http_proxy=http://ip:8080
export https_proxy=http://ip:8080

## Start keybase redirector
/usr/bin/keybase-redirector /keybase &

## Start keybase 
/usr/bin/keybase --use-default-log-file --debug service &

## Start keybase gui
/opt/keybase/Keybase &

Doesn't seem to do any DNS lookup, so add proxy via IP.

[mscox42]

This works for me on Linux:

#!/bin/bash

## Export http proxy's as ip's DNS lookup does not work
export http_proxy=http://ip:8080
export https_proxy=http://ip:8080

## Start keybase redirector
/usr/bin/keybase-redirector /keybase &

## Start keybase 
/usr/bin/keybase --use-default-log-file --debug service &

## Start keybase gui
/opt/keybase/Keybase &

Doesn't seem to do any DNS lookup, so add proxy via IP.

This gets me further. I can log in, but not all functionality is present. There are still a lot of things trying to do name resolution directly instead of using the proxy. I also have the proxy set in config.json.

[phillip-white-jarden]

Yes same with... needs some debugging