search

keybase / client

Keybase Go Library, Client, Service, OS X, iOS, Android, Electron
BSD 3-Clause "New" or "Revised" License
8.89k stars 1.23k forks source link

Self-signed certificate used on api.keybase.io is blocked by some firewalls #6252

Open SachaD opened 7 years ago

SachaD commented 7 years ago

Hi there,

It looks like the self-signed cert used on api.keybase.io is blocked by some firewalls. This apprears to be a consequence of the firewall's inability to fully validate the certificate chain (unknown Root CA). Whitelisting *.keybase.io on the firewall, or using a VPN connection fixes the problem. Note: This issue is related to #6004.

My log id: cfb0941f74341b83589dec1c

karux commented 6 years ago

Does keybase provide a root cert or certificate validation signature that will enable my systems to trust *.keybase.io? whitelisting a domain (where domain resolution can be spoofed) is not an ideal solution

maxtaco commented 6 years ago

See here for our certs. Our thinking here is that we gain nothing from trusting the root CAs in addition to our source code, since the source code already determines the URLs.

karux commented 6 years ago

hi @maxtaco, I agree trusting root CA's is not ideal... however, as mentioned in a few bug reports, firewalls, proxy servers, and SSL inspectors need to trust the traffic. without associating a root (which could be your own), tooling identify HTTPS traffic that is not associated with any known trust chain. client processes emitting encrypted data from device endpoints throws alerts. Follow up security forensics is difficult when the server certificate is not traceable to a known fingerprint.. Thank you for sharing the entire cert via the code pointer.

maxtaco commented 6 years ago

If you set this environment variable when running your keybase "service":

KEYBASE_SERVER_URI=https://keybase.io

You'll be getting HTTPS connections signed by the same certs that the Web site uses, which does use the root CAs. (In other words, for macOS, you'll have to set this as a launchd environment variable).

This will get you half the way there, since our other servers don't have signatures by the root CAs (fmprpc+tls://chat-0.core.keybaseapi.com:443 and also mdserver-{0,1}.kbfs.keybaseapi.com:443 and bserver-{0,1}.kbfs.keybaseapi.com:443).

We can make a ticket to work on this. We'll have to change all of these URLs to point to alternate CNAMEs so that our Web front-ends can serve certs signed by the root CAs rather than our vendored CAs.

johnrengelman commented 6 years ago

Would it be possible to use LetsEncrypt to obtain valid trusted certificates for the keybaseapi.com domain?

maxtaco commented 6 years ago

It's not a question of cost, it's a question that TLS only allows us to set one CA for our cert, and it's only a security degradation to include one that we don't own the private key for.

maxtaco commented 6 years ago

As far as I know, though this could be outdated: https://stackoverflow.com/questions/6506068/can-a-ssl-certificate-be-signed-by-multiple-certificate-authorities