Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Keybase proof integration #10013

Closed
wants to merge 34 commits into
base: master
from

Conversation

Projects
None yet
8 participants
@xgess
Copy link

xgess commented Feb 11, 2019

Ref: keybase/keybase-issues#2948

Implement Keybase's parametrized proof integration.

  • add an api for Keybase to pull proofs that are hosted on mastodon
  • add a Sidekiq task to check Keybase for proof validity and update locally
  • add a new flow for creating and saving a Keybase proof. This process starts from Keybase, so it's a little tricky to test here.
  • add auto-population and better usability for the creation flow
  • add a little thing on the profile page when a remote proof (e.g. from Keybase) is active
  • add Mastodon avatar links to the payload for Keybase so they can be displayed over there
  • add configuration for Keybase at /.well-known/keybase-proof-config.json and a related initializer
  • add management of identity proofs in the user settings.
@Gargron
Copy link
Member

Gargron left a comment

Hello! Thank you for submitting this patch.

There are some code style/organization issues that I have highlighted. The patch also needs to be tried out...

Edit: This does not mean I expect you to personally address these issues. Just notes!

Show resolved Hide resolved config/initializers/external_proof_service.rb Outdated
Show resolved Hide resolved config/initializers/external_proof_service.rb Outdated
Show resolved Hide resolved config/initializers/external_proof_service.rb Outdated
Show resolved Hide resolved app/views/well_known/keybase_proof_config/show.json.ruby Outdated
Show resolved Hide resolved app/views/settings/identity_proofs/new.html.haml Outdated
Show resolved Hide resolved app/controllers/well_known/keybase_proof_config_controller.rb Outdated
Show resolved Hide resolved app/controllers/well_known/keybase_proof_config_controller.rb Outdated
Show resolved Hide resolved app/controllers/well_known/keybase_proof_config_controller.rb Outdated
Show resolved Hide resolved app/controllers/well_known/keybase_proof_config_controller.rb Outdated
Show resolved Hide resolved app/controllers/well_known/keybase_proof_config_controller.rb Outdated

@xgess xgess force-pushed the xgess:xgess/keybase-proofs branch 3 times, most recently from afabf43 to 36d4b4f Feb 15, 2019

@xgess

This comment has been minimized.

Copy link
Author

xgess commented Feb 19, 2019

@Gargron i think i replied to everything

@Gargron

This comment has been minimized.

Copy link
Member

Gargron commented Feb 19, 2019

Thank you

@xgess xgess force-pushed the xgess:xgess/keybase-proofs branch 2 times, most recently from 335c8ad to e49a251 Mar 1, 2019

@Gargron Gargron changed the title First Pass Add Keybase Proofs Add Keybase proof integration Mar 1, 2019

@Gargron

This comment has been minimized.

Copy link
Member

Gargron commented Mar 1, 2019

I'm going to summarize how this integration works from admin and end-user perspective, as far as I understand it, to allow people to leave feedback without reading the code.

From end-user perspective, if you are on Keybase, you can click "Prove your Mastodon identity", enter the instance address*, and it will send you to a page on your Mastodon instance with an "Authorize" button that will confirm the connection. From then on, both your Keybase account and your Mastodon account** will display a link to each other.

*) Currently the button is "Prove your Mastodon Social identity" and visible only to whitelisted Keybase users

**) Currently the link only appears on the public profile page. How/if the proofs are supposed to federate, is not yet entirely clear

From admin perspective (and this has been a major concern for me since the start), running a Mastodon server is not enough. To allow users to prove Keybase identities, you must yourself have a Keybase account, and your instance must first be whitelisted by the Keybase team.


This is, admittedly, both a lot of hassle for admins and a lot of new code. We already have link verification, i.e. confirming that two pages link to each other with correct markup (rel=me), independently of Keybase. I am not quite sure why Keybase could not simply use the same method, thus allowing two-way verification without much extra work and without any cryptography.

On the other hand, in keybase/keybase-issues#2948 more than 160 people expressed a desire for a Mastodon/Keybase integration.

Keybase had been a Patreon sponsor of Mastodon for 3 months, but when this PR was submitted, I returned all donated money back to them to keep money out of the equation. Still, this is a very hard call, so I would appreciate input from other contributors and users of the platform.

@matildepark

This comment has been minimized.

Copy link

matildepark commented Mar 1, 2019

I am not quite sure why Keybase could not simply use the same method, thus allowing two-way verification without much extra work and without any cryptography.

This is why I'm hesitant on this feature that would hardcode in ties to a centralised, private verification service. There are other ways of verifying identity that allow Keybase alternatives to participate, up to and including your own website.

@malgorithms

This comment has been minimized.

Copy link

malgorithms commented Mar 1, 2019

Keybase team member here. We'd love to see this integration, really because we have a lot of people expressing interest in it. There are shared values, as you can imagine, between the security/cryptography and decentralization crowds.

We also have 300,000 pretty serious users, most of whom are tech types, and most of whom are not yet on Mastodon. We'd like to promote Mastodon instances to them, as a better kind of social network. Twitter, Reddit, Github, etc., are all big players and we'd rather see a solution that allows anyone to create a community with public key crypto support.

A few clarifications:

  • A Mastodon admin who wants to support Keybase connections will not need to have a Keybase account. I think our beta doc suggests otherwise, but it really won't be necessary. Ultimately we just need to find the config file for the instance, declaring its rules. Early we asked for those to be keybase-signed to us, but email is fine for now, and we're talking about how to automate it.

  • The reason bidirection rel=me links do not work is that we want to announce keys and achieve auditable public key infrastructure for Mastodon users. Think of it this way: a presumption on our part is that Keybase servers cannot be trusted. That someday you'll have an oh shit moment and think "I REAAAALLY need to send an encrypted message that only @foo@instanceY can read. OFF THE RECORD." If the only connection is a link from mastodon username to a keybase username and vice versa, then that's not quite there. When you want to send that message, the Keybase server could give you whatever keys it wants that day, claiming that keybase username had reset their account. Just like crappy old PGP key servers can lie. So a hacker or malicious power taking over Keybase could trick you and intercept your message as a "man in the middle." But if the announcement on Mastodon itself is a signed statement then this is perfectly safe.

  • Further, a Keybase signed identity announcement is more than just posting a key. It's a link into a chain of key announcements and revocations, identity announcements, and revocations, etc. It's designed to protect people from problems that old key servers had, such as possibly lying about key revocations by omission.

There are a number of other advantages to this model for security, such as an auditable history of when the proofs were made, pinned to the bitcoin blockchain. That just won't be the case if all you've got is an input field on each website that can change without a signature.

to a centralised, private verification service.

I appreciate this point, however a subtle clarification: Keybase is guaranteed to be transparent. We can prevent a write to our database, just as a Mastodon instance could. But unlike a Mastodon instance, if a public announcement is in our database, it can be proven we're giving everyone in the world the same answer, and anyone could run a verifiable mirror.

As a final long-term strategy point. Decentralization projects NEED public key crypto more than anyone else. Admittedly, there is a chicken and an egg problem: someday you could have the perfect 100% decentralized app WITH cryptographic security, but we're nowhere near that right now, and each side kind of depends on the other.

We cryptography people support the idea of Mastodon, even though it isn't "secure" in ways we'd like (I assume there's private unencrypted data on your servers. It's certainly not E2E encrypted. The horror!) But decentralization is a goal in itself, and we love it. Similarly, Mastodon can benefit from Keybase, even if we're not as decentralized as you'd like. Either side getting too dogmatic will keep security from Mastodon users, and Mastodon-style federation from Keybase identities. This opportunity is great for both sides.

Single longest Github comment I've ever written!

@Serkan-devel

This comment has been minimized.

Copy link

Serkan-devel commented Mar 2, 2019

Decentralization projects NEED public key crypto more than anyone else.

But having it rely on something centralized and poprietary (considering the keybase backend) won't develop a healthy ecosystem on the fediverse.

Why not integrate whatsapp as well when we are on it?

@wiktor-k

This comment has been minimized.

Copy link
Contributor

wiktor-k commented Mar 2, 2019

Wow, a staggering amount of code for something that should be simple.

If bidirectional rel=me links are not enough why not have Keybase link to a public toot with signed statement that links back to Keybase (random example from Twitter)?

I get that the integration wants to make it easy for people to link accounts but wouldn't tooting a signed message do? That's what works for GitHub, HackerNews and other services Keybase supports.

Edit: I'll answer my own question as since writing it I've read the docs on proof integration. It seems that for certain high-profile sites (HN, Reddit, Facebook) Keybase provides dedicated proof creation/verification code (Keybase writes all the code, the target service doesn't need to do anything).

Mastodon on the other hand would, with this PR, re-use their generic proof integration endpoint, shifting the burden of implementation to Mastodon so that Keybase wouldn't have to many any changes to their code.

@malgorithms

This comment has been minimized.

Copy link

malgorithms commented Mar 3, 2019

@wiktor-k - your summary is a good one, although an added difference: a twitter integration has 2 problems:

  1. it's brittle, which is sort of what you were saying; if twitter changes something about its design, it may be hard to validate a tweet. By having simple API endpoints on a partner that formalize serving and posting the proofs in a dedicated place, there's no real chance of it breaking. A partner can visually decide to present the proofs however it wants on a profile, and it will still work. Mastodon instances can design their sites however they want and be more robust.

  2. faaaar more important, the twitter-style solution is inadequate because twitter does nothing to verify the claims on the twitter side, and such a claim could be a social engineering attack/lie. If I follow someone on Twitter, and they claim to be Keybase user X, then that's fine, I can of course go encrypt a message to Keybase user X. But consider this: if I see twitter a random user saying Verifying myself, I am keybase user wiktor1234 (some garbage code looking like a sig hash), that Twitter user might not in fact be keybase user wiktor1234, and I might send that twitter user a DM on twitter thinking I'm talking to you. Or, worse, trust a digital signature that I shouldn't have.

We have a special opportunity to fix this case with Mastodon and subsequent partners: if someone effectively announces a key on their Mastodon profile, it should be cryptographically checked that it is in fact their key. Otherwise all you get out of it is safety in one direction. Both of these should work:

  • start with a mastodon user know how to encrypt for them safely
  • start with a signature (or public key) and know which mastodon user it is

This allows digital signature verification and all kinds of other awesomeness.

@Gargron

This comment has been minimized.

Copy link
Member

Gargron commented Mar 3, 2019

Those are good points @malgorithms.

@wiktor-k

This comment has been minimized.

Copy link
Contributor

wiktor-k commented Mar 3, 2019

it's brittle, which is sort of what you were saying; if twitter changes something about its design, it may be hard to validate a tweet.

To be honest it's just a text so there is not much they can change. Additionally Mastodon implements content negotiation so curling any toot with Accept: application/json returns machine-readable version. No need to convert tweet HTML URLs into API calls (and no tokens necessary!)

But consider this: if I see twitter a random user saying Verifying myself, I am keybase user wiktor1234 (some garbage code looking like a sig hash), that Twitter user might not in fact be keybase user wiktor1234, and I might send that twitter user a DM on twitter thinking I'm talking to you. Or, worse, trust a digital signature that I shouldn't have.

I was under the impression that the Keybase browser extension does two-way validation of that claim...

We have a special opportunity to fix this case with Mastodon and subsequent partners: if someone effectively announces a key on their Mastodon profile, it should be cryptographically checked that it is in fact their key.

I'm not sure that this model works best with federated systems such as Mastodon. Even if this is cryptographically checked on mastodon.social any other instance admin can put Verifying myself, I am keybase user wiktor1234 (pretty keybase icon) and quickly turn it into a security theater (or an equivalent of Mastodon's "Verified" badge).

The only secure place to do this kind of validations is in Keybase browser extension or on keybase.io (that are already trusted by Keybase users). There is no way to know if a random instance admin is running this validation code there or just playing with a little bit of HTML.

As far as I understood the system would protect from malicious users but would assume all admins are good. But if the user was malicious they can spin up their own instance in the first place.

@Gargron

This comment has been minimized.

Copy link
Member

Gargron commented Mar 3, 2019

I'm not sure that this model works best with federated systems such as Mastodon.

The way we approach it you need to trust only your own admin... For example with link verification, we do not trust what the remote server claims, we re-run our own checks for remote accounts. Ideally it would be the same for these Keybase signatures. Re-verified on the receiving end.

@wiktor-k

This comment has been minimized.

Copy link
Contributor

wiktor-k commented Mar 3, 2019

Eugen, it's good that you bring link verification as I see this (Keybase and link verification) strikingly similar.

Link verification shows ✔️ and if you trust your local admin you know it's good, if one is browsing foreign instance it could be fake but one can click the link and see for themselves if the linkback is correct. This is simple.

The same applies to Keybase proofs, if one trusts their admin they don't need "cryptographically checked" proofs - a simple one will do. If a "Keybase badge" is hosted on a foreign instance then one can't trust it anyway so it doesn't matter if it's "cryptographically checked" or not. How would one verify Keybase proof on foreign instance? The same way as with link verification - by following the link and checking the link back.

@malgorithms

This comment has been minimized.

Copy link

malgorithms commented Mar 3, 2019

The same applies to Keybase proofs

hi Wiktor, I think this is where we disagree (let me convince you!), and I think the difference is why so many people are interested in getting these cryptographic proofs into Mastodon.

(And note we chose to prioritize working on Mastodon integration since it was getting requested the most, along with the fact that we believe in the idea.)

Remember, one goal here is that someone could fire up a Keybase app (which is open source) and make a request to both a Keybase and a mastodon instance, and know for sure it's getting absolutely the right keys for that mastodon user. If the only connection were usernames, there are some ways Keybase OR Mastodon could cheat. Sure, people might trust their admins enough to use an instance, but people want this because they don't trust anyone with their end-to-end encryption and/or signatures. If, instead of usernames, it's a cryptographically-signed message which both Keybase and the instance agree about, then (1) a bad actor would have to have bad data on both sides, and (2) more important, it would be discoverable and exportable (since the sig would have to exist in Keybase's merkle tree). Which means really not feasible at all to cheat, even for a moment!

But with just usernames, targeted lies are totally possible.

So, I think...if you sort of trust your admin, like enough to use their instance, but not for something private, then the Keybase solution is much better than just hosting something like a public key. Or a username-username connection.

As a last point - I'm just not seeing meaningful Mastodon connections outside of Mastodon, and I hope this could help. I think people will want profiles out there with some of their identities connected. I'd love to promote on Keybase that GitHub programmer X is also Mastodon @foo@bar and @foo2@bar2 and look, if you don't trust the website, the Keybase app is actually verifying all the crypto, etc.

Because the Keybase connections are all verifiable, someone running Keybase can feel very good about drawing transitive conclusions. I don't know of any formal way other than Keybase to get all this identity connection. That's just how Keybase will lead to Mastodon, but also, starting on the Mastodon side, even not running Keybase or worrying about the crypto, people will start being able to make these connections. I could look at you on instance X, follow the link to Keybase, and then follow the link from Keybase to GitHub, Reddit, or Twitter (assuming you want). Right now I don't know which of those services are doing the rel=me bidrectional thing (if not, how will you get them on a Mastodon profile?) , but with Keybase it doesn't matter. I think that's pretty cool.

Ok, thanks for listening!

@wiktor-k

This comment has been minimized.

Copy link
Contributor

wiktor-k commented Mar 3, 2019

Ok, thanks for listening!

No problem, and thanks for taking the time to explain. I really appreciate it.

For the record I'd like to see Keybase integration probably as much as everyone else. I'm just discussing the design issues that could, in my opinion, be improved.

But with just usernames, targeted lies are totally possible.

I get why you think plain two-way links are not enough. But two-way link + a signed toot, that Keybase would verify should be enough to satisfy your threat model. Keybase validates the toot, adds rel=me. That is used by Mastodon to display ✔️. You've got signed assertion and two-way link between profiles.

Mastodon already exposes API for sending statuses and modifying account metadata.

The only thing that implementing parametrized proofs gives is tighter integration with Keybase, for example Mastodon checking if someone didn't remove their Mastodon profile from Keybase and removing the backlink then or a better styling for Keybase proof. That is nice, the only minor issue I have with that is that it's overly specific to one service only. Styling and automanagement of backlinks is good but maybe it would be better to enhance link verification so that every other service could benefit.

My 2 cents, have a nice day! 👋

@xgess xgess force-pushed the xgess:xgess/keybase-proofs branch from e49a251 to 1119574 Mar 5, 2019

@edobry

This comment has been minimized.

Copy link

edobry commented Mar 15, 2019

@malgorithms excellent overview and explanations of what a public key crypto infrastructure can bring to the fediverse, thank you for sharing! I have a question, if you don't mind: do you see value in implementing this sort of integration abstractly enough to allow for crypto infrastructure other than Keybase? Say, if a competitor were to launch a service equivalent to yours, do you think it would be worthwhile to enable Mastodon users to integrate with their service as easily as with Keybase? if not, how come, and if so, how do we ensure this happens?

@malgorithms

This comment has been minimized.

Copy link

malgorithms commented Mar 15, 2019

good question @edobry . I'd be totally happy to see other services adopt a similar protocol. I might not call them "competitors" because Keybase does a lot of different things, not just identity connections. For example, we do encrypted filesystem, chat and team memberships. Meanwhile, we'd love to see an Ethereum dapp that also does identity right, so people can connect dapps to Mastodon. We're not really getting into that stuff at all. So the more the merrier.

I think the technical answer to your question is a good one. The team's assessment is this really could evolve as needed without (1) breaking Keybase<>Mastodon or (2) preventing other people from doing the same. There is some specific Keybase code in this PR, but it's pretty superficial; most details in the PR are either general or easily generalized.

As soon as someone like Keybase comes along and wants this, too, they'll have some small differences we haven't thought of yet in the user flow and protocol, and the higher level Keybase-specific code can get modified to be a bit more general and designed to accommodate those things we haven't thought of. That would lead to a next, much smaller PR for Mastodon to keep Keybase support and add the next set of partners. I would say trying to predict those generalizations right now might be tough and could bloat the PR with harder to follow code that no one uses and yet still isn't general enough.

tl;dr we'd love to see this Keybase<>Mastodon connection, and wouldn't feel the least bit threatened to see other Keybase-like services, should they come along. we'd be happy to help with the generalizations when that happens too.

Note I personally will be on vacation all next week, so I might not be the fastest to reply here...but other people on the team who've been working hard on this will be around.

@Gargron Gargron referenced this pull request Mar 17, 2019

Merged

Add Keybase integration #10297

@Gargron

This comment has been minimized.

Copy link
Member

Gargron commented Mar 17, 2019

I have taken over the integration of this feature and continued my own work on top of these commits in #10297. As such I am closing this PR.

@Gargron Gargron closed this Mar 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.