[
https://issues.apache.org/jira/browse/SLING-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790633#comment-13790633
]
Ian Boston commented on SLING-3154:
-----------------------------------
Changes committed with code coverage for the new code for the passing use cases.
Verified no impact on current implementation, as none of the existing tests
were touched.
All discovery bundles build and pass tests.
Will need to deploy so some live instances and configure to validate in the
wild.
This is a brief description
Uses HmacSHA256 with a derived key that lasts 4h for signatures.
Uses AES/CBC/PKCS5Padding with a 128 bit key and random 9 byte salt for
encryption if enabled.
Configuration is via the Config Component. To enable white listing is turned
off, a shared key is set and optionally, encryption and the signature key
lifetime is set.
Signature is performed by performing a HMAC on a SHA of the body, url and
direction message (request or response). The SHA is put in X-SlingTopologyHash
header, the HMAC is put in X-SlingTopologyTrust header.
Verifying the message can be trusted rebuilds checks that the HMAC of the SHA
is the same as in the request. No reference is made to the body of the request.
When extracting the body of the request or response the SHA is rebuilt and
checked against the body of the message (encrypted if the body was encrypted)
Encryption takes the String body, and encrypts into a json object with a single
key "payload" containing a JSONArray made up of the base64 encoded 10 byte
salt, the Cipher initialisation vector as base64 encoded bytes, and the
encrypted data.
Decryption uses the salt to generate the key and initialisation vector to
decrypt the data.
It is possible to replay the same identical message 2x.
It is not possible to replay a different message using an old hash/hmac
It is not possible to replay an empty message (eg DELETE, where the body is
null) on different urls.
Requests and responses do not share hash/hmac pairs and both directions are
secured.
I will leave the issue open in case there objections to this change from the
community or if testing turns up issues.
> Add Topology Message Verification to the Discovery service.
> -----------------------------------------------------------
>
> Key: SLING-3154
> URL: https://issues.apache.org/jira/browse/SLING-3154
> Project: Sling
> Issue Type: Improvement
> Components: General
> Affects Versions: Discovery Impl 1.0.0
> Reporter: Ian Boston
> Assignee: Ian Boston
> Fix For: Discovery Impl 1.0.2
>
>
> The discovery service provides support for whitelisting sources of topology
> information, but in a cluster where the topology this creates a
> re-configuration load of order M*(n*(n-1)) where n is the number of nodes in
> the topology and M is the number of changes. That load rises rapidly as the
> number of changes and/or nodes increases.
> To address this there are 2 proposals.
> 1. To provide an SPI exported from the Discovery Impl bundle that allows
> implementors to implement whitelisting based on the request. This will need
> to support creating the request and validating the request.
> 2. Embed functionality within the Discovery Impl bundle that supports
> validation and encryption of topology requests.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
