mirror of https://gitlab.com/bashrc2/epicyon
Typo
parent
6892e07054
commit
46c5a29a4a
|
@ -123,7 +123,7 @@ When posts are subsequently sent from the following instance (server-to-server)
|
|||
|
||||
Subsequently **Bob** could change the stored capabilities for **Alice** in their database, giving the new object a different id. This could be sent back to **Alice**, perhaps as another **follow Accept** activity with attached capabilities. This could then change the way in which **Alice** can interact with **Bob**, for example by adding or removing the ability to like or reply to posts.
|
||||
|
||||
If **Eve** subsequently learns what the capabilities id is for **Alice** by somehow intercepting the traffic (eg. suppose she works for *Eveflare*) then she can't gain the capabilities of Alice due to the *scope* parameter against which the actors of incoming posts are checked. **Eve** could create a post pretending to be from Alice's domain, but the http signature check would fail due to her not having Alice's keys. The only scenario in which Eve might triumphy would be if she could also do DNS highjacking and if Bob isn't storing Alice's public key and looks it up repeatedly, or if Alice and Bob's instances are foolishly configured to perform *blind key rotation*.
|
||||
If **Eve** subsequently learns what the capabilities id is for **Alice** by somehow intercepting the traffic (eg. suppose she works for *Eveflare*) then she can't gain the capabilities of Alice due to the *scope* parameter against which the actors of incoming posts are checked. **Eve** could create a post pretending to be from Alice's domain, but the http signature check would fail due to her not having Alice's keys. The only scenario in which Eve might triumph would be if she could also do DNS highjacking and if Bob isn't storing Alice's public key and looks it up repeatedly, or if Alice and Bob's instances are foolishly configured to perform *blind key rotation*.
|
||||
|
||||
## Install
|
||||
|
||||
|
|
Loading…
Reference in New Issue