Authenticate RPC messages #68
Comments
sebschrader
added a commit
that referenced
this issue
Feb 5, 2018
Although Celery already includes an authenticating serializer, it is not very difficult to implement a serializer. The serializer included with Celery uses X.509 certificates and OpenSSL, which is flexible, but complex. This serializer uses a lightweight PKI scheme based on ed25519 and the well-regarded libsodium library. All that needs to be done, is to generate a secure random 32 byte sequence. The serializer has a single signing key and a list of trusted verification keys. Addresses #68
sebschrader
added a commit
that referenced
this issue
Aug 4, 2018
Although Celery already includes an authenticating serializer, it is not very difficult to implement a serializer. The serializer included with Celery uses X.509 certificates and OpenSSL, which is flexible, but complex. This serializer uses a lightweight PKI scheme based on ed25519 and the well-regarded libsodium library. All that needs to be done, is to generate a secure random 32 byte sequence. The serializer has a single signing key and a list of trusted verification keys. Addresses #68
sebschrader
added a commit
that referenced
this issue
Aug 5, 2018
Although Celery already includes an authenticating serializer, it is not very difficult to implement a serializer. The serializer included with Celery uses X.509 certificates and OpenSSL, which is flexible, but complex. This serializer uses a lightweight PKI scheme based on ed25519 and the well-regarded libsodium library. All that needs to be done, is to generate a secure random 32 byte sequence. The serializer has a single signing key and a list of trusted verification keys. Addresses #68
sebschrader
added a commit
that referenced
this issue
Sep 10, 2022
The former JSON document stream based encoding has various shortcomings.
The new encoding is more robust, because no ambiguity or tolerance with
regards to whitespace exists.
There are two variants: Binary and base64-encoded.
The signature now also covers all the metadata (except the signature
itself of course):
+-----------------------------+----+ <--+
| Signature (64 bytes) | |
| | H
+--------------------------------- + e <--+
| Signer (32 bytes) | a M
+--------------------------------- + d e
| Content Type (variable) | 00 | e s
+-----------------------------+----+ r s
| Content Encoding (variable) | 00 | | a
+-----------------------------+----+ <--+ g
| Payload (variable) | e
+----------------------------------+ <--+
With base64 encoding the header becomes:
+-----------------------------+----+
| Header (variable, base 64) | \n |
+--------------------------------- +
| Payload (variable) |
+----------------------------------+
Addresses #68
sebschrader
added a commit
that referenced
this issue
Sep 10, 2022
The former JSON document stream based encoding has various shortcomings.
The new encoding is more robust, because no ambiguity or tolerance with
regards to whitespace exists.
There are two variants: Binary and base64-encoded.
The signature now also covers all the metadata (except the signature
itself of course):
+-----------------------------+----+ <--+
| Signature (64 bytes) | |
| | H
+--------------------------------- + e <--+
| Signer (32 bytes) | a M
+--------------------------------- + d e
| Content Type (variable) | 00 | e s
+-----------------------------+----+ r s
| Content Encoding (variable) | 00 | | a
+-----------------------------+----+ <--+ g
| Payload (variable) | e
+----------------------------------+ <--+
With base64 encoding the header becomes:
+-----------------------------+----+
| Header (variable, base 64) | \n |
+--------------------------------- +
| Payload (variable) |
+----------------------------------+
Addresses #68
sebschrader
added a commit
that referenced
this issue
Sep 10, 2022
The former JSON document stream based encoding has various shortcomings.
The new encoding is more robust, because no ambiguity or tolerance with
regards to whitespace exists.
There are two variants: Binary and base64-encoded.
The signature now also covers all the metadata (except the signature
itself of course):
+-----------------------------+----+ <--+
| Signature (64 bytes) | |
| | H
+--------------------------------- + e <--+
| Signer (32 bytes) | a M
+--------------------------------- + d e
| Content Type (variable) | 00 | e s
+-----------------------------+----+ r s
| Content Encoding (variable) | 00 | | a
+-----------------------------+----+ <--+ g
| Payload (variable) | e
+----------------------------------+ <--+
With base64 encoding the header becomes:
+-----------------------------+----+
| Header (variable, base 64) | \n |
+--------------------------------- +
| Payload (variable) |
+----------------------------------+
Addresses #68
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
RPC messages obtained from the message queue by Celery should be authenticated, before they are executed by the agent.
Celery includes an
authtask serializer, which uses OpenSSL and X.509 certificates to sign an verify messages.The text was updated successfully, but these errors were encountered: