June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2084) FlowControl: receiver should replenish credits after message delivery, not before

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2084?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2084: -------------------------------- Hmm, there's a problem: in the old approach, 10 threads from P received at the same time would only set P's credits to max_credits *once*. With the proposed change, P's credits could be set to max 10 times, defeating the purpose of flow control! E.g.: * Thread 1 from P (P1) is received, decrements P credits and drops below min_credits. P1 is now delivered, while P's credits are below min_credits * Thread P2, P3, P4 are received: they all decrement P's credits see that they need to set P's credits to max * When P1-4 have delivered the message, they will all set P's credits to max_credits! > FlowControl: receiver should replenish credits after message delivery, not before > --------------------------------------------------------------------------------- > > Key: JGRP-2084 > URL: https://issues.jboss.org/browse/JGRP-2084 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.10, 4.0 > > > When a message from P of length LEN is received, the following algorithm is run: > * P's credits are decremented by LEN > * If this is less than min_credits: > ** Set P's credits to max_credits > ** Deliver the message > ** Send a REPLENISH message back to P > The problem here is that, if the deliver of the message blocks (e.g. because another sync RPC is invoked on the same thread), then other threads from P sending messages won't cause a REPLENISH message to be sent back to P. > SOLUTION: replenish P's credits only _after the message delivery_: > * P's credits are decremented by LEN > * If this is less than min_credits: > ** Deliver the message > ** Set P's credits to max_credits > ** Send a REPLENISH message back to P > Email from Dan: > {quote} > ... when a message is received that passes over the min_credits threshold, the credits for that sender are already adjusted to max_credits - so only this thread can send a REPLENISH message back. If this thread blocks in the application (e.g. it sends a message and it blocks to wait for credits), even though other threads successfully deliver other messages, FlowControl will not send a REPLENISH message. > So it only takes one delayed/dropped REPLENISH message to enter a vicious circle, where nodes keep not sending REPLENISH messages to each other. And credit requests can't really help here, because there are way too many concurrent requests, and credits are immediately exhausted. > ...I think the best solution would be to have the receiver increment credits only *after* the application handles the message. I don't think the receiver needs to do anything before > delivering the message, because the blocking happens on the sender side anyway. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6655) When creating JMS bridge management API should pass bridge name to JMS broker

by Tom Ross (JIRA)

