Re: [External] Re: Queries on Qpid setup
Hi Kirankumar, The AMQP and HTTP ports of Qpid Broker-J support TLS and plain TCP transports. In order to enable TLS on broker HTTP or/and AMQP ports Keystore configured object(s) needs to be configured. The keystore object should contain a private key and certificates (including intermediates if required). A number of Keystore types is supported on the broker: * FileKeyStore - in this type of Keystore a java keystore is used underneath to hold the private key and certificates * NonJavaKeyStore - used to configure private key and certificates directly in PEM or DER formats The Broker allows users to quickly create a self-signed certificate with a special type of Keystore called "AutoGeneratedSelfSigned" (with Oracle JDK or OpenJDK). The TLS protocols and TLS cipher suites can be customised (if required) using special context variables: * qpid.security.tls.protocolAllowList * qpid.security.tls.protocolDenyList * qpid.security.tls.cipherSuiteAllowList * qpid.security.tls.cipherSuiteDenyList or * qpid.security.tls.protocolWhiteList * qpid.security.tls.protocolBlackList * qpid.security.tls.cipherSuiteWhiteList * qpid.security.tls.cipherSuiteBlackList Before 7.1.9 only "white/black" list terminology was supported. Starting from version 7.1.9 the alternative names "allow/deny" lists can be used. In version 9.0 the "allow/deny" lists completely replace "white/black" list terminology. For example, you can allow only TLSv1.3 with JDK11 by setting context variable qpid.security.tls.protocolAllowList to "TLSv1.3". You can specify the allowed or denied values using regular expressions represented as JSON stringified lists. For example, you can limit allowed cipher suites to only some of them by setting qpid.security.tls.cipherSuiteAllowList to "[\"(TLS|SSL)_AES_128_GSM_SHA256\",\"TLS|SSL)_AES_256_GSM_SHA384\",\"TLS|SSL)_ECDHE_ECDSA_WITH_AES_256_GSM_SHA384\"]". The same applies to deny lists. The context variable can be set in multiple ways: * as JVM settings * as command line arguments (for example, ./bin/qpid-server -prop qpid.security.tls.protocolAllowList=TLSv1.3 ) * in a properties file system.properties (it needs to be in broker classpath) * as configured object context variables (for example, context variable set on the Broker object using REST API) The Qpid Broker HA is based on Oracle BDB JE. Unfortunately the BDB JE does not support TLS transport. The data replication is unencrypted. Potentially, you can use SSH tunnels, but that requires configuring tunes between each of HA nodes, as the nodes communicate with each other. I believe that it should be possible to configure SSH tunnels, though I cannot give you any useful advice on how to do that. You can download Qpid Broker distribution files from Qpid Download page at http://qpid.apache.org/download.html . KInd Regards, Alex On Fri, 6 Nov 2020 at 04:50, Malyala, Kirankumar wrote: > Hi Alex, > > We are using broker-j (for java). As of now, we are exploring on version 7. > Please do let us know if you want any other information. > > Regards, > Kirankumar Malyala > > -Original Message- > From: Oleksandr Rudyy > Sent: Friday, November 6, 2020 5:44 AM > To: users@qpid.apache.org > Subject: [External] Re: Queries on Qpid setup > > This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with > links and attachments. > > Hi Kirankumar, > Could you please clarify what exactly Qpid broker are you trying to use? > There are two brokers in Qpid project: c++ broker and broker-j (for java). > > Are you using Qpid Broker-J? > > Kind regards, > Alex > > On Thu, 5 Nov 2020 at 08:05, Malyala, Kirankumar > wrote: > > > Hi Team, > > > > We have been doing some POC on Qpid. While working on the > > configuration, we came across multiple blockers which we have mentioned > below. > > > > > > * How to use a specific version of TLS encryption for Qpid if we > > deploy on VM. > > * We understood from the Qpid documentation that we have to deploy > > broker on multiple VM's to create a group and introduce master/replica > > nodes. Any SOP on this part ? > > * How to apply SSL/TLS encryption to replicas in the group consists > of > > master and replica nodes using SSH tunnel/IPsec. > > * How can we fetch file in Apache > > > > Please let us know if some one from your team can guide us on these > points. > > > > Regards, > > Kirankumar Malyala > > > > > > > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise confidential information. If you > > have received it in error, please notify the sender immediately and > > delete the original. Any other use of the e-mail by you is prohibited. > > Where allowed by local law, electronic communications with Accenture > > and its affiliates, including e-mail and instant messaging (including > > content), may be scanned by our systems for the purposes of > > information security and assessment of internal
QPID-CPP "No Protocol Received" on internal connections
Qpid C++ Periodic Connection Issues
Hello,
I am currently working on upgrading a legacy application's QPID
communication to support SSL/TLS encryption via x.509 certificates. I was
provided a virtual machine to test against and I think I've got most of it
ironed out. However, maybe 1 out of 10 times I start up my system my Qpid
C++ code will simply refuse to open any connections to the other virtual
machine nor will it open any connections to connections for services that
are hosted by my application.
I came across this issue: https://issues.apache.org/jira/browse/QPID-8221
which describes similar behavior to what I was seeing, so I added
"connect-timeout: 5" to my connection options, this did keep the connection
open calls from hanging but didn't fix my issue as it continues to fail to
connect rather than failing once and hanging like it was without that
option.
I'm able to force this issue to present (eventually) by restarting my
application several times. Not only am I unable to communicate with my test
VM when in this error state but I'm also unable to connect to my own
exchanges and see lots of logs like "[System] error Connection
qpid.10.43.1.10:3-10.43.1.11:51564 No protocol received after 10s,
closing" which are both internal IP addresses.
When I enable protocol logging with "log-enable=trace+:Protocol" and browse
them while my application is in the error state I see a ton of SEND and RECV
calls which seems to indicate that there's some level of communication
happening but I'm not exactly sure how to parse what I'm seeing (snippet
from the logs below). This issue does not appear to ever occur when I run my
application without the SSL/TLS x.509 stuff enabled.
I tried using Wireshark to snoop on the message traffic when this occurs and
I can see that there is no TLS traffic whatsoever when I'm in the error
state, when things are working as intended I can see lots of TLS 1.2 packets
flowing back and forth.
I've been chasing this issue for a few days with no luck. If anybody has any
ideas that might get me on the right track I'd really appreciate it!
qpid-cpp client, server, and tools are all version 1.39.0-1
An excerpt of the protocol logs, 192.168.56.2 is my VM, 192.168.56.55 is the
Test VM I'd like to talk to:
Oct 27 21:34:01 stbdlcp qpidd[14927]: 2020-10-27 21:34:01 [Protocol] trace
SENT [qpid.192.168.56.2:3-192.168.56.55:52718]: Frame[Bbe; channel=1;
{MessageTransferBody: destination=21efd55d-79d4-4ed4-afa0-e259a13ca3a7#;
accept-mode=0; acquire-mode=0; }
Oct 27 21:34:01 stbdlcp qpidd[14927]: 2020-10-27 21:34:01 [Protocol] trace
SENT [qpid.192.168.56.2:3-192.168.56.55:52718]: Frame[be; channel=1;
header (178 bytes); properties={{MessageProperties: content-length=1622;
correlation-id=3277; content-type
Oct 27 21:34:01 stbdlcp qpidd[14927]: 2020-10-27 21:34:01 [Protocol] trace
SENT [qpid.192.168.56.2:3-192.168.56.55:52718]: Frame[Ebe; channel=1;
content (1622 bytes)
\x00\x00\x06R\x00\x00\x00\x01\xA8\x00\x00\x06I\x00\x00\x00\x06
Oct 27 21:34:01 stbdlcp qpidd[14927]: _create_ts2\x16A\xF6...]
Oct 27 21:34:02 stbdlcp qpidd[14927]: 2020-10-27 21:34:02 [System] error
Connection qpid.10.43.1.10:3-10.43.1.11:47720 No protocol received after
10s, closing
Oct 27 21:34:02 stbdlcp qpidd[14927]: 2020-10-27 21:34:02 [Protocol] trace
RECV [qpid.192.168.56.2:3-192.168.56.55:52718]: Frame[BEbe; channel=1;
{MessageAcceptBody: transfers={ [821,821] }; }]
Oct 27 21:34:02 stbdlcp qpidd[14927]: 2020-10-27 21:34:02 [Protocol] trace
RECV [qpid.192.168.56.2:3-192.168.56.55:52718]: Frame[BEbe; channel=1;
{SessionFlushBody: completed=1; }]
Oct 27 21:34:02 stbdlcp qpidd[14927]: 2020-10-27 21:34:02 [Protocol] trace
RECV [qpid.192.168.56.2:3-192.168.56.55:52718]: Frame[BEbe; channel=1;
{MessageStopBody: destination=757fc5f1-659b-475b-942c-1a6ce3e763b8#; }]
Oct 27 21:34:02 stbdlcp qpidd[14927]: 2020-10-27 21:34:02 [Protocol] trace
SENT [qpid.192.168.56.2:3-192.168.56.55:52718]: Frame[BEbe; channel=1;
{SessionCompletedBody: commands={ [4364,4379] }; timely-reply=1; }]
Oct 27 21:34:02 stbdlcp qpidd[14927]: 2020-10-27 21:34:02 [Protocol] trace
SENT [qpid.192.168.56.2:3-192.168.56.55:52718]: Frame[BEbe; channel=1;
{SessionCompletedBody: commands={ [4364,4380] }; }]
Oct 27 21:34:02 stbdlcp qpidd[14927]: 2020-10-27 21:34:02 [Protocol] trace
RECV [qpid.192.168.56.2:3-192.168.56.55:52718]: Frame[BEbe; channel=1;
{SessionKnownCompletedBody: commands={ [4359,4379] }; }]
Oct 27 21:34:02 stbdlcp qpidd[14927]: 2020-10-27 21:34:02 [Protocol] trace
RECV [qpid.192.168.56.2:3-192.168.56.55:52718]: Frame[BEbe; channel=1;
{MessageReleaseBody: transfers={ }; }]
Oct 27 21:34:02 stbdlcp qpidd[14927]: 2020-10-27 21:34:02 [Protocol] trace
RECV [qpid.192.168.56.2:3-192.168.56.55:52718]: Frame[BEbe; channel=1;
{MessageCancelBody: destination=757fc5f1-659b-475b-942c-1a6ce3e763b8#; }]
Oct 27 21:34:02 stbdlcp qpidd[14927]: 2020-10-27 21:34:02 [Model] debug
Delete subscription.
