You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Ken Giusti <kg...@redhat.com> on 2009/10/26 16:52:09 UTC
Q: replicating connection info in a cluster
Hi,
I'm trying to fix QPID-1899, and I am trying to determine the best approach to implement for the cluster case. Opinions requested!
The way I'm trying to fix this bug is by indicating to the broker when a connection is on a secure link. Specifically, if a connection uses SSL, then I want the SASL authenticator to be aware of this. In SASL, this is done by by setting the "external security strength factor" for a connection. This prevents SASL from trying to encrypt over an already encrypted connection.
The patch I've posted for QPID-1899 seems to work in the non-cluster case. I can determine the security strength (key length) for an SSL connection trivially, since the connection is local.
The problem I've hit is with shadow connections on clustered brokers: since the SSL link doesn't exist locally, I can't get the key length.
I noticed that the cluster code creates the shadow connection on receipt of an "announce" message. One approach to solving this problem would be to put the security strength factor into the announce message when a link that is encrypted is shadowed. This would require me to add the security strength factor to the cluster announce message.
I'm not sure of the ramifications of this, since it will change the existing protocol.
Is this a reasonable approach? Is there a better alternative?
thanks!
https://issues.apache.org/jira/browse/QPID-1899
-K
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Q: replicating connection info in a cluster
Posted by Alan Conway <ac...@redhat.com>.
On 10/26/2009 11:52 AM, Ken Giusti wrote:
> Hi,
>
>I'm trying to fix QPID-1899, and I am trying to determine the best approach to
implement for the cluster case. Opinions requested!
>
> The way I'm trying to fix this bug is by indicating to the broker when a
> connection is on a secure link. Specifically, if a connection uses SSL, then
> I want the SASL authenticator to be aware of this. In SASL, this is done by
> by setting the "external security strength factor" for a connection. This
> prevents SASL from trying to encrypt over an already encrypted connection.
>
> The patch I've posted for QPID-1899 seems to work in the non-cluster case. I
> can determine the security strength (key length) for an SSL connection
> trivially, since the connection is local.
>
> The problem I've hit is with shadow connections on clustered brokers: since
> the SSL link doesn't exist locally, I can't get the key length.
>
> I noticed that the cluster code creates the shadow connection on receipt of
> an "announce" message. One approach to solving this problem would be to put
> the security strength factor into the announce message when a link that is
> encrypted is shadowed. This would require me to add the security strength
> factor to the cluster announce message.
>
> I'm not sure of the ramifications of this, since it will change the existing
> protocol.
>
> Is this a reasonable approach? Is there a better alternative?
That's the way to go, add the data you need to the announce control in XML and
update 2 functions in Cluster.cpp: addLocalConnection (to send the data in the
announce) and getConnection (to set the data on the shadow connection)
Also you need to modify this line in Cluster.cpp:
const uint32_t Cluster::CLUSTER_VERSION = 820783;
Change it to whatever is the latest SVN revision before you submit the patch.
Its there to detect accidentally starting brokers with different versions of the
cluster protocol in the same cluster.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Q: replicating connection info in a cluster
Posted by Alan Conway <ac...@redhat.com>.
On 10/26/2009 11:52 AM, Ken Giusti wrote:
> Hi,
>
> I'm trying to fix QPID-1899, and I am trying to determine the best approach to implement for the cluster case. Opinions requested!
>
> The way I'm trying to fix this bug is by indicating to the broker when a connection is on a secure link. Specifically, if a connection uses SSL, then I want the SASL authenticator to be aware of this. In SASL, this is done by by setting the "external security strength factor" for a connection. This prevents SASL from trying to encrypt over an already encrypted connection.
>
> The patch I've posted for QPID-1899 seems to work in the non-cluster case. I can determine the security strength (key length) for an SSL connection trivially, since the connection is local.
>
> The problem I've hit is with shadow connections on clustered brokers: since the SSL link doesn't exist locally, I can't get the key length.
>
> I noticed that the cluster code creates the shadow connection on receipt of an "announce" message. One approach to solving this problem would be to put the security strength factor into the announce message when a link that is encrypted is shadowed. This would require me to add the security strength factor to the cluster announce message.
>
> I'm not sure of the ramifications of this, since it will change the existing protocol.
>
> Is this a reasonable approach? Is there a better alternative?
>
> thanks!
>
Been running after hotfix fires today so didn't see this - I'll give you a
proper response first thing tomorrow.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org