Thank you Lorenz,
It is perfectly clear now. Regards, Adel ________________________________ From: Lorenz Quack <[email protected]> Sent: Tuesday, December 6, 2016 5:08:55 PM To: [email protected] Subject: Re: [Qpid Java Broker 6.0.4] Java Cryptography Extension Hello Adel, I see. SSL/TLS encrypts the communication between the client library and the broker to prevent eavesdropping by a third party. Anyone with access to the broker or any client which is permissioned to consume the message from the queue has access to the message. This does not require the unlimited strength JCE. The *message* encryption Keith and I were refering to is End-to-End (i.e., client to client) encryption. This means (a little simplified) that the broker or anybody with access to the broker cannot see the content of the message. This feature requires the unlimited strength JCE. This is analogue to email where you can connect to the IMAP/POP3 server using SSL/TLS but that does not mean that your emails (messages) themselves are encrypted. In this analogy you could use PGP to encrypt the email/message itself so that only the intended recipient can read it. This is essentially the message encryption we are referring to. SASL is completely separate. It is concerned with how the authentication takes place and might or might not involve cryptography but is orthogonal to how traffic is exchanged between the client and broker once the user is authenticated. I hope that helps to clarify things. Kind regards, Lorenz On 06/12/16 12:55, Adel Boutros wrote: > Hello Lorenz, > > > Yes, I think there is a misunderstanding here. > > > In our tests, we activated SSL and SASL and the messages were successfully > sent/received and were encrypted. > > > Is the above in contradiction with what is said here "the AMQP 1.0 Qpid JMS > Client does currently not support message encryption"? > > > Regards, > > Adel > > ________________________________ > From: Lorenz Quack <[email protected]> > Sent: Tuesday, December 6, 2016 1:46:19 PM > To: [email protected] > Subject: Re: [Qpid Java Broker 6.0.4] Java Cryptography Extension > > Hello Adel, > > As mentioned by Keith, the AMQP 1.0 Qpid JMS Client does currently not > support message encryption. > Or did I misunderstand your follow-up question? > > Furthermore, the Kerberos AuthenticationProvider also requires the full > strength JCE. > > Kind regards, > Lorenz > > > On 06/12/16 09:13, Adel Boutros wrote: >> Thank you Keith! >> >> >> For AMQP 1.0 Qpid JMS , what encryption mechanism is used? >> >> >> Regards, >> >> Adel >> >> ________________________________ >> From: Keith W <[email protected]> >> Sent: Tuesday, December 6, 2016 10:00:47 AM >> To: [email protected] >> Subject: Re: [Qpid Java Broker 6.0.4] Java Cryptography Extension >> >> Hi Adel >> >> Within the Qpid Broker for Java, it is the Configuration Encryption piece: >> >> https://qpid.apache.org/releases/qpid-java-6.0.4/java-broker/book/Java-Broker-Security-Configuration-Encryption.html >> >> The 0-8..0-10 Qpid JMS client also uses the JCE for end to end message >> payload/header encryption. >> >> https://qpid.apache.org/releases/qpid-java-6.1.0/jms-client-0-8/book/JMS-Client-Message-Encryption.html >> >> The newer AMQP 1.0 Qpid JMS Client does not support this feature (yet). >> >> Kind regards, Keith Wall. >> >> >> >> On 6 December 2016 at 08:35, Adel Boutros <[email protected]> wrote: >>> Hello, >>> >>> >>> It is mentioned in the link below that some features require Java >>> Cryptography Extension. What are those features exactly? >>> >>> >>> http://qpid.apache.org/releases/qpid-java-6.0.4/java-broker/book/Java-Broker-Installation-Prerequistes.html#ftn.d0e103 >>> >>> >>> Regards, >>> >>> Adel >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
