[jboss-jira] [JBoss JIRA] (JGRP-2021) Prevent messages from non-members

[ https://issues.jboss.org/browse/JGRP-2021?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2021: --------------------------- Description: Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks. For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to * Send messages to the cluster * Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address * Install a new view including itself * Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages h3. Goals 1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests) 2. Prevent a non-member from receiving any cluster messages The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}. h3. Proposed solution * Use ENCRYPT for encryption of the payload *and the headers* * Now _every message_ carries an encrypt header * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key) * When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key) ** If the message doesn't have an encrypt header, it will be dropped * For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g. ** Views and MergeViews: they are stored in the payload ({{GMS}}) ** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}}) h3. Scenarios to test h5. Catching a message from some member P, modifying it and re-sending it on behalf of P * A rogue member R could catch a message from P by simply joining the same multicast group and port * R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P * However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too *R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message h5. Installing a rogue view * This requires {{ENCRYPT}} to sit somewhere below {{GMS}} * TBD h5. The rogue node installing a new secret key in all members (ENCRYPT) was: Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks. For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to * Send messages to the cluster * Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address * Install a new view including itself * Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages h3. Goals 1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests) 2. Prevent a non-member from receiving any cluster messages The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}. h3. Proposed solution * Use ENCRYPT for encryption of the payload *and the headers* * Now _every message_ carries an encrypt header * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key) * When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key) ** If the message doesn't have an encrypt header, it will be dropped * For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g. ** Views and MergeViews: they are stored in the payload ({{GMS}}) ** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}}) h3. Scenarios h5. Catching a message from some member P, modifying it and re-sending it on behalf of P * A rogue member R could catch a message from P by simply joining the same multicast group and port * R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P * However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too *R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message h5. Installing a rogue view * This requires {{ENCRYPT}} to sit somewhere below {{GMS}} * TBD h5. The rogue node installing a new secret key in all members (ENCRYPT) -- This message was sent by Atlassian JIRA (v6.4.11#64026)