[ https://issues.jboss.org/browse/WFLY-6655?page=com.atlassian.jira.plugin.... ] Tom Ross commented on WFLY-6655: -------------------------------- Let me check with EAP 6 and I'll let you know. > When creating JMS bridge management API should pass bridge name to JMS broker > ----------------------------------------------------------------------------- > > Key: WFLY-6655 > URL: https://issues.jboss.org/browse/WFLY-6655 > Project: WildFly > Issue Type: Bug > Components: JMS > Environment: JBoss EAP 7.0 > Reporter: Tom Ross > Assignee: Chen Maoqian > > In situations where there are multiple JMS bridges being created it woudl help if bridge name is logged in the server name. This helps with recognising which JMS bridge is having problems. > For this to work the JBoss messaging API layer has to pass bridge name to the JMS broker. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6655) When creating JMS bridge management API should pass bridge name to JMS broker

by Chen Maoqian (JIRA)

[ https://issues.jboss.org/browse/WFLY-6655?page=com.atlassian.jira.plugin.... ] Chen Maoqian commented on WFLY-6655: ------------------------------------ [~raggz] hi,Tom ,i have passed the bridge name to artemis broker and created a artemis issues . in the pr of artemis issue the log of jms bridge name have been added,i don't know whether it is enough .if not ,please tell me.Thanks. > When creating JMS bridge management API should pass bridge name to JMS broker > ----------------------------------------------------------------------------- > > Key: WFLY-6655 > URL: https://issues.jboss.org/browse/WFLY-6655 > Project: WildFly > Issue Type: Bug > Components: JMS > Environment: JBoss EAP 7.0 > Reporter: Tom Ross > Assignee: Chen Maoqian > > In situations where there are multiple JMS bridges being created it woudl help if bridge name is logged in the server name. This helps with recognising which JMS bridge is having problems. > For this to work the JBoss messaging API layer has to pass bridge name to the JMS broker. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2084) FlowControl: receiver should replenish credits after message delivery, not before

by Bela Ban (JIRA)

Bela Ban created JGRP-2084: ------------------------------ Summary: FlowControl: receiver should replenish credits after message delivery, not before Key: JGRP-2084 URL: https://issues.jboss.org/browse/JGRP-2084 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.10, 4.0 When a message from P of length LEN is received, the following algorithm is run: * P's credits are decremented by LEN * If this is less than min_credits: ** Set P's credits to max_credits ** Deliver the message ** Send a REPLENISH message back to P The problem here is that, if the deliver of the message blocks (e.g. because another sync RPC is invoked on the same thread), then other threads from P sending messages won't cause a REPLENISH message to be sent back to P. SOLUTION: replenish P's credits only _after the message delivery_: * P's credits are decremented by LEN * If this is less than min_credits: ** Deliver the message ** Set P's credits to max_credits ** Send a REPLENISH message back to P Email from Dan: {quote} ... when a message is received that passes over the min_credits threshold, the credits for that sender are already adjusted to max_credits - so only this thread can send a REPLENISH message back. If this thread blocks in the application (e.g. it sends a message and it blocks to wait for credits), even though other threads successfully deliver other messages, FlowControl will not send a REPLENISH message. So it only takes one delayed/dropped REPLENISH message to enter a vicious circle, where nodes keep not sending REPLENISH messages to each other. And credit requests can't really help here, because there are way too many concurrent requests, and credits are immediately exhausted. ...I think the best solution would be to have the receiver increment credits only *after* the application handles the message. I don't think the receiver needs to do anything before delivering the message, because the blocking happens on the sender side anyway. {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2021) ENCRYPT: 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: --------------------------- Security: (was: Red Hat Internal) > ENCRYPT: 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 I: > ** 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}}. > * ALTERNATIVE II: digital signature > ** The sender creates a hash from the message (digest) and encrypts the digest with its secret key, and ships it with the message > ** The receiver decrypts the digest, computes the digest from the message and drops the message if the digests don't match > ** The diff to the first alternative is that a receiver doesn't even need to deliver the message and stop at (failing) de-serialization. > ** Downside: additional work to be done and space used when sending the signature with every message > 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. > h4. Issues > * How do we handle (unicast) JOINs from non-members? > * Ditto for merge requests (unicasts) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2055) ENCRYPT/AUTH: backport JGRP-2021 to 3.6 branch

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2055?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2055: --------------------------- Security: (was: Red Hat Internal) > ENCRYPT/AUTH: backport JGRP-2021 to 3.6 branch > ---------------------------------------------- > > Key: JGRP-2055 > URL: https://issues.jboss.org/browse/JGRP-2055 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.10 > > > Backport of JGRP-2021 to the 3.6 branch. Plus security holes in AUTH and ENCRYPT. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6768) ServletResourceManager does not implement isResourceChangeListenerSupported correctly

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-6768: ------------------------------------ Summary: ServletResourceManager does not implement isResourceChangeListenerSupported correctly Key: WFLY-6768 URL: https://issues.jboss.org/browse/WFLY-6768 Project: WildFly Issue Type: Bug Reporter: Stuart Douglas Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6742) javax.servlet.http.Part.getSubmittedFileName() uses wrong encoding

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6742?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-6742: -------------------------------------- Can you provide a reproducer? How is the charset being set to UTF-8? > javax.servlet.http.Part.getSubmittedFileName() uses wrong encoding > ------------------------------------------------------------------ > > Key: WFLY-6742 > URL: https://issues.jboss.org/browse/WFLY-6742 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final, 10.0.0.Final > Environment: Ubuntu 16.04 LTS > oracle java > java version "1.8.0_91" > Java(TM) SE Runtime Environment (build 1.8.0_91-b14) > Wildfly 8.2.0.Final > Wildfly 10.0.0.Final > Reporter: Maxim Wirt > Assignee: Stuart Douglas > > Servlet 3.1 file upload feature implementation uses incorrect character set for decoding file names > request.getCharacterEncoding() returns "UTF-8", > System property file.encoding is set to UTF-8, but > javax.servlet.http.Part.getSubmittedFileName() returns file name encoded using Latin character set > all non-latin symbols in name of the file become unreadably characters. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6655) When creating JMS bridge management API should pass bridge name to JMS broker

by Chen Maoqian (JIRA)

[ https://issues.jboss.org/browse/WFLY-6655?page=com.atlassian.jira.plugin.... ] Chen Maoqian reassigned WFLY-6655: ---------------------------------- Assignee: Chen Maoqian (was: Jeff Mesnil) > When creating JMS bridge management API should pass bridge name to JMS broker > ----------------------------------------------------------------------------- > > Key: WFLY-6655 > URL: https://issues.jboss.org/browse/WFLY-6655 > Project: WildFly > Issue Type: Bug > Components: JMS > Environment: JBoss EAP 7.0 > Reporter: Tom Ross > Assignee: Chen Maoqian > > In situations where there are multiple JMS bridges being created it woudl help if bridge name is logged in the server name. This helps with recognising which JMS bridge is having problems. > For this to work the JBoss messaging API layer has to pass bridge name to the JMS broker. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1618) Management request handling cleanup

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1618: ---------------------------------------- Summary: Management request handling cleanup Key: WFCORE-1618 URL: https://issues.jboss.org/browse/WFCORE-1618 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 3.0.0.Alpha3 Clean up some of the code used in management request handling to try and reduce the complexity. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2016