[JBoss JIRA] (WFLY-6283) CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
by Harold Campbell (JIRA)
[ https://issues.jboss.org/browse/WFLY-6283?page=com.atlassian.jira.plugin.... ]
Harold Campbell commented on WFLY-6283:
---------------------------------------
I am actually able to recreate something very similar with your jar unchanged. Copy it into deployments, let it deploy, then delete it from deployments. When I do this I get:
22:11:35,225 ERROR [stderr] (ServerService Thread Pool -- 81) Exception in thread "ServerService Thread Pool -- 81" java.lang.IllegalStateException: ISPN000371: Cannot remove cache configuration 'local-query' because it is in use
22:11:35,225 ERROR [stderr] (ServerService Thread Pool -- 81) at org.infinispan.manager.DefaultCacheManager.undefineConfiguration(DefaultCacheManager.java:391)
22:11:35,225 ERROR [stderr] (ServerService Thread Pool -- 81) at org.jboss.as.clustering.infinispan.DefaultCacheContainer.undefineConfiguration(DefaultCacheContainer.java:90)
22:11:35,225 ERROR [stderr] (ServerService Thread Pool -- 81) at org.wildfly.clustering.infinispan.spi.service.ConfigurationBuilder.stop(ConfigurationBuilder.java:80)
22:11:35,225 ERROR [stderr] (ServerService Thread Pool -- 81) at org.wildfly.clustering.service.AsynchronousServiceBuilder$2.run(AsynchronousServiceBuilder.java:130)
22:11:35,225 ERROR [stderr] (ServerService Thread Pool -- 81) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
22:11:35,225 ERROR [stderr] (ServerService Thread Pool -- 81) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
22:11:35,226 ERROR [stderr] (ServerService Thread Pool -- 81) at java.lang.Thread.run(Thread.java:745)
22:11:35,226 ERROR [stderr] (ServerService Thread Pool -- 81) at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6283
> URL: https://issues.jboss.org/browse/WFLY-6283
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Harold Campbell
> Assignee: Scott Marlow
>
> With second level caching enabled in a persistence unit, my application can only be deployed once without restarting wildfly. Redeployment results in this stacktrace:
> 19:06:48,764 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 87) MSC000001: Failed to start service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": org.jboss.msc.service.StartException in service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:954)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:882)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
> ... 7 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> at org.infinispan.interceptors.InterceptorChain.assertNotAdded(InterceptorChain.java:76)
> at org.infinispan.interceptors.InterceptorChain.addInterceptor(InterceptorChain.java:90)
> at org.infinispan.cache.impl.CacheImpl.addInterceptor(CacheImpl.java:879)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.addInterceptor(AbstractDelegatingAdvancedCache.java:65)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:184)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:133)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.prepareForValidation(BaseTransactionalDataRegion.java:145)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.createAccessDelegate(BaseTransactionalDataRegion.java:130)
> at org.hibernate.cache.infinispan.naturalid.NaturalIdRegionImpl.buildAccessStrategy(NaturalIdRegionImpl.java:50)
> at org.hibernate.internal.SessionFactoryImpl.determineNaturalIdRegionAccessStrategy(SessionFactoryImpl.java:600)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:339)
> at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
> ... 9 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6283) CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6283?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6283:
------------------------------------
Thanks for the report Harold! A similar issue was raised in the forums [https://developer.jboss.org/message/951279] but no reproducing test given. I pushed a very simple test jar to [https://github.com/scottmarlow/2lc], in case that is helpful for hacking a test case together but I couldn't reproduce.
Could you provide a set of steps to reproduce and a standalone test case (e.g. jar file or source project)?
We have a potential fix ([https://hibernate.atlassian.net/browse/HHH-10545]) identified but really need a way to reproduce the failure.
If you cannot help us to reproduce the failure, I can explain how to build the Hibernate/WildFly changes so perhaps you could try the potential fix.
> CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6283
> URL: https://issues.jboss.org/browse/WFLY-6283
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Harold Campbell
> Assignee: Scott Marlow
>
> With second level caching enabled in a persistence unit, my application can only be deployed once without restarting wildfly. Redeployment results in this stacktrace:
> 19:06:48,764 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 87) MSC000001: Failed to start service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": org.jboss.msc.service.StartException in service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:954)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:882)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
> ... 7 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> at org.infinispan.interceptors.InterceptorChain.assertNotAdded(InterceptorChain.java:76)
> at org.infinispan.interceptors.InterceptorChain.addInterceptor(InterceptorChain.java:90)
> at org.infinispan.cache.impl.CacheImpl.addInterceptor(CacheImpl.java:879)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.addInterceptor(AbstractDelegatingAdvancedCache.java:65)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:184)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:133)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.prepareForValidation(BaseTransactionalDataRegion.java:145)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.createAccessDelegate(BaseTransactionalDataRegion.java:130)
> at org.hibernate.cache.infinispan.naturalid.NaturalIdRegionImpl.buildAccessStrategy(NaturalIdRegionImpl.java:50)
> at org.hibernate.internal.SessionFactoryImpl.determineNaturalIdRegionAccessStrategy(SessionFactoryImpl.java:600)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:339)
> at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
> ... 9 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6283) CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
by Harold Campbell (JIRA)
Harold Campbell created WFLY-6283:
-------------------------------------
Summary: CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
Key: WFLY-6283
URL: https://issues.jboss.org/browse/WFLY-6283
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 10.0.0.Final
Reporter: Harold Campbell
Assignee: Scott Marlow
With second level caching enabled in a persistence unit, my application can only be deployed once without restarting wildfly. Redeployment results in this stacktrace:
19:06:48,764 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 87) MSC000001: Failed to start service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": org.jboss.msc.service.StartException in service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:954)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:882)
at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
... 7 more
Caused by: org.infinispan.commons.CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
at org.infinispan.interceptors.InterceptorChain.assertNotAdded(InterceptorChain.java:76)
at org.infinispan.interceptors.InterceptorChain.addInterceptor(InterceptorChain.java:90)
at org.infinispan.cache.impl.CacheImpl.addInterceptor(CacheImpl.java:879)
at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.addInterceptor(AbstractDelegatingAdvancedCache.java:65)
at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:184)
at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:133)
at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.prepareForValidation(BaseTransactionalDataRegion.java:145)
at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.createAccessDelegate(BaseTransactionalDataRegion.java:130)
at org.hibernate.cache.infinispan.naturalid.NaturalIdRegionImpl.buildAccessStrategy(NaturalIdRegionImpl.java:50)
at org.hibernate.internal.SessionFactoryImpl.determineNaturalIdRegionAccessStrategy(SessionFactoryImpl.java:600)
at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:339)
at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
... 9 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (LOGMGR-124) Add marker support
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-124?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-124:
--------------------------------------
The problem is JUL doesn't have a {{Marker}} concept so it's something we'd have to add an API for. I honestly just see them as a bit fancier of a {{java.util.logging.Filter}}.
As far as logback support both jboss-logmanager and logback are really doing the same thing. I don't think it makes sense to have support for logback in the jboss-logmanager. Both of them are log managers. Logback has it's own API and jboss-logmanager just extends J.U.L.
> Add marker support
> ------------------
>
> Key: LOGMGR-124
> URL: https://issues.jboss.org/browse/LOGMGR-124
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Affects Versions: 2.0.2.Final
> Reporter: Rob Heine
> Priority: Optional
>
> The logging engine currently (talking about the one included in WF-9) does not support Markers (like in implementations like "logback" and/or "log4j2").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6210) Example ec2/gossip/azure server profiles do not have any modifications from the standard HA profiles (missing proper discovery protocols)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6210?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6210:
---------------------------------
Summary: Example ec2/gossip/azure server profiles do not have any modifications from the standard HA profiles (missing proper discovery protocols) (was: Example ec2/gossip server profiles do not have any modifications from the standard HA profiles (missing proper discovery protocols))
> Example ec2/gossip/azure server profiles do not have any modifications from the standard HA profiles (missing proper discovery protocols)
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6210
> URL: https://issues.jboss.org/browse/WFLY-6210
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 10.1.0.Final
>
>
> {noformat}
> [rhusar@syrah wildfly-10.1.0.Final-SNAPSHOT]$ diff -s standalone/configuration/standalone_xml_history/standalone-ha.initial.xml docs/examples/configs/standalone-ec2-ha.xml
> Files standalone/configuration/standalone_xml_history/standalone-ha.initial.xml and docs/examples/configs/standalone-ec2-ha.xml are identical
> {noformat}
> {noformat}
> [rhusar@syrah wildfly-10.1.0.Final-SNAPSHOT]$ diff -s standalone/configuration/standalone_xml_history/standalone-ha.initial.xml docs/examples/configs/standalone-gossip-ha.xml
> Files standalone/configuration/standalone_xml_history/standalone-ha.initial.xml and docs/examples/configs/standalone-gossip-ha.xml are identical
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (LOGMGR-124) Add marker support
by Robert Knotek (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-124?page=com.atlassian.jira.plugin... ]
Robert Knotek commented on LOGMGR-124:
--------------------------------------
And what about adding Marker into ExtLogRecord and not to extend MarkerIgnoringBase, implement all Marker related methods correctly and propagate Marker as deep as possible. And after writing custom handler similar to this https://gist.github.com/xiaodong-xie/219491e0b433f8bd451e support for logback will be possible and relatively cheap Also it will not be full support of logback but it might be enough.
> Add marker support
> ------------------
>
> Key: LOGMGR-124
> URL: https://issues.jboss.org/browse/LOGMGR-124
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Affects Versions: 2.0.2.Final
> Reporter: Rob Heine
> Priority: Optional
>
> The logging engine currently (talking about the one included in WF-9) does not support Markers (like in implementations like "logback" and/or "log4j2").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2021) Prevent messages from non-members
by Bela Ban (JIRA)
[ 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}})
* ALTERNATIVE:
** We encrypt a phrase with the secret key. Everyone who has the shared key will be able to decrypt it and thus pass a message up. Messages from a non-member would be dropped.
** Could the above also be done by the sender _signing_ a phrase with its private key and the receiver decrypting it with the sender's public key, to enforce non-repudiation?
** Hmm, this would be prone to replay attacks, so either the phrase would have to be changed every time, or the ENCRYT header would have to be encrypted as well ({{encrypt_entire_msg==true}}.
h3. Scenarios to test (ENCRYPTTest)
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 _captured 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}}
* R sends a new view consisting of the existing view plus R
* If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
h5. The rogue node installing a new secret key in all members (ENCRYPT)
* R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
* Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
h5. Non-member R sending a message encrypted with its own secret key
* Cluster members would receive that message and decrypt it with their own (different) shared key, leading to garbage in the payload
* The message would get delivered to the application but de-serialization would fail as the payload is garbage
** See ALTERNATIVE above to prevent cluster members from delivering messages from rogue members in the first place
h4. Properties
* Rogue non-member R
* Resending of captures (and unmodified) cluster messages by R: YES (however, those messages will get dropped by either {{NAKACK2}} or {{UNICAST3}} as duplicates)
* Capturing and resending of messages as _new messages_ by R (e.g. by incrementing the seqno): YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
* Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
* Cluster members receiving messages from R: YES, but applications will throw an exception trying to read the contents of the payload as it is encrypted, and decryption failed as the secret key was wrong.
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}})
* ALTERNATIVE:
** We encrypt a phrase with the secret key. Everyone who has the shared key will be able to decrypt it and thus pass a message up. Messages from a non-member would be dropped.
** Could the above also be done by the sender _signing_ a phrase with its private key and the receiver decrypting it with the sender's public key, to enforce non-repudiation?
** Hmm, this would be prone to replay attacks, so either the phrase would have to be changed every time, or the ENCRYT header would have to be encrypted as well ({{encrypt_entire_msg==true}}.
h3. Scenarios to test (ENCRYPTTest)
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 _captured 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}}
* R sends a new view consisting of the existing view plus R
* If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
h5. The rogue node installing a new secret key in all members (ENCRYPT)
* R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
* Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
h4. Properties
* Rogue non-member R
* Resending of captures (and unmodified) cluster messages by R: YES (however, those messages will get dropped by either {{NAKACK2}} or {{UNICAST3}} as duplicates)
* Capturing and resending of messages as _new messages_ by R (e.g. by incrementing the seqno): YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
* Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
* Cluster members receiving messages from R: YES, but applications will throw an exception trying to read the contents of the payload as it is encrypted, and decryption failed as the secret key was wrong.
> Prevent messages from non-members
> ---------------------------------
>
> Key: JGRP-2021
> URL: https://issues.jboss.org/browse/JGRP-2021
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> 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}})
> * ALTERNATIVE:
> ** We encrypt a phrase with the secret key. Everyone who has the shared key will be able to decrypt it and thus pass a message up. Messages from a non-member would be dropped.
> ** Could the above also be done by the sender _signing_ a phrase with its private key and the receiver decrypting it with the sender's public key, to enforce non-repudiation?
> ** Hmm, this would be prone to replay attacks, so either the phrase would have to be changed every time, or the ENCRYT header would have to be encrypted as well ({{encrypt_entire_msg==true}}.
> h3. Scenarios to test (ENCRYPTTest)
> 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 _captured 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}}
> * R sends a new view consisting of the existing view plus R
> * If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
> h5. The rogue node installing a new secret key in all members (ENCRYPT)
> * R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
> * Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
> h5. Non-member R sending a message encrypted with its own secret key
> * Cluster members would receive that message and decrypt it with their own (different) shared key, leading to garbage in the payload
> * The message would get delivered to the application but de-serialization would fail as the payload is garbage
> ** See ALTERNATIVE above to prevent cluster members from delivering messages from rogue members in the first place
> h4. Properties
> * Rogue non-member R
> * Resending of captures (and unmodified) cluster messages by R: YES (however, those messages will get dropped by either {{NAKACK2}} or {{UNICAST3}} as duplicates)
> * Capturing and resending of messages as _new messages_ by R (e.g. by incrementing the seqno): YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
> * Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
> * Cluster members receiving messages from R: YES, but applications will throw an exception trying to read the contents of the payload as it is encrypted, and decryption failed as the secret key was wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2021) Prevent messages from non-members
by Bela Ban (JIRA)
[ 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}})
* ALTERNATIVE:
** We encrypt a phrase with the secret key. Everyone who has the shared key will be able to decrypt it and thus pass a message up. Messages from a non-member would be dropped.
** Could the above also be done by the sender _signing_ a phrase with its private key and the receiver decrypting it with the sender's public key, to enforce non-repudiation?
** Hmm, this would be prone to replay attacks, so either the phrase would have to be changed every time, or the ENCRYT header would have to be encrypted as well ({{encrypt_entire_msg==true}}.
h3. Scenarios to test (ENCRYPTTest)
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 _captured 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}}
* R sends a new view consisting of the existing view plus R
* If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
h5. The rogue node installing a new secret key in all members (ENCRYPT)
* R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
* Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
h4. Properties
* Rogue non-member R
* Resending of captures (and unmodified) cluster messages by R: YES (however, those messages will get dropped by either {{NAKACK2}} or {{UNICAST3}} as duplicates)
* Capturing and resending of messages as _new messages_ by R (e.g. by incrementing the seqno): YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
* Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
* Cluster members receiving messages from R: YES, but applications will throw an exception trying to read the contents of the payload as it is encrypted, and decryption failed as the secret key was wrong.
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}})
* ALTERNATIVE:
** We encrypt a phrase with the secret key. Everyone who has the shared key will be able to decrypt it and thus pass a message up. Messages from a non-member would be dropped.
** Could the above also be done by the sender _signing_ a phrase with its private key and the receiver decrypting it with the sender's public key, to enforce non-repudiation?
** Hmm, this would be prone to replay attacks, so either the phrase would have to be changed every time, or the ENCRYT header would have to be encrypted as well ({{encrypt_entire_msg==true}}.
h3. Scenarios to test (ENCRYPTTest)
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}}
* R sends a new view consisting of the existing view plus R
* If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
h5. The rogue node installing a new secret key in all members (ENCRYPT)
* R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
* Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
h4. Properties
* Rogue non-member R
* Resending of captures (and unmodified) cluster messages by R: YES (however, those messages will get dropped by either {{NAKACK2}} or {{UNICAST3}} as duplicates)
* Capturing and resending of messages as _new messages_ by R (e.g. by incrementing the seqno): YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
* Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
* Cluster members receiving messages from R: YES, but applications will throw an exception trying to read the contents of the payload as it is encrypted, and decryption failed as the secret key was wrong.
> Prevent messages from non-members
> ---------------------------------
>
> Key: JGRP-2021
> URL: https://issues.jboss.org/browse/JGRP-2021
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> 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}})
> * ALTERNATIVE:
> ** We encrypt a phrase with the secret key. Everyone who has the shared key will be able to decrypt it and thus pass a message up. Messages from a non-member would be dropped.
> ** Could the above also be done by the sender _signing_ a phrase with its private key and the receiver decrypting it with the sender's public key, to enforce non-repudiation?
> ** Hmm, this would be prone to replay attacks, so either the phrase would have to be changed every time, or the ENCRYT header would have to be encrypted as well ({{encrypt_entire_msg==true}}.
> h3. Scenarios to test (ENCRYPTTest)
> 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 _captured 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}}
> * R sends a new view consisting of the existing view plus R
> * If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
> h5. The rogue node installing a new secret key in all members (ENCRYPT)
> * R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
> * Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
> h4. Properties
> * Rogue non-member R
> * Resending of captures (and unmodified) cluster messages by R: YES (however, those messages will get dropped by either {{NAKACK2}} or {{UNICAST3}} as duplicates)
> * Capturing and resending of messages as _new messages_ by R (e.g. by incrementing the seqno): YES if {{ENCRYPT.encrypt_entire_msg}} is false, NO if true
> * Reception of cluster messages by R: YES, but R won't be able to read the contents as the payload is encrypted
> * Cluster members receiving messages from R: YES, but applications will throw an exception trying to read the contents of the payload as it is encrypted, and decryption failed as the secret key was wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months