Re: client certificate and client hostname check
On 9 June 2016 at 22:19, Gordon Sim wrote: > On 09/06/16 21:00, Rob Godfrey wrote: > >> Hi Olivier, >> >> Speaking for the Java Broker, there is currently no mechanism to tie the >> TLS client certificate to the host name or IP address corresponding to the >> origin of the TCP/IP connection (I'd imagine this is also the case for >> Dispatcher but I'll let someone more knowledgable on that codebase step in >> there). Similarly to the C++ broker as described in the document Chester >> provided, when using the SSL Client Certificates on a connection we simply >> verify that the certificate has been signed by a trusted source, and then >> (if the External Auth Provider is being used) take the identity from the >> certificate itself. >> >> It's certainly shouldn't be a big job to add the ability to verify that >> the >> certificate provided by the client in the TLS negotiation has a DN or SAN >> which corresponds to the IP address or reverse-looked-up DNS name of the >> machine initiating the connection. Obviously in your use case as >> described >> below this would be validating that the connection from a Dispatcher >> instance is coming from the expected machine for the Dispatcher... it >> won't >> be verifying anything about the client which connects to the Dispatcher. >> >> Would you be interested in me implementing something to add this >> functionality to the Java Broker? >> > > My suggestion would be to restrict the authenticated client identity to > connect only from given IP addresses. That way your certificates just > identify the client (and are not tied to a given host or ip address) and > you can update the whitelisted/blacklisted ips for a given client identity > more easily. > > The router can do this now, I believe. > > > Yes - that will also work if you have a reasonably static set of users / hosts connecting and want to have the configuration at the server... The Java Broker also supports ACL rules that limit access to a given virtual host for a given user (or group) to a set of IP Addresses or DNS host names. The difference (I don't know if this is the property that Olivier needs) is that the TLS certificate mechanism doesn't need the broker to be reconfigured in order for a new client / host to be added... that is taken care of solely by the generation of a certificate which is is signed by the trusted authority. -- Rob > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
Re: client certificate and client hostname check
On 09/06/16 21:00, Rob Godfrey wrote: Hi Olivier, Speaking for the Java Broker, there is currently no mechanism to tie the TLS client certificate to the host name or IP address corresponding to the origin of the TCP/IP connection (I'd imagine this is also the case for Dispatcher but I'll let someone more knowledgable on that codebase step in there). Similarly to the C++ broker as described in the document Chester provided, when using the SSL Client Certificates on a connection we simply verify that the certificate has been signed by a trusted source, and then (if the External Auth Provider is being used) take the identity from the certificate itself. It's certainly shouldn't be a big job to add the ability to verify that the certificate provided by the client in the TLS negotiation has a DN or SAN which corresponds to the IP address or reverse-looked-up DNS name of the machine initiating the connection. Obviously in your use case as described below this would be validating that the connection from a Dispatcher instance is coming from the expected machine for the Dispatcher... it won't be verifying anything about the client which connects to the Dispatcher. Would you be interested in me implementing something to add this functionality to the Java Broker? My suggestion would be to restrict the authenticated client identity to connect only from given IP addresses. That way your certificates just identify the client (and are not tied to a given host or ip address) and you can update the whitelisted/blacklisted ips for a given client identity more easily. The router can do this now, I believe. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: client certificate and client hostname check
Hi Olivier, Speaking for the Java Broker, there is currently no mechanism to tie the TLS client certificate to the host name or IP address corresponding to the origin of the TCP/IP connection (I'd imagine this is also the case for Dispatcher but I'll let someone more knowledgable on that codebase step in there). Similarly to the C++ broker as described in the document Chester provided, when using the SSL Client Certificates on a connection we simply verify that the certificate has been signed by a trusted source, and then (if the External Auth Provider is being used) take the identity from the certificate itself. It's certainly shouldn't be a big job to add the ability to verify that the certificate provided by the client in the TLS negotiation has a DN or SAN which corresponds to the IP address or reverse-looked-up DNS name of the machine initiating the connection. Obviously in your use case as described below this would be validating that the connection from a Dispatcher instance is coming from the expected machine for the Dispatcher... it won't be verifying anything about the client which connects to the Dispatcher. Would you be interested in me implementing something to add this functionality to the Java Broker? Cheers, Rob On 9 June 2016 at 21:34, Chester wrote: > At least for the cpp broker, ssl-require-client-authentication=yes will do > the trick. The broker book ( > > http://qpid.apache.org/releases/qpid-cpp-0.34/cpp-broker/book/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-Encryption_using_SSL > ) > is a good resource for SSL options. > > As far as the check goes, I think it looks at the Subject Alternative Name, > and falls back to CN if there is no SAN on the cert. > > > On Thu, Jun 9, 2016 at 1:09 PM, Olivier Mallassi < > olivier.malla...@gmail.com > > wrote: > > > All, > > > > The whole idea is > > (1) to build the following chain : clients (Java/c++) <-> dispatcher(s) > <-> > > java qpid brokers. > > (2) with two ways SSL between all the components > > > > test are ongoing but I was wondering if there is a way to configure the > > dispatchers and the brokers to check (or not) the client hostname (while > > checking the client certificate)? > > if activated, does it use the CN for hostname? > > > > Thx for your help. > > > > Cheers. > > > > Olivier. > > >
Re: client certificate and client hostname check
At least for the cpp broker, ssl-require-client-authentication=yes will do the trick. The broker book ( http://qpid.apache.org/releases/qpid-cpp-0.34/cpp-broker/book/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-Encryption_using_SSL) is a good resource for SSL options. As far as the check goes, I think it looks at the Subject Alternative Name, and falls back to CN if there is no SAN on the cert. On Thu, Jun 9, 2016 at 1:09 PM, Olivier Mallassi wrote: > All, > > The whole idea is > (1) to build the following chain : clients (Java/c++) <-> dispatcher(s) <-> > java qpid brokers. > (2) with two ways SSL between all the components > > test are ongoing but I was wondering if there is a way to configure the > dispatchers and the brokers to check (or not) the client hostname (while > checking the client certificate)? > if activated, does it use the CN for hostname? > > Thx for your help. > > Cheers. > > Olivier. >
Re: [VOTE] Release Qpid Proton 0.13.0
+1 * Checked the signature and the checksums * Checked the license and notice files * Built from source using the cmake build and ran tests * Built from source for proton-j using the maven build and ran the tests * Tested Qpid JMS using the 0.13.0 proton-j against ActiveMQ built against both 0.12.1 and 0.13.0 * Tested Qpid JMS using the 0.12.1 proton-j against an ActiveMQ broker built against 0.13.0 * Ran ActiveMQ unit tests with updated 0.13.0 dependency. On 06/07/2016 10:31 AM, Justin Ross wrote: The artifacts proposed for release: https://dist.apache.org/repos/dist/dev/qpid/proton/0.13.0-rc/ Please indicate your vote below. If you favor releasing the 0.13.0 RC bits as 0.13.0 GA, vote +1. If you have reason to think the RC is not ready for release, vote -1. Thanks, Justin --- Proton 0.13.0 release page: https://cwiki.apache.org/confluence/display/qpid/Qpid+Proton+0.13.0 -- Tim Bish twitter: @tabish121 blog: http://timbish.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
client certificate and client hostname check
All, The whole idea is (1) to build the following chain : clients (Java/c++) <-> dispatcher(s) <-> java qpid brokers. (2) with two ways SSL between all the components test are ongoing but I was wondering if there is a way to configure the dispatchers and the brokers to check (or not) the client hostname (while checking the client certificate)? if activated, does it use the CN for hostname? Thx for your help. Cheers. Olivier.
Re: [VOTE] Qpid Dispatch Router 0.6.0 (RC4)
previous vote rescinded. +1 - Release RC4 as Qpid Dispatch Router 0.6.0 - Original Message - > From: "Robbie Gemmell" > To: users@qpid.apache.org > Sent: Wednesday, June 8, 2016 10:42:39 AM > Subject: Re: [VOTE] Qpid Dispatch Router 0.6.0 (RC4) > > On 8 June 2016 at 15:07, Ken Giusti wrote: > > Robbie - > > > > - Original Message - > >> From: "Robbie Gemmell" > >> To: users@qpid.apache.org > >> Sent: Tuesday, June 7, 2016 4:56:56 PM > >> Subject: Re: [VOTE] Qpid Dispatch Router 0.6.0 (RC4) > >> > >> Is the behaviour a regression, or has it always been that way? If its > >> the latter then I think its simply a good addition to a list of things > >> worthy of a swift followup release, rather than a reason to hold back > >> this one. > >> > > > > Good point - no it is not a regression. > > > > But it is an ambiguity in the behavior that is visible to the clients that > > will likely result in clients violating the AMQP 1.0 spec (i.e. resending > > w/o proper delivery count or resending to a node that cannot process the > > message). > > > > No I don't want to hold up the release. I agree it's been too long since > > the last release (but given the major refactor that has occurred it is > > understandable why it has taken so long). But I don't want to let this > > issue remain open for too long once a fix is available. > > > > I haven't found any other issues with the RC4 candidate. > > > > If the consensus is to ship 0.6.0 without a fix I'll rescind my -1 but I'm > > going to call for a 0.6.x release if 0.7.0 doesn't ship within a couple of > > weeks after a fix is made available. > > > > Is this a reasonable compromise? > > > > -K > > Yes, I think doing a 0.6.1 (or however many 0.6.x as are appropriate > to resolve similar issues as they arise) if 0.7.0 is more than a > couple weeks away seems like a good approach. It almost seems like the > final digit in the versions could be useful :) > > Robbie > > > > >> There will be other things requiring fixes and as people discover > >> those we can and should do additional releases as appropriate to fix > >> them. It looks to be almost 9 months since the last Dispatch release, > >> its time to get a new one out and then do some more after that. > >> > >> I've said this before, but I think its worth repeating. In general we > >> are guilty of taking too long to put out releases, often coupled with > >> having putting too much in them, then putting even more things in to > >> avoid them waiting around for the next slow release. The trouble is, > >> the more often releases are delayed to fit in yet another thing, then > >> the more often people will feel the need to fit yet more into it, and > >> the longer people will put off testing the candidate builds due to > >> expectation there will still be more of them to come, and the later we > >> might find actual blockers as a result, and the further needless > >> respins there are. The net result is fewer releases that can often end > >> up being overly annoying and further encourage doing less of them. > >> > >> It takes us no more time and effort (probably even a good bit less) to > >> do multiple releases in a given reasonable time period than it does to > >> respin one over and over before release, but short of breaking API > >> changes to consider its generally going to be nicer having the > >> additional releases. > >> > >> Robbie > >> > >> On 7 June 2016 at 20:57, Ken Giusti wrote: > >> > -1 - Don't release RC4 because of > >> > https://issues.apache.org/jira/browse/DISPATCH-366 > >> > > >> > Sorry to be the party pooper, but this seems serious enough to block the > >> > RC. > >> > > >> > If this isn't fixed we risk clients re-sending messages with the > >> > improper > >> > delivery-count value. > >> > > >> > > >> > > >> > > >> > - Original Message - > >> >> From: "Ted Ross" > >> >> To: users@qpid.apache.org > >> >> Sent: Monday, June 6, 2016 5:32:14 PM > >> >> Subject: [VOTE] Qpid Dispatch Router 0.6.0 (RC4) > >> >> > >> >> This is the vote thread to approve RC4 as the final Dispatch Router > >> >> 0.6.0. > >> >> > >> >> Given that this is a significant release in terms of features and > >> >> functionality, I think we should get it released. > >> >> > >> >> I understand that there are a number of open issues with this > >> >> candidate, > >> >> the most worrisome being DISPATCH-358. This issue involves > >> >> intermittent > >> >> crashes, but to this point it has been unreproducible outside of the > >> >> reporter's test environment. > >> >> > >> >> My proposal is to go forward with the release, get the new > >> >> functionality > >> >> out officially, and continue to close out the issues that are > >> >> outstanding. If we reproduce and fix DISPATCH-358, we can turn a 0.6.1 > >> >> on the release branch, or wait for 0.7.0 (which should be much shorter > >> >> in duration than 0.6.0). > >> >> > >> >> Please weigh in with your opinion and your vote: > >> >> > >> >> +1 - R
Re: Qpid Java Broker performance tests using AMQP 1.0
At the end I have managed to make it run using AMQP 1.0 protocol against both Qpid Java broker and Qpid C++ broker. With Qpid Java broker I had to switch to REST Queue creator and also specify management parameters. The final command then looks like: For the C++ broker I have created queues by hand and used "NoOp" Queue creator. The final command: -- View this message in context: http://qpid.2158936.n2.nabble.com/Qpid-Java-Broker-performance-tests-using-AMQP-1-0-tp7645180p7645383.html Sent from the Apache Qpid users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
