You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
26 lines
1.0 KiB
26 lines
1.0 KiB
|
|
Some notes about security.
|
|
|
|
honk is not currently hardened against SSRF, server side request forgery. Be
|
|
mindful of what else may be reachable on localhost or the local network if
|
|
it's not generally accessible.
|
|
|
|
Key and signature verification is best effort, but some forgeries may sneak
|
|
past. In particular, tying together key name, key owner, actor, object, etc.
|
|
is incomplete.
|
|
|
|
How are user keys supposed to be rotated? Expired? Revoked?
|
|
|
|
The current answer is never, never, never.
|
|
|
|
If the key is only used for signing http requests, it can be be changed
|
|
basically at will. Change the key in the actor, give it a new name (to avoid
|
|
conflict with any cached keys), carry on.
|
|
|
|
Since keynames in practice don't change, honk will simply discard a key after
|
|
a signature failure and attempt to get a fresh key.
|
|
|
|
Using keys to sign json is more complicated. The current practice is to name
|
|
keys with URL fragments. example.com/user#key. If the keyname is changed to
|
|
#newkey, how does one fetch the old key to verify existing data?
|