[openamq-dev] Encryption/C++ API

[Robert Powers]

Pieter,

Thank you for the detailed response.

My interest is moving slightly beyond the traditional enterprise use cases
for message queues in the enterprise and push a bit into the consumer
appliance realm.  This requires relatively robust security measures to
persuade people to poke a hole in their home firewalls for a broker to run
on a spare commodity box, off-the-shelf SAN, or whatever.

I agree with Russel and yourself that client level encryption makes the most
sense.  Clearly you need to balance security with speed and burdening the
broker with encryption would be an unnecessary trade-off.  For my needs the
broker would only need to provide a secure means of login (particularly
broker-to-broker) and everything else can be off-loaded to the clients.
Perhaps another concession is to make it optional for anyone not requiring
that level of security.

Thank you for you attention.





On Fri, Apr 18, 2008 at 2:51 PM, Pieter Hintjens <ph at imatix.com> wrote:

> On Fri, Apr 18, 2008 at 7:40 PM, Robert Powers <emptyspace02 at gmail.com>
> wrote:
>
> > (1) My understanding is that currently there is no option for encrypted
> > communication, in particular for logins, making OpenAMQ unusable over the
> > internet.  Are there any plans for this and, if so, what is the general
> > method and time frame is envisioned?
>
> In general we implement functionality only when there is a serious
> user demand, and security has been a check box item but not explicitly
> demanded by anyone up to now.
>
> There are a number of different requirements - privacy, tamper
> resistance, authentication.  The methods for doing each of these vary,
> and the effort needed also depends.
>
> My own preference - if I was building a secure internet-based network
> using OpenAMQ - would be to do end-to-end encryption, and place this
> entirely in the client API, above WireAPI.  The protocol does have
> some security hooks, e.g. for secure authentication of AMQP
> applications to the broker, and these would also be needed.
> Disclaimer: I am not a security expert.
>
> Using an existing security library like OpenSSL, we'd expect to be
> able to deliver a working security framework in a few weeks at most.
> The difficulties would be, IMO, (a) mixing secure and non-secure on
> the same network, (b) the performance hit in high-volume / low-latency
> situations, and (c) distribution of certificates.  Again, IANASE, and
> the best answer probably depends on the actual application demands.
>
> It may also be possible - but we'd need to check - to use the existing
> clients over an ssh tunnel to the broker.  Finally, the classic
> fallback is to use VPNs so that remote clients are effectively brought
> into the LAN.  This is especially plausible if one also uses OpenAMQ
> federation, so the VPN connects two brokers and not N clients to a
> remote broker.
>
> Sorry for the vagueness and probably inaccuracy of my answers.  If you
> have a clear scenario, we can give a more useful answer.
>
> > (2) Are there any publicly available C++ wrappers for the client API?
>
> We do have C++ wrappers for all the WireAPI classes, these are not
> built by default but we should be able to dust them off.
>
> My colleague Martin Lucina will probably have more to say on those these
> topics.
>
> -Pieter
>
> --
> This email may contain documents in ISO26300 format (ODF). ODF is
> portable to Windows, Mac, and GNU/Linux and is widely supported. Go to
> http://www.ODFworks.com for more information and free downloads.
> _______________________________________________
> openamq-dev mailing list
> openamq-dev at lists.openamq.org
> http://lists.openamq.org/mailman/listinfo/openamq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openamq.org/pipermail/openamq-dev/attachments/20080425/c4f31710/attachment.htm