[jboss-jira] [JBoss JIRA] (JGRP-2273) ASYM_ENCRYPT: deprecate encrypt_entire_message
[
https://issues.jboss.org/browse/JGRP-2273?page=com.atlassian.jira.plugin....
]
Nick Sawadsky commented on JGRP-2273:
-------------------------------------
{quote}However, this is not an issue, as replayed messages will simply get dropped by the
retransmission layer (e.g. NAKACK2 or UNICAST3).{quote}
[~belaban] I'm trying to understand how replays are still prevented in the absence of
encrypt_entire_message. Supposing an attacker was trying to spoof messages from one node
to another. We can assume the attacker has access to the entire message history between
the two nodes, including the unencrypted headers generated by UNICAST3. Would it not be
possible for the attacker to replay one of the messages previously exchanged between the
two nodes, by using the same encrypted message payload, but choosing appropriate values
for the unencrypted UNICAST3 header?
ASYM_ENCRYPT: deprecate encrypt_entire_message
----------------------------------------------
Key: JGRP-2273
URL: https://issues.jboss.org/browse/JGRP-2273
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Major
Fix For: 4.1.3
In {{ASYM_ENCRYPT}}, {{encrypt_entire_message}} encrypts not only the payload, but also
metadata such as destination and sender's address, headers and flags.
The rationale was to prevent replay attacks. However, this is not an issue, as replayed
messages will simply get dropped by the retransmission layer (e.g. NAKACK2 or UNICAST3).
If people still want this feature, they can write a protocol _above_ {{ASYM_ENCRYPT}},
which serializes the entire message into the payload of a new message, and this would be
exactly the same as setting {{encrypt_entire_message}} to {{true}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)