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
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
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice some kind of mechanism for issuing and keeping track of tokens would be way better than this http sig mess that’s basically the same as using self-signed tls certs
-
alice@gts.void.dogreplied to trwnh@mastodon.social last edited by
@trwnh yea but it seems a bit heavier. bc you have to keep track of tokens and i imagine there would be a lot more of those than statuses. practically speaking as someone who's worried for database server. of course you can cheat a little by making your tokens around a signed bit of a special little capability dsl but god all of that just to post jokes on the internet. and the key rolling oh
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice i mean if you wanna just post jokes on the internet i don't see what http sigs bring to the table either. just put them on one site and then relay/aggregate them across other sites. or use something like websub. most of fedi is just web browsers but shittier anyway