2019-01-21 16:54:57 +01:00
|
|
|
{- This file is part of Vervis.
|
|
|
|
-
|
|
|
|
- Written in 2019 by fr33domlover <fr33domlover@riseup.net>.
|
|
|
|
-
|
|
|
|
- ♡ Copying is an act of love. Please copy, reuse and share.
|
|
|
|
-
|
|
|
|
- The author(s) have dedicated all copyright and related and neighboring
|
|
|
|
- rights to this software to the public domain worldwide. This software is
|
|
|
|
- distributed without any warranty.
|
|
|
|
-
|
|
|
|
- You should have received a copy of the CC0 Public Domain Dedication along
|
|
|
|
- with this software. If not, see
|
|
|
|
- <http://creativecommons.org/publicdomain/zero/1.0/>.
|
|
|
|
-}
|
|
|
|
|
|
|
|
module Web.ActivityPub
|
|
|
|
( -- * Actor
|
|
|
|
--
|
|
|
|
-- ActivityPub actor document including a public key, with a 'FromJSON'
|
|
|
|
-- instance for fetching and a 'ToJSON' instance for publishing.
|
|
|
|
ActorType (..)
|
|
|
|
, Algorithm (..)
|
|
|
|
, PublicKey (..)
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
, PublicKeySet (..)
|
2019-01-21 16:54:57 +01:00
|
|
|
, Actor (..)
|
|
|
|
|
|
|
|
-- * Activity
|
2019-02-12 12:53:24 +01:00
|
|
|
, Note (..)
|
|
|
|
, Create (..)
|
2019-01-21 16:54:57 +01:00
|
|
|
, Activity (..)
|
|
|
|
|
|
|
|
-- * Utilities
|
2019-02-07 11:34:33 +01:00
|
|
|
, hActivityPubActor
|
2019-01-21 16:54:57 +01:00
|
|
|
, provideAP
|
|
|
|
, APGetError (..)
|
|
|
|
, httpGetAP
|
|
|
|
, httpPostAP
|
2019-02-06 03:48:23 +01:00
|
|
|
, Fetched (..)
|
When verifying HTTP sig with known shared key, verify actor lists the key
Previously, when verifying an HTTP signature and we fetched the key and
discovered it's shared, we'd fetch the actor and make sure it lists the key URI
in the `publicKey` field. But if we already knew the key, had it cached in our
DB, we wouldn't check the actor at all, despite not knowing whether it lists
the key.
With this patch, we now always GET the actor when the key is shared,
determining the actor URI from the `ActivityPub-Actor` request header, and we
verify that the actor lists the key URI. We do that regardless of whether or
not we have the key in the DB, although these two cases and handled in
different parts of the code right now (for a new key, it's in Web.ActivityPub
fetchKey; for a known key, it's in Vervis.Foundation httpVerifySig).
2019-02-18 10:20:13 +01:00
|
|
|
, keyListedByActor
|
2019-02-04 00:39:56 +01:00
|
|
|
, fetchKey
|
2019-01-21 16:54:57 +01:00
|
|
|
)
|
|
|
|
where
|
|
|
|
|
|
|
|
import Prelude
|
|
|
|
|
2019-02-04 00:39:56 +01:00
|
|
|
import Control.Applicative ((<|>), optional)
|
|
|
|
import Control.Exception (Exception, displayException, try)
|
2019-02-12 12:53:24 +01:00
|
|
|
import Control.Monad (unless, (<=<))
|
2019-01-21 16:54:57 +01:00
|
|
|
import Control.Monad.IO.Class
|
2019-02-04 00:39:56 +01:00
|
|
|
import Control.Monad.Trans.Except
|
2019-01-21 16:54:57 +01:00
|
|
|
import Control.Monad.Trans.Writer (Writer)
|
2019-02-04 00:39:56 +01:00
|
|
|
import Crypto.Error (CryptoFailable (..))
|
2019-01-21 16:54:57 +01:00
|
|
|
import Data.Aeson
|
|
|
|
import Data.Aeson.Types (Parser)
|
2019-02-04 11:07:25 +01:00
|
|
|
import Data.Bifunctor (bimap, first)
|
|
|
|
import Data.Bitraversable (bitraverse)
|
2019-01-21 16:54:57 +01:00
|
|
|
import Data.ByteString (ByteString)
|
2019-02-17 01:14:05 +01:00
|
|
|
import Data.Foldable (for_)
|
2019-01-21 16:54:57 +01:00
|
|
|
import Data.List.NonEmpty (NonEmpty)
|
|
|
|
import Data.PEM
|
|
|
|
import Data.Semigroup (Endo)
|
|
|
|
import Data.Text (Text)
|
|
|
|
import Data.Text.Encoding (encodeUtf8, decodeUtf8)
|
2019-02-05 05:05:44 +01:00
|
|
|
import Data.Time.Clock (UTCTime)
|
2019-01-21 16:54:57 +01:00
|
|
|
import Network.HTTP.Client
|
|
|
|
import Network.HTTP.Client.Conduit.ActivityPub (httpAPEither)
|
|
|
|
import Network.HTTP.Client.Signature (signRequest)
|
|
|
|
import Network.HTTP.Signature (KeyId, Signature)
|
|
|
|
import Network.HTTP.Simple (JSONException)
|
|
|
|
import Network.HTTP.Types.Header (HeaderName, hContentType)
|
|
|
|
import Network.URI
|
|
|
|
import Yesod.Core.Content (ContentType)
|
|
|
|
import Yesod.Core.Handler (ProvidedRep, provideRepType)
|
|
|
|
|
2019-02-04 00:39:56 +01:00
|
|
|
import qualified Crypto.PubKey.Ed25519 as E (PublicKey, publicKey)
|
2019-01-21 16:54:57 +01:00
|
|
|
import qualified Data.HashMap.Strict as M (lookup)
|
2019-02-06 03:48:23 +01:00
|
|
|
import qualified Data.Text as T (pack, unpack)
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
import qualified Data.Vector as V (fromList, toList)
|
2019-01-21 16:54:57 +01:00
|
|
|
|
2019-02-08 00:08:28 +01:00
|
|
|
import Network.FedURI
|
|
|
|
|
2019-02-03 12:01:36 +01:00
|
|
|
import Data.Aeson.Local
|
2019-01-21 16:54:57 +01:00
|
|
|
|
|
|
|
as2context :: Text
|
|
|
|
as2context = "https://www.w3.org/ns/activitystreams"
|
|
|
|
|
|
|
|
actorContext :: Value
|
|
|
|
actorContext = Array $ V.fromList
|
|
|
|
[ String as2context
|
|
|
|
, String "https://w3id.org/security/v1"
|
|
|
|
]
|
|
|
|
|
|
|
|
data ActorType = ActorTypePerson | ActorTypeOther Text
|
|
|
|
|
|
|
|
instance FromJSON ActorType where
|
|
|
|
parseJSON = withText "ActorType" $ \ t ->
|
|
|
|
pure $ case t of
|
|
|
|
"Person" -> ActorTypePerson
|
|
|
|
_ -> ActorTypeOther t
|
|
|
|
|
|
|
|
instance ToJSON ActorType where
|
|
|
|
toJSON = error "toJSON ActorType"
|
|
|
|
toEncoding at =
|
|
|
|
toEncoding $ case at of
|
|
|
|
ActorTypePerson -> "Person"
|
|
|
|
ActorTypeOther t -> t
|
|
|
|
|
|
|
|
data Algorithm = AlgorithmEd25519 | AlgorithmOther Text
|
|
|
|
|
|
|
|
instance FromJSON Algorithm where
|
|
|
|
parseJSON = withText "Algorithm" $ \ t ->
|
|
|
|
pure $ if t == frg <> "ed25519"
|
|
|
|
then AlgorithmEd25519
|
|
|
|
else AlgorithmOther t
|
|
|
|
|
|
|
|
instance ToJSON Algorithm where
|
|
|
|
toJSON = error "toJSON Algorithm"
|
|
|
|
toEncoding algo =
|
|
|
|
toEncoding $ case algo of
|
|
|
|
AlgorithmEd25519 -> frg <> "ed25519"
|
|
|
|
AlgorithmOther t -> t
|
|
|
|
|
|
|
|
data PublicKey = PublicKey
|
2019-02-08 00:08:28 +01:00
|
|
|
{ publicKeyId :: FedURI
|
2019-02-05 05:05:44 +01:00
|
|
|
, publicKeyExpires :: Maybe UTCTime
|
2019-02-08 00:08:28 +01:00
|
|
|
, publicKeyOwner :: FedURI
|
2019-02-05 05:05:44 +01:00
|
|
|
, publicKeyPem :: PEM
|
|
|
|
, publicKeyAlgo :: Maybe Algorithm
|
|
|
|
, publicKeyShared :: Bool
|
2019-01-21 16:54:57 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
instance FromJSON PublicKey where
|
2019-02-04 00:39:56 +01:00
|
|
|
parseJSON = withObject "PublicKey" $ \ o -> do
|
|
|
|
mtyp <- optional $ o .: "@type" <|> o .: "type"
|
|
|
|
case mtyp of
|
|
|
|
Nothing -> return ()
|
|
|
|
Just t ->
|
|
|
|
if t == ("Key" :: Text)
|
|
|
|
then return ()
|
|
|
|
else fail "PublicKey @type isn't Key"
|
2019-01-21 16:54:57 +01:00
|
|
|
PublicKey
|
2019-02-08 00:08:28 +01:00
|
|
|
<$> o .: "id"
|
2019-02-05 05:05:44 +01:00
|
|
|
<*> o .:? "expires"
|
2019-02-08 00:08:28 +01:00
|
|
|
<*> o .: "owner"
|
2019-01-21 16:54:57 +01:00
|
|
|
<*> (parsePEM =<< o .: "publicKeyPem")
|
|
|
|
<*> o .:? (frg <> "algorithm")
|
2019-02-03 12:12:18 +01:00
|
|
|
<*> o .:? (frg <> "shared") .!= False
|
2019-01-21 16:54:57 +01:00
|
|
|
where
|
|
|
|
parsePEM t =
|
|
|
|
case pemParseBS $ encodeUtf8 t of
|
|
|
|
Left e -> fail $ "PEM parsing failed: " ++ e
|
|
|
|
Right xs ->
|
|
|
|
case xs of
|
|
|
|
[] -> fail "Empty PEM"
|
|
|
|
[x] -> pure x
|
|
|
|
_ -> fail "Multiple PEM sections"
|
|
|
|
|
|
|
|
instance ToJSON PublicKey where
|
|
|
|
toJSON = error "toJSON PublicKey"
|
2019-02-05 05:05:44 +01:00
|
|
|
toEncoding (PublicKey id_ mexpires owner pem malgo shared) =
|
2019-01-21 16:54:57 +01:00
|
|
|
pairs
|
2019-02-08 00:08:28 +01:00
|
|
|
$ "id" .= id_
|
2019-02-05 05:05:44 +01:00
|
|
|
<> "expires" .=? mexpires
|
2019-02-08 00:08:28 +01:00
|
|
|
<> "owner" .= owner
|
2019-02-03 12:12:18 +01:00
|
|
|
<> "publicKeyPem" .= decodeUtf8 (pemWriteBS pem)
|
|
|
|
<> (frg <> "algorithm") .=? malgo
|
|
|
|
<> (frg <> "shared") .= shared
|
2019-01-21 16:54:57 +01:00
|
|
|
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
data PublicKeySet = PublicKeySet
|
2019-02-08 00:08:28 +01:00
|
|
|
{ publicKey1 :: Either FedURI PublicKey
|
|
|
|
, publicKey2 :: Maybe (Either FedURI PublicKey)
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
instance FromJSON PublicKeySet where
|
|
|
|
parseJSON v =
|
|
|
|
case v of
|
|
|
|
Array a ->
|
|
|
|
case V.toList a of
|
|
|
|
[] -> fail "No public keys"
|
|
|
|
[k1] -> PublicKeySet <$> parseKey k1 <*> pure Nothing
|
|
|
|
[k1, k2] -> PublicKeySet <$> parseKey k1 <*> (Just <$> parseKey k2)
|
|
|
|
_ -> fail "More than 2 public keys isn't supported"
|
|
|
|
_ -> PublicKeySet <$> parseKey v <*> pure Nothing
|
|
|
|
where
|
2019-02-08 00:08:28 +01:00
|
|
|
parseKey = fmap toEither . parseJSON
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
|
|
|
|
instance ToJSON PublicKeySet where
|
|
|
|
toJSON = error "toJSON PublicKeySet"
|
|
|
|
toEncoding (PublicKeySet k1 mk2) =
|
|
|
|
case mk2 of
|
|
|
|
Nothing -> toEncoding $ renderKey k1
|
|
|
|
Just k2 -> toEncodingList [renderKey k1, renderKey k2]
|
|
|
|
where
|
2019-02-08 00:08:28 +01:00
|
|
|
renderKey = fromEither
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
|
2019-01-21 16:54:57 +01:00
|
|
|
data Actor = Actor
|
2019-02-08 00:08:28 +01:00
|
|
|
{ actorId :: FedURI
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
, actorType :: ActorType
|
|
|
|
, actorUsername :: Text
|
2019-02-08 00:08:28 +01:00
|
|
|
, actorInbox :: FedURI
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
, actorPublicKeys :: PublicKeySet
|
2019-01-21 16:54:57 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
instance FromJSON Actor where
|
|
|
|
parseJSON = withObject "Actor" $ \ o ->
|
|
|
|
Actor
|
2019-02-08 00:08:28 +01:00
|
|
|
<$> o .: "id"
|
2019-01-21 16:54:57 +01:00
|
|
|
<*> o .: "type"
|
|
|
|
<*> o .: "preferredUsername"
|
2019-02-08 00:08:28 +01:00
|
|
|
<*> o .: "inbox"
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
<*> o .: "publicKey"
|
2019-01-21 16:54:57 +01:00
|
|
|
|
|
|
|
instance ToJSON Actor where
|
|
|
|
toJSON = error "toJSON Actor"
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
toEncoding (Actor id_ typ username inbox pkeys) =
|
2019-01-21 16:54:57 +01:00
|
|
|
pairs
|
|
|
|
$ "@context" .= actorContext
|
2019-02-08 00:08:28 +01:00
|
|
|
<> "id" .= id_
|
2019-01-21 16:54:57 +01:00
|
|
|
<> "type" .= typ
|
|
|
|
<> "preferredUsername" .= username
|
2019-02-08 00:08:28 +01:00
|
|
|
<> "inbox" .= inbox
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
<> "publicKey" .= pkeys
|
2019-01-21 16:54:57 +01:00
|
|
|
|
2019-02-12 12:53:24 +01:00
|
|
|
data Note = Note
|
|
|
|
{ noteId :: FedURI
|
|
|
|
, noteAttrib :: FedURI
|
|
|
|
, noteTo :: FedURI
|
|
|
|
, noteReplyTo :: Maybe FedURI
|
|
|
|
, noteContent :: Text
|
2019-01-21 16:54:57 +01:00
|
|
|
}
|
|
|
|
|
2019-02-12 12:53:24 +01:00
|
|
|
instance FromJSON Note where
|
|
|
|
parseJSON = withObject "Note" $ \ o -> do
|
|
|
|
typ <- o .: "type"
|
|
|
|
unless (typ == ("Note" :: Text)) $ fail "type isn't Note"
|
|
|
|
Note
|
|
|
|
<$> o .: "id"
|
|
|
|
<*> o .: "attributedTo"
|
|
|
|
<*> o .: "to"
|
|
|
|
<*> o .:? "inReplyTo"
|
|
|
|
<*> o .: "content"
|
|
|
|
|
|
|
|
instance ToJSON Note where
|
|
|
|
toJSON = error "toJSON Note"
|
|
|
|
toEncoding (Note id_ attrib to mreply content) =
|
|
|
|
pairs
|
|
|
|
$ "type" .= ("Note" :: Text)
|
|
|
|
<> "id" .= id_
|
|
|
|
<> "attributedTo" .= attrib
|
|
|
|
<> "to" .= to
|
|
|
|
<> "inReplyTo" .=? mreply
|
|
|
|
<> "content" .= content
|
|
|
|
|
|
|
|
data Create = Create
|
|
|
|
{ createId :: FedURI
|
|
|
|
, createTo :: FedURI
|
|
|
|
, createActor :: FedURI
|
|
|
|
, createObject :: Note
|
|
|
|
}
|
|
|
|
|
|
|
|
instance FromJSON Create where
|
|
|
|
parseJSON = withObject "Create" $ \ o -> do
|
|
|
|
typ <- o .: "type"
|
|
|
|
unless (typ == ("Create" :: Text)) $ fail "type isn't Create"
|
|
|
|
Create
|
|
|
|
<$> o .: "id"
|
|
|
|
<*> o .: "to"
|
|
|
|
<*> o .: "actor"
|
|
|
|
<*> o .: "object"
|
|
|
|
|
|
|
|
instance ToJSON Create where
|
|
|
|
toJSON = error "toJSON Create"
|
|
|
|
toEncoding (Create id_ to actor obj) =
|
|
|
|
pairs
|
|
|
|
$ "@context" .= as2context
|
|
|
|
<> "type" .= ("Create" :: Text)
|
|
|
|
<> "id" .= id_
|
|
|
|
<> "to" .= to
|
|
|
|
<> "actor" .= actor
|
|
|
|
<> "object" .= obj
|
|
|
|
|
|
|
|
data Activity = CreateActivity Create
|
|
|
|
|
2019-01-21 16:54:57 +01:00
|
|
|
instance FromJSON Activity where
|
|
|
|
parseJSON = withObject "Activity" $ \ o -> do
|
2019-02-12 12:53:24 +01:00
|
|
|
ctx <- o .: "@context"
|
|
|
|
if ctx == as2context
|
2019-01-21 16:54:57 +01:00
|
|
|
then return ()
|
|
|
|
else fail "@context isn't the AS2 context URI"
|
2019-02-12 12:53:24 +01:00
|
|
|
typ <- o .: "type"
|
|
|
|
let v = Object o
|
|
|
|
case typ of
|
|
|
|
"Create" -> CreateActivity <$> parseJSON v
|
|
|
|
_ -> fail $ "Unrecognized activity type: " ++ T.unpack typ
|
2019-01-21 16:54:57 +01:00
|
|
|
|
|
|
|
instance ToJSON Activity where
|
|
|
|
toJSON = error "toJSON Activity"
|
2019-02-12 12:53:24 +01:00
|
|
|
toEncoding (CreateActivity c) = toEncoding c
|
2019-01-21 16:54:57 +01:00
|
|
|
|
|
|
|
typeActivityStreams2 :: ContentType
|
|
|
|
typeActivityStreams2 = "application/activity+json"
|
|
|
|
|
|
|
|
typeActivityStreams2LD :: ContentType
|
|
|
|
typeActivityStreams2LD =
|
|
|
|
"application/ld+json; profile=\"https://www.w3.org/ns/activitystreams\""
|
|
|
|
|
2019-02-07 11:34:33 +01:00
|
|
|
hActivityPubActor :: HeaderName
|
|
|
|
hActivityPubActor = "ActivityPub-Actor"
|
|
|
|
|
2019-01-21 16:54:57 +01:00
|
|
|
provideAP :: (Monad m, ToJSON a) => a -> Writer (Endo [ProvidedRep m]) ()
|
|
|
|
provideAP v = do
|
|
|
|
let enc = toEncoding v
|
|
|
|
-- provideRepType typeActivityStreams2 $ return enc
|
|
|
|
provideRepType typeActivityStreams2LD $ return enc
|
|
|
|
|
|
|
|
data APGetError
|
|
|
|
= APGetErrorHTTP HttpException
|
|
|
|
| APGetErrorJSON JSONException
|
2019-01-21 23:24:09 +01:00
|
|
|
| APGetErrorContentType Text
|
2019-01-21 16:54:57 +01:00
|
|
|
deriving Show
|
|
|
|
|
|
|
|
instance Exception APGetError
|
|
|
|
|
|
|
|
-- | Perform an HTTP GET request to fetch an ActivityPub object.
|
|
|
|
--
|
|
|
|
-- * Verify the URI scheme is _https:_ and authority part is present
|
|
|
|
-- * Set _Accept_ request header
|
|
|
|
-- * Perform the GET request
|
|
|
|
-- * Verify the _Content-Type_ response header
|
|
|
|
-- * Parse the JSON response body
|
|
|
|
httpGetAP
|
|
|
|
:: (MonadIO m, FromJSON a)
|
|
|
|
=> Manager
|
2019-02-08 00:08:28 +01:00
|
|
|
-> FedURI
|
2019-01-21 16:54:57 +01:00
|
|
|
-> m (Either APGetError (Response a))
|
|
|
|
httpGetAP manager uri =
|
2019-02-08 00:08:28 +01:00
|
|
|
liftIO $
|
|
|
|
mkResult <$> try (httpAPEither manager =<< requestFromURI (toURI uri))
|
2019-01-21 16:54:57 +01:00
|
|
|
where
|
|
|
|
lookup' x = map snd . filter ((== x) . fst)
|
|
|
|
mkResult (Left e) = Left $ APGetErrorHTTP e
|
|
|
|
mkResult (Right r) =
|
|
|
|
case lookup' hContentType $ responseHeaders r of
|
|
|
|
[] -> Left $ APGetErrorContentType "No Content-Type"
|
|
|
|
[b] -> if b == typeActivityStreams2LD || b == typeActivityStreams2
|
|
|
|
then case responseBody r of
|
|
|
|
Left e -> Left $ APGetErrorJSON e
|
|
|
|
Right v -> Right $ v <$ r
|
2019-01-21 23:24:09 +01:00
|
|
|
else Left $ APGetErrorContentType $ "Non-AP Content-Type: " <> decodeUtf8 b
|
2019-01-21 16:54:57 +01:00
|
|
|
_ -> Left $ APGetErrorContentType "Multiple Content-Type"
|
|
|
|
|
|
|
|
-- | Perform an HTTP POST request to submit an ActivityPub object.
|
|
|
|
--
|
|
|
|
-- * Verify the URI scheme is _https:_ and authority part is present
|
|
|
|
-- * Set _Content-Type_ request header
|
2019-02-07 11:34:33 +01:00
|
|
|
-- * Set _ActivityPub-Actor_ request header
|
2019-01-21 16:54:57 +01:00
|
|
|
-- * Compute HTTP signature and add _Signature_ request header
|
|
|
|
-- * Perform the POST request
|
|
|
|
-- * Verify the response status is 2xx
|
|
|
|
httpPostAP
|
|
|
|
:: (MonadIO m, ToJSON a)
|
|
|
|
=> Manager
|
2019-02-08 00:08:28 +01:00
|
|
|
-> FedURI
|
2019-01-21 16:54:57 +01:00
|
|
|
-> NonEmpty HeaderName
|
|
|
|
-> (ByteString -> (KeyId, Signature))
|
2019-02-07 11:34:33 +01:00
|
|
|
-> Text
|
2019-01-21 16:54:57 +01:00
|
|
|
-> a
|
|
|
|
-> m (Either HttpException (Response ()))
|
2019-02-07 11:34:33 +01:00
|
|
|
httpPostAP manager uri headers sign uActor value =
|
2019-02-08 00:08:28 +01:00
|
|
|
liftIO $ try $ do
|
|
|
|
req <- requestFromURI $ toURI uri
|
|
|
|
let req' =
|
|
|
|
setRequestCheckStatus $
|
|
|
|
consHeader hContentType typeActivityStreams2LD $
|
|
|
|
consHeader hActivityPubActor (encodeUtf8 uActor) $
|
|
|
|
req { method = "POST"
|
|
|
|
, requestBody = RequestBodyLBS $ encode value
|
|
|
|
}
|
|
|
|
sign' b =
|
|
|
|
let (k, s) = sign b
|
|
|
|
in (Nothing, k, s)
|
|
|
|
req'' <- signRequest headers sign' Nothing req'
|
|
|
|
httpNoBody req'' manager
|
2019-01-21 16:54:57 +01:00
|
|
|
where
|
|
|
|
consHeader n b r = r { requestHeaders = (n, b) : requestHeaders r }
|
2019-02-04 00:39:56 +01:00
|
|
|
|
2019-02-06 03:48:23 +01:00
|
|
|
-- | Result of GETing the keyId URI and processing the JSON document.
|
|
|
|
data Fetched = Fetched
|
|
|
|
{ fetchedPublicKey :: E.PublicKey
|
|
|
|
-- ^ The Ed25519 public key corresponding to the URI we requested.
|
|
|
|
, fetchedKeyExpires :: Maybe UTCTime
|
|
|
|
-- ^ Optional expiration time declared for the key we received.
|
2019-02-08 00:08:28 +01:00
|
|
|
, fetchedActorId :: FedURI
|
2019-02-06 03:48:23 +01:00
|
|
|
-- ^ The @id URI of the actor for whom the key's signature applies.
|
2019-02-15 00:27:40 +01:00
|
|
|
, fetchedActorInbox :: FedURI
|
|
|
|
-- ^ The inbox URI of the actor for whom the key's signature applies.
|
2019-02-06 03:48:23 +01:00
|
|
|
, fetchedHost :: Text
|
|
|
|
-- ^ The domain name of the instance from which we got the key.
|
|
|
|
, fetchedKeyShared :: Bool
|
|
|
|
-- ^ Whether the key we received is shared. A shared key can sign
|
|
|
|
-- requests for any actor on the same instance, while a personal key is
|
|
|
|
-- only for one actor. Knowing whether the key is shared will allow us
|
|
|
|
-- when receiving more requests, whether to accept signatures made on
|
|
|
|
-- different actors, or allow only a single permanent actor for the key
|
|
|
|
-- we received.
|
|
|
|
}
|
|
|
|
|
When verifying HTTP sig with known shared key, verify actor lists the key
Previously, when verifying an HTTP signature and we fetched the key and
discovered it's shared, we'd fetch the actor and make sure it lists the key URI
in the `publicKey` field. But if we already knew the key, had it cached in our
DB, we wouldn't check the actor at all, despite not knowing whether it lists
the key.
With this patch, we now always GET the actor when the key is shared,
determining the actor URI from the `ActivityPub-Actor` request header, and we
verify that the actor lists the key URI. We do that regardless of whether or
not we have the key in the DB, although these two cases and handled in
different parts of the code right now (for a new key, it's in Web.ActivityPub
fetchKey; for a known key, it's in Vervis.Foundation httpVerifySig).
2019-02-18 10:20:13 +01:00
|
|
|
-- | Fetches the given actor and checks whether it lists the given key (as a
|
|
|
|
-- URI, not as an embedded object). If it does, returns 'Right' the fetched
|
|
|
|
-- actor. Otherwise, or if an error occurs during fetching, returns 'Left' an
|
|
|
|
-- error message.
|
|
|
|
keyListedByActor :: MonadIO m => Manager -> FedURI -> FedURI -> m (Either String Actor)
|
|
|
|
keyListedByActor manager uKey uActor = runExceptT $ do
|
|
|
|
let fetch :: (MonadIO m, FromJSON a) => FedURI -> ExceptT String m a
|
|
|
|
fetch u = ExceptT $ bimap displayException responseBody <$> httpGetAP manager u
|
|
|
|
actor <- fetch uActor
|
|
|
|
if keyUriListed uKey actor
|
|
|
|
then return actor
|
|
|
|
else throwE "Actor publicKey has no URI matching pkey @id"
|
|
|
|
where
|
|
|
|
keyUriListed uk a =
|
|
|
|
let PublicKeySet k1 mk2 = actorPublicKeys a
|
|
|
|
match (Left uri) = uri == uk
|
|
|
|
match (Right _) = False
|
|
|
|
in match k1 || maybe False match mk2
|
|
|
|
|
2019-02-04 00:39:56 +01:00
|
|
|
fetchKey
|
|
|
|
:: MonadIO m
|
|
|
|
=> Manager
|
|
|
|
-> Bool
|
2019-02-08 00:08:28 +01:00
|
|
|
-> Maybe FedURI
|
|
|
|
-> FedURI
|
2019-02-06 03:48:23 +01:00
|
|
|
-> m (Either String Fetched)
|
|
|
|
fetchKey manager sigAlgo muActor uKey = runExceptT $ do
|
2019-02-08 00:08:28 +01:00
|
|
|
let fetch :: (MonadIO m, FromJSON a) => FedURI -> ExceptT String m a
|
2019-02-04 00:39:56 +01:00
|
|
|
fetch u = ExceptT $ bimap displayException responseBody <$> httpGetAP manager u
|
2019-02-06 03:48:23 +01:00
|
|
|
obj <- fetch uKey
|
2019-02-20 08:40:25 +01:00
|
|
|
let inztance = f2i uKey
|
When verifying HTTP sig with known shared key, verify actor lists the key
Previously, when verifying an HTTP signature and we fetched the key and
discovered it's shared, we'd fetch the actor and make sure it lists the key URI
in the `publicKey` field. But if we already knew the key, had it cached in our
DB, we wouldn't check the actor at all, despite not knowing whether it lists
the key.
With this patch, we now always GET the actor when the key is shared,
determining the actor URI from the `ActivityPub-Actor` request header, and we
verify that the actor lists the key URI. We do that regardless of whether or
not we have the key in the DB, although these two cases and handled in
different parts of the code right now (for a new key, it's in Web.ActivityPub
fetchKey; for a known key, it's in Vervis.Foundation httpVerifySig).
2019-02-18 10:20:13 +01:00
|
|
|
(actor, pkey) <-
|
2019-02-04 00:39:56 +01:00
|
|
|
case obj of
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
Left' pkey -> do
|
2019-02-06 03:48:23 +01:00
|
|
|
if publicKeyId pkey == uKey
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
then return ()
|
|
|
|
else throwE "Public key's ID doesn't match the keyid URI"
|
2019-02-08 00:08:28 +01:00
|
|
|
if furiHost (publicKeyOwner pkey) == furiHost uKey
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
then return ()
|
2019-02-04 00:39:56 +01:00
|
|
|
else throwE "Actor and key on different domains, we reject"
|
2019-02-06 03:48:23 +01:00
|
|
|
uActor <-
|
|
|
|
if publicKeyShared pkey
|
|
|
|
then case muActor of
|
|
|
|
Nothing -> throwE "Key is shared but actor header not specified!"
|
|
|
|
Just u -> return u
|
2019-02-17 01:14:05 +01:00
|
|
|
else do
|
|
|
|
let owner = publicKeyOwner pkey
|
|
|
|
for_ muActor $ \ u ->
|
|
|
|
if owner == u
|
|
|
|
then return ()
|
|
|
|
else throwE "Key's owner doesn't match actor header"
|
|
|
|
return owner
|
When verifying HTTP sig with known shared key, verify actor lists the key
Previously, when verifying an HTTP signature and we fetched the key and
discovered it's shared, we'd fetch the actor and make sure it lists the key URI
in the `publicKey` field. But if we already knew the key, had it cached in our
DB, we wouldn't check the actor at all, despite not knowing whether it lists
the key.
With this patch, we now always GET the actor when the key is shared,
determining the actor URI from the `ActivityPub-Actor` request header, and we
verify that the actor lists the key URI. We do that regardless of whether or
not we have the key in the DB, although these two cases and handled in
different parts of the code right now (for a new key, it's in Web.ActivityPub
fetchKey; for a known key, it's in Vervis.Foundation httpVerifySig).
2019-02-18 10:20:13 +01:00
|
|
|
actor <- ExceptT $ keyListedByActor manager uKey uActor
|
|
|
|
return (actor, pkey)
|
2019-02-04 11:07:25 +01:00
|
|
|
Right' actor -> do
|
2019-02-08 00:08:28 +01:00
|
|
|
if actorId actor == uKey { furiFragment = "" }
|
2019-02-04 11:07:25 +01:00
|
|
|
then return ()
|
2019-02-04 00:39:56 +01:00
|
|
|
else throwE "Actor ID doesn't match the keyid URI we fetched"
|
2019-02-17 01:14:05 +01:00
|
|
|
for_ muActor $ \ u ->
|
|
|
|
if actorId actor == u
|
|
|
|
then return ()
|
|
|
|
else throwE "Key's owner doesn't match actor header"
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
let PublicKeySet k1 mk2 = actorPublicKeys actor
|
|
|
|
match (Left _) = Nothing
|
|
|
|
match (Right pk) =
|
2019-02-06 03:48:23 +01:00
|
|
|
if publicKeyId pk == uKey
|
Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.
By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:
1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
request signature, but fails because it can't fetch the key. It's the old
key and we discarded it already, replaced it with the new one
When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.
Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.
Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
|
|
|
then Just pk
|
|
|
|
else Nothing
|
|
|
|
case match k1 <|> (match =<< mk2) of
|
|
|
|
Nothing -> throwE "keyId resolved to actor which doesn't have a key object with that ID"
|
2019-02-06 03:48:23 +01:00
|
|
|
Just pk ->
|
|
|
|
if publicKeyShared pk
|
|
|
|
then throwE "Actor's publicKey is shared, but embedded in actor document! We allow shared keys only if they're in a separate document"
|
When verifying HTTP sig with known shared key, verify actor lists the key
Previously, when verifying an HTTP signature and we fetched the key and
discovered it's shared, we'd fetch the actor and make sure it lists the key URI
in the `publicKey` field. But if we already knew the key, had it cached in our
DB, we wouldn't check the actor at all, despite not knowing whether it lists
the key.
With this patch, we now always GET the actor when the key is shared,
determining the actor URI from the `ActivityPub-Actor` request header, and we
verify that the actor lists the key URI. We do that regardless of whether or
not we have the key in the DB, although these two cases and handled in
different parts of the code right now (for a new key, it's in Web.ActivityPub
fetchKey; for a known key, it's in Vervis.Foundation httpVerifySig).
2019-02-18 10:20:13 +01:00
|
|
|
else return (actor, pk)
|
2019-02-04 00:39:56 +01:00
|
|
|
ExceptT . pure $ do
|
When verifying HTTP sig with known shared key, verify actor lists the key
Previously, when verifying an HTTP signature and we fetched the key and
discovered it's shared, we'd fetch the actor and make sure it lists the key URI
in the `publicKey` field. But if we already knew the key, had it cached in our
DB, we wouldn't check the actor at all, despite not knowing whether it lists
the key.
With this patch, we now always GET the actor when the key is shared,
determining the actor URI from the `ActivityPub-Actor` request header, and we
verify that the actor lists the key URI. We do that regardless of whether or
not we have the key in the DB, although these two cases and handled in
different parts of the code right now (for a new key, it's in Web.ActivityPub
fetchKey; for a known key, it's in Vervis.Foundation httpVerifySig).
2019-02-18 10:20:13 +01:00
|
|
|
if publicKeyShared pkey
|
2019-02-20 08:40:25 +01:00
|
|
|
then if publicKeyOwner pkey == i2f inztance
|
2019-02-05 14:02:15 +01:00
|
|
|
then Right ()
|
|
|
|
else Left "Key is shared but its owner isn't the top-level instance URI"
|
|
|
|
else if publicKeyOwner pkey == actorId actor
|
|
|
|
then Right ()
|
|
|
|
else Left "Actor's publicKey's owner doesn't match the actor's ID"
|
2019-02-04 00:39:56 +01:00
|
|
|
case publicKeyAlgo pkey of
|
|
|
|
Nothing ->
|
|
|
|
Left $
|
|
|
|
if sigAlgo
|
|
|
|
then "Algo mismatch, Ed25519 in Sig but none in actor"
|
|
|
|
else "Algo not given in Sig nor actor"
|
|
|
|
Just algo ->
|
|
|
|
case algo of
|
|
|
|
AlgorithmEd25519 -> Right ()
|
|
|
|
AlgorithmOther _ ->
|
|
|
|
Left $
|
|
|
|
if sigAlgo
|
|
|
|
then "Algo mismatch, Ed25519 in Sig but unsupported algo in actor"
|
|
|
|
else "No algo in Sig, unsupported algo in actor"
|
|
|
|
case E.publicKey $ pemContent $ publicKeyPem pkey of
|
2019-02-06 03:48:23 +01:00
|
|
|
CryptoPassed k -> Right Fetched
|
|
|
|
{ fetchedPublicKey = k
|
|
|
|
, fetchedKeyExpires = publicKeyExpires pkey
|
|
|
|
, fetchedActorId = actorId actor
|
2019-02-15 00:27:40 +01:00
|
|
|
, fetchedActorInbox = actorInbox actor
|
2019-02-08 00:08:28 +01:00
|
|
|
, fetchedHost = furiHost uKey
|
When verifying HTTP sig with known shared key, verify actor lists the key
Previously, when verifying an HTTP signature and we fetched the key and
discovered it's shared, we'd fetch the actor and make sure it lists the key URI
in the `publicKey` field. But if we already knew the key, had it cached in our
DB, we wouldn't check the actor at all, despite not knowing whether it lists
the key.
With this patch, we now always GET the actor when the key is shared,
determining the actor URI from the `ActivityPub-Actor` request header, and we
verify that the actor lists the key URI. We do that regardless of whether or
not we have the key in the DB, although these two cases and handled in
different parts of the code right now (for a new key, it's in Web.ActivityPub
fetchKey; for a known key, it's in Vervis.Foundation httpVerifySig).
2019-02-18 10:20:13 +01:00
|
|
|
, fetchedKeyShared = publicKeyShared pkey
|
2019-02-06 03:48:23 +01:00
|
|
|
}
|
|
|
|
CryptoFailed _ -> Left "Parsing Ed25519 public key failed"
|