[JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs
by Nick Sawadsky (Jira)
[ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.... ]
Nick Sawadsky edited comment on JGRP-2274 at 8/20/19 4:39 PM:
--------------------------------------------------------------
[~belaban] I'm afraid it's not the case. The decrypted message may be garbled, but it can still decrypt successfully, depending on the encryption algorithm.
Adding an additional INTEGRITY protocol is one possible option. Using an HMAC is preferred these days over a checksum. HMAC needs its own shared key, so this may be one reason to keep the signing as part of the encryption protocol (so it can reuse the same shared secret). It seems the best practice would be to derive two different keys (one for encryption and one for signing) from the same shared secret using a key derivation function. [This article|https://proandroiddev.com/security-best-practices-symmetric-encry...] has a good description of the steps.
Implementing HMAC is a bit complicated, which would be a reason to instead add support for GCM mode in Encrypt. This will require some changes as well I think, but the work would be quite a bit less. I think "mode" and "padding" would have to be added as configuration properties for the base Encrypt class. GCM also needs a unique initialization vector for each encrypted message. So Encrypt would need to be able to generate an initialization vector (with configurable length) per encrypted message. [This article|https://proandroiddev.com/security-best-practices-symmetric-encry...] describes how to go about implementing this type of encryption in Java.
ECB is seen as a somewhat less secure choice of mode these days anyway, so even if HMAC support were added, it still would be advisable to also add support for alternate encryption modes in Encrypt.
was (Author: nsawadsky):
[~belaban] I'm afraid not. The decrypted message may be garbled, but it can still decrypt successfully, depending on the encryption algorithm.
Adding an additional INTEGRITY protocol is one possible option. Using an HMAC is preferred these days over a checksum. HMAC needs its own shared key, so this may be one reason to keep the signing as part of the encryption protocol (so it can reuse the same shared secret). It seems the best practice would be to derive two different keys (one for encryption and one for signing) from the same shared secret using a key derivation function. [This article|https://proandroiddev.com/security-best-practices-symmetric-encry...] has a good description of the steps.
Implementing HMAC is a bit complicated, which would be a reason to instead add support for GCM mode in Encrypt. This will require some changes as well I think, but the work would be quite a bit less. I think "mode" and "padding" would have to be added as configuration properties for the base Encrypt class. GCM also needs a unique initialization vector for each encrypted message. So Encrypt would need to be able to generate an initialization vector (with configurable length) per encrypted message. [This article|https://proandroiddev.com/security-best-practices-symmetric-encry...] describes how to go about implementing this type of encryption in Java.
ECB is seen as a somewhat less secure choice of mode these days anyway, so even if HMAC support were added, it still would be advisable to also add support for alternate encryption modes in Encrypt.
> ASYM_ENCRYPT: deprecate sign_msgs
> ---------------------------------
>
> Key: JGRP-2274
> URL: https://issues.jboss.org/browse/JGRP-2274
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.12
>
>
> In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature.
> However, this is redundant, as decryption of a message will fail if the contents have been changed.
> If needed, signing of messages can be done in a separate protocol.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs
by Nick Sawadsky (Jira)
[ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.... ]
Nick Sawadsky commented on JGRP-2274:
-------------------------------------
[~belaban] I'm afraid not. The decrypted message may be garbled, but it can still decrypt successfully, depending on the encryption algorithm.
Adding an additional INTEGRITY protocol is one possible option. Using an HMAC is preferred these days over a checksum. HMAC needs its own shared key, so this may be one reason to keep the signing as part of the encryption protocol (so it can reuse the same shared secret). It seems the best practice would be to derive two different keys (one for encryption and one for signing) from the same shared secret using a key derivation function. [This article|https://proandroiddev.com/security-best-practices-symmetric-encry...] has a good description of the steps:
Implementing HMAC is a bit complicated, which would be a reason to instead add support for GCM mode in Encrypt. This will require some changes as well I think, but the work would be quite a bit less. I think "mode" and "padding" would have to be added as configuration properties for the base Encrypt class. GCM also needs a unique initialization vector for each encrypted message. So Encrypt would need to be able to generate an initialization vector (with configurable length) per encrypted message. [This article|https://proandroiddev.com/security-best-practices-symmetric-encry...] describes how to go about implementing this type of encryption in Java.
ECB is seen as a somewhat less secure choice of mode these days anyway, so even if HMAC support were added, it still would be advisable to also add support for alternate encryption modes in Encrypt.
> ASYM_ENCRYPT: deprecate sign_msgs
> ---------------------------------
>
> Key: JGRP-2274
> URL: https://issues.jboss.org/browse/JGRP-2274
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.12
>
>
> In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature.
> However, this is redundant, as decryption of a message will fail if the contents have been changed.
> If needed, signing of messages can be done in a separate protocol.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-2859) Treating all JAX-RS components as CDI Beans has some negative consequences
by Matt Drees (Jira)
[ https://issues.jboss.org/browse/WFLY-2859?page=com.atlassian.jira.plugin.... ]
Matt Drees commented on WFLY-2859:
----------------------------------
I think so, yes!
> Treating all JAX-RS components as CDI Beans has some negative consequences
> --------------------------------------------------------------------------
>
> Key: WFLY-2859
> URL: https://issues.jboss.org/browse/WFLY-2859
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, REST
> Affects Versions: 8.0.0.CR1, 16.0.0.Beta1
> Reporter: Matt Drees
> Assignee: Stuart Douglas
> Priority: Major
>
> It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans. This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class.
> See the forum link for a specific instance of this.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12317:
-----------------------------------------
[~bmaxwell] I'm answering your question in general, not specifically related to this particular item.
A reload stops and restarts an MSC service that nearly all services depend on. The idea is that by doing that stop, nearly all runtime state stored in the memory is cleared, e.g. object instances get garbage collected.
But not all state is held in instance fields of classes whose objects' have a lifecycle controlled by MSC services. In particular, some libraries store some state in static fields, presumably under an assumption that that state will only be written once per the lifetime of the JVM. If a library does that, and the subsystem authors know that, then they should write the subsystem such that trying to change a management attribute that ends up writing that state should result in the server going into restart-required, not reload-required.
For a bit more see "Applying Updates to Runtime Services" in https://docs.wildfly.org/17/Admin_Guide.html#Description_of_the_Managemen...
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Ondrej Chaloupka
> Priority: Critical
> Fix For: 18.0.0.Beta1
>
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # node-identifier of server1, 2 & 3 is set to 'vkcd', 'FdOu' and 'GocW' (ts.jbosstsX.node.identifier property)
> # server2 is started, node-identifier is set to txdifferentnodeid and server2 is stopped
> # server1 is started, node-identifier is set to txdifferentnodeid and server1 is reloaded
> # server3 is running
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move server1 object store directory to the server2
> # server2 is started
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> *When does the scenario pass*
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (old and new node-identifier on both servers are same)
> When step 3 slightly differs:
> When restart is performed instead of reload op.
> Server1 is reloaded. If it is restarted, node name is set correctly to txdifferentnodeid
> *tldr;*
> The problem is that server1 set TX node name to old value after node identifier is changed and server is reloaded. If the server is restarted, everything is OK.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFWIP-160:
-----------------------------------
Component/s: Web (Undertow)
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Flavia Rainone
> Priority: Blocker
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Configure and start server with TLSv1.3 and JDK 11:
> {code}
> connect
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (DROOLS-3953) DMN UX - overlay validation error reporting
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3953?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-3953:
-------------------------------------------
[~mmenestr][~karreiro] I've updated the click-thru with the changes we discussed:
* Using an alert inside the canvas node, and removing the badge from outside of it.
* Changed the canvas overlay from a tooltip to a popover.
* Changed the popover interaction from initiating on click to on hover.
Other than that: Made some adjustments to the messaging inside the dialog.
> DMN UX - overlay validation error reporting
> -------------------------------------------
>
> Key: DROOLS-3953
> URL: https://issues.jboss.org/browse/DROOLS-3953
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam, drools-tools
> Attachments: Error reporting after test run-different kinds.png, Error reporting after test run-different kinds2.png, Error reporting after test run-popup.png, Error reporting after test run-popup.png, Error reporting after test run.png, ut.png, ux-decision button.png, ux-decision table.png
>
>
> As user during DMN model editing, I want to see validation errors on the model in case of wrong FEEL expression or invalid decision table.
> I want to see this kind of errors in the decisions and at diagram level.
> * As a user I want to run a validation test within the DMN editor, using the Validate toolbar action, to be able to identify elements within the graph or grids that have errors, so that I can resolve the issues.
> * As a user when I save a file (and it is validated) I want to be informed if there are any validation errors, so that I'm aware that there are issues that need to be resolved.
> * As a user when I test a rule in the Scenario tool and any scenarios fail due to a syntax errors within DMN, I need to be able to easily identify the portions of the DMN file with errors so that I can fix them.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (DROOLS-4448) [Guided Rule] Local Date constraint is lost
by Toni Rikkola (Jira)
[ https://issues.jboss.org/browse/DROOLS-4448?page=com.atlassian.jira.plugi... ]
Toni Rikkola moved RHDM-1064 to DROOLS-4448:
--------------------------------------------
Project: Drools (was: Red Hat Decision Manager)
Key: DROOLS-4448 (was: RHDM-1064)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: Guided Rule Editor
(was: Decision Central)
Affects Version/s: (was: 7.4.0.GA)
QE Status: NEW
> [Guided Rule] Local Date constraint is lost
> -------------------------------------------
>
> Key: DROOLS-4448
> URL: https://issues.jboss.org/browse/DROOLS-4448
> Project: Drools
> Issue Type: Bug
> Components: Guided Rule Editor
> Reporter: Jozef Marko
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools
>
> User is unable to create guided rule with constraint over {LocalDate} field.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months