i wonder if there’s any prior art on breaking the same-origin assumption— like if there’s a way to signal that a URI subpath is being served by a different application than whichever server is handling requests for that hostname?
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
if someone puts a public key anywhere on trwnh.com and uses the private key to sign http requests then they could make it look like i’m making those requests. the application could actually be running on some other server outside of my control, on any number of different hostnames in reality.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
say domain.example/~alice points to an activitypub server with a single actor on it, domain.example/~alice/actor.json and then there’s a public key on domain.example/~alice/key.json
key.json claims to be owned by actor.json, and actor.json claims to have key.json
but these were all planted by the sysadmin mallory. mallory can puppet any arbitrary path on domain.example. the request looks like it came from ~alice and it could have in fact come from ~alice but ~alice is in fact mallory.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
in fact, mallory can do the same thing for any hostname pointed at any server under her control
the question is, how can you possibly detect this?
-
bengo@mastodon.socialreplied to trwnh@mastodon.social last edited by
@trwnh there is a whole dark rabbit hole https://www.w3.org/TR/UMP/
-
bengo@mastodon.socialreplied to trwnh@mastodon.social last edited by
@trwnh EXACTLY
You're starting to get why actor URIs should not only be https:// URIs and it's fun to work on ActivityPub + DIDs https://www.w3.org/TR/did-core/
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
WHOIS information can be private, so that’s not a solution
also a domain name can be owned by e.g. bob, but bob has pointed his domain at mallory’s service using a CNAME or A record (thereby giving mallory nefarious control over bob’s domain — bob.example can be used to serve actors and keys in the same way domain.example/~alice was used)
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
ip addresses aren’t a solution either. although they do tend to be longer-lived. so you could somewhat reasonably say that if you start with the assumption that domain.example is untrustworthy, then you ought to look up the current A record and block the associated IP address it points to. and make sure to recheck occasionally in case mallory switches the DNS records for domain.example to a new IP. this in effect “burns” any IP that mallory has access to
-
trwnh@mastodon.socialreplied to bengo@mastodon.social last edited by
@bengo the real question is how to establish proof of controllership of a did
did:web is subject to the same issues as https: uris. so basically you are deferring to the did method and its resolution method
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
picking a keyserver and trusting it seems like the only workable solution, or rather picking a keystore (which could be some ledger, possibly distributed but that comes with its own trust issues)
you are still in effect choosing to trust whoever runs the keyserver, but that’s better than choosing to trust every single domain or web origin to self-assert with a key not anchored to anything
“http sigs with a key fetched from a domain over http” is the security equivalent of a selfsigned TLS cert
-
alice@gts.void.dogreplied to trwnh@mastodon.social last edited by
@trwnh are u trying to solve the general case of phishing
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
this is why http sigs are fundamentally broken the way fedi uses them. it’s security theater. every actor typically has its own key, but in reality that key proves nothing because all the keys are controlled by the application which is controlled by the sysadmin. just like a self signed cert proves nothing.
it’s why signed fetch is so easily circumvented, because you can just stick a key on any domain you control and no one would be any wiser.
we need a root of trust for fedi
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice more or less trying to derive a security model for fedi from first principles
-
alice@gts.void.dogreplied to trwnh@mastodon.social last edited by
@trwnh the problem with those is that they're just another smaller theater
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice well yeah but at least when you yell “fire” then less people get hurt
-
alice@gts.void.dogreplied to trwnh@mastodon.social last edited by
@trwnh ive thought about the Central Registry solution to location and authentication a lot and tbh, i still prefer a more isolated fedi where ppl compare public keys out of band. if the cryptography involved was actually useful and e2e, that is, atm we have about none anyway. reinventing the PKI and its authorities doesnt feel worth the effort for all the flaws it still leaves us
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice passing around bearer/capability tokens out of band
-
alice@gts.void.dogreplied to trwnh@mastodon.social last edited by
@trwnh this is an invite link
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice an invite link is generally used to sign up for something, not to authorize requests (“you need a valid token to POST to my inbox or GET any of my posts”)
-
alice@gts.void.dogreplied to trwnh@mastodon.social last edited by
@trwnh i mean the typical invite link is basically a cap token that you share out of band, that will authorize one request (an account creation) and we should definitely use this already good idea in other ways. but im just not sure of exactly what you were hinting at there. generally i wish activitypub already had capabilities instead of http signatures yea