Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse

NodeBB

  1. Home
  2. General Discussion
  3. πŸ†• blog!

πŸ†• blog!

Scheduled Pinned Locked Moved General Discussion
activitybotactivitypubmastodonphp
63 Posts 35 Posters 203 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • edent@mastodon.socialE edent@mastodon.social

    I think the #RFC9421 HTTP Signature algorithm should be explicitly included in #Mastodon's requests.

    Feedback welcome - especially those explaining politely why I'm a wrong about this.

    https://github.com/mastodon/mastodon/issues/29905#issuecomment-5440336919

    fentiger@zotum.netF
    fentiger@zotum.netF
    fentiger@zotum.net
    wrote last edited by
    #54
    @Terence Eden If the verifier chooses which algorithm to use from this header, without double-checking it against the key, there's a chance it'll be vulnerable to an "algorithm confusion attack".

    Here's what that looks like in the case of JWTs; the same problem could happen with RFC9421.

    The safe way to work out which algorithm to use is to dereference the keyid and then choose the algorithm which matches the type of the returned key.
    edent@mastodon.socialE 1 Reply Last reply
    0
    • fentiger@zotum.netF fentiger@zotum.net
      @Terence Eden If the verifier chooses which algorithm to use from this header, without double-checking it against the key, there's a chance it'll be vulnerable to an "algorithm confusion attack".

      Here's what that looks like in the case of JWTs; the same problem could happen with RFC9421.

      The safe way to work out which algorithm to use is to dereference the keyid and then choose the algorithm which matches the type of the returned key.
      edent@mastodon.socialE
      edent@mastodon.socialE
      edent@mastodon.social
      wrote last edited by
      #55

      @fentiger I think that's where I'm getting confused.

      I'm getting the public key from the Mastodon user - but how do tell what algorithm the key itself uses?

      fentiger@zotum.netF 1 Reply Last reply
      0
      • edent@mastodon.socialE edent@mastodon.social

        @fentiger I think that's where I'm getting confused.

        I'm getting the public key from the Mastodon user - but how do tell what algorithm the key itself uses?

        fentiger@zotum.netF
        fentiger@zotum.netF
        fentiger@zotum.net
        wrote last edited by
        #56
        @Terence Eden You should be able to find out from your crypto library after you've decoded the key from PEM.

        (I don't think anyone uses anything other than RSA in the publicKeyPem field, but I'm not sure it's safe to assume that.)
        edent@mastodon.socialE 1 Reply Last reply
        0
        • fentiger@zotum.netF fentiger@zotum.net
          @Terence Eden You should be able to find out from your crypto library after you've decoded the key from PEM.

          (I don't think anyone uses anything other than RSA in the publicKeyPem field, but I'm not sure it's safe to assume that.)
          edent@mastodon.socialE
          edent@mastodon.socialE
          edent@mastodon.social
          wrote last edited by
          #57

          @fentiger
          If I decode the PEM, all I get is
          Type: RSA Public Key
          Key Size: 2048 bits

          Nothing to say which algorithm it uses.

          Feel free to tell me what incredibly obvious thing I'm missing πŸ˜…

          1 Reply Last reply
          0
          • edent@mastodon.socialE edent@mastodon.social

            I think the #RFC9421 HTTP Signature algorithm should be explicitly included in #Mastodon's requests.

            Feedback welcome - especially those explaining politely why I'm a wrong about this.

            https://github.com/mastodon/mastodon/issues/29905#issuecomment-5440336919

            edent@mastodon.socialE
            edent@mastodon.socialE
            edent@mastodon.social
            wrote last edited by
            #58

            Hey, #Mastodon and #ActivityPub developers.

            How much skew do you allow before rejecting a message?

            I've just received something where the header is signed:
            Mon, 31 Aug 2026 20:09:54 GMT

            But the ActivityPub message was published:
            Mon, 31 Aug 2026 19:58:36 GMT

            That's a little over 10 minutes. Is that too much? Should I not care as long as the signature validates?

            fazalmajid@vivaldi.netF evan@cosocial.caE m0yng@mastodon.radioM 3 Replies Last reply
            0
            • edent@mastodon.socialE edent@mastodon.social

              Hey, #Mastodon and #ActivityPub developers.

              How much skew do you allow before rejecting a message?

              I've just received something where the header is signed:
              Mon, 31 Aug 2026 20:09:54 GMT

              But the ActivityPub message was published:
              Mon, 31 Aug 2026 19:58:36 GMT

              That's a little over 10 minutes. Is that too much? Should I not care as long as the signature validates?

              fazalmajid@vivaldi.netF
              fazalmajid@vivaldi.netF
              fazalmajid@vivaldi.net
              wrote last edited by
              #59

              @Edent you'd be surprised how many servers don't have proper NTP sync enabled and can have system clocks off by *hours*.

              1 Reply Last reply
              0
              • edent@mastodon.socialE edent@mastodon.social

                Hey, #Mastodon and #ActivityPub developers.

                How much skew do you allow before rejecting a message?

                I've just received something where the header is signed:
                Mon, 31 Aug 2026 20:09:54 GMT

                But the ActivityPub message was published:
                Mon, 31 Aug 2026 19:58:36 GMT

                That's a little over 10 minutes. Is that too much? Should I not care as long as the signature validates?

                evan@cosocial.caE
                evan@cosocial.caE
                evan@cosocial.ca
                wrote last edited by
                #60

                @Edent activitypub.bot gives a tolerance of 5 minutes.

                https://github.com/evanp/activitypub-bot/blob/main/lib%2Fhttpsignatureauthenticator.js#L8

                edent@mastodon.socialE 1 Reply Last reply
                0
                • evan@cosocial.caE evan@cosocial.ca

                  @Edent activitypub.bot gives a tolerance of 5 minutes.

                  https://github.com/evanp/activitypub-bot/blob/main/lib%2Fhttpsignatureauthenticator.js#L8

                  edent@mastodon.socialE
                  edent@mastodon.socialE
                  edent@mastodon.social
                  wrote last edited by
                  #61

                  @evan Thanks - I had mine at two minutes.
                  I'm starting to see more exceeding 10 minutes.
                  I wonder what the actual risk is of accepting something with that long a delay?

                  evan@cosocial.caE 1 Reply Last reply
                  0
                  • edent@mastodon.socialE edent@mastodon.social

                    Hey, #Mastodon and #ActivityPub developers.

                    How much skew do you allow before rejecting a message?

                    I've just received something where the header is signed:
                    Mon, 31 Aug 2026 20:09:54 GMT

                    But the ActivityPub message was published:
                    Mon, 31 Aug 2026 19:58:36 GMT

                    That's a little over 10 minutes. Is that too much? Should I not care as long as the signature validates?

                    m0yng@mastodon.radioM
                    m0yng@mastodon.radioM
                    m0yng@mastodon.radio
                    wrote last edited by
                    #62

                    @Edent I've seen my Sidekiq queues get multiple minutes long on occasion, so it doesn't seem unreasonable.

                    1 Reply Last reply
                    0
                    • edent@mastodon.socialE edent@mastodon.social

                      @evan Thanks - I had mine at two minutes.
                      I'm starting to see more exceeding 10 minutes.
                      I wonder what the actual risk is of accepting something with that long a delay?

                      evan@cosocial.caE
                      evan@cosocial.caE
                      evan@cosocial.ca
                      wrote last edited by
                      #63

                      @Edent replay attacks, I'd guess.

                      1 Reply Last reply
                      0

                      Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                      Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                      With your input, this post could be even better πŸ’—

                      Register Login
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes


                      • Login

                      • Don't have an account? Register

                      • Login or register to search.
                      Powered by NodeBB Contributors
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • World
                      • Users
                      • Groups