[zeromq-dev] Encryption (OpenSSL/TLS)
Brian Granger
ellisonbg at gmail.com
Fri Oct 1 02:47:11 CEST 2010
Great topic...
> 1) VPN level encryption, handled UNDER zmq.
> 2) SSL level encryption, handled BY zmq
> 3) message level encryption, handled ON TOP OF zmq.
> #2 is not really possible, for the previously-mentioned zmq system features
> of intelligent message routing by intermediate nodes. However, the same
> feature of exposing message flow and structure in order to provide those
> services has the security tradeoff of... exposing message flow and
> structure.
I don't quite follow this logic. If there were a tls transport in
zeromq, it would be entirely transparent to the zeromq API. IOW,
whenever a message appears in user code, it will not be encrypted. In
the actual zeromq code itself, you just have to ensure that the
message routing is done after the message is decrypted. The only
downside of this approach is that that each network hop will have to
encrypt/decrypt the message.
While I agree that 1) is a solid approach, deploying it in the wild
will be a total pain. Imagine if your bank required you to have a VPN
connection to access its website. Any security model for zeromq needs
to be deployable by "regular users" that don't have sys admin privs.
I think 2) is both possible and the best approach (unless I am missing
something).
Cheers,
Brian
> Thus, if message flow must be concealed, encrypting the entire channel via
> VPN (or SSH tunnels, or similar) is the route to take. If it's acceptable
> to just opaque-ify the message payloads, then either VPN encryption or
> message level encryption are both options to consider.
>
> On Thu, Sep 30, 2010 at 1:49 PM, Pieter Hintjens <ph at imatix.com> wrote:
>>
>> Hi Oliver,
>>
>> Mato and I were discussing this exact topic yesterday. Neither of us
>> are really security experts but his experience trumps mine. I'd go
>> for an OpenSSL TLS transport layer that replaces the existing tcp://
>> transport. Mato's opinion was that this would not work, and the
>> correct approach would be per-message encryption, with out of band key
>> exchange using some existing technology.
>>
>> Mato's approach has the advantage of also giving secure multicast.
>>
>> -Pieter
>>
>> On Thu, Sep 30, 2010 at 7:56 PM, Oliver Smith <oliver at kfs.org> wrote:
>> > After a little time off doing other stuff, I come back to my guerrilla
>> > ZeroMQ integration project. An early concern for my project is security,
>> > and it seems like using OpenSSL's TLS API might provide a
>> > wheel-reinvention-avoiding means of encrypting the streams. But it seems
>> > like I'd have to integrate it very much at the zmq::socket_t level or
>> > else I'd have to do per-message_t encryption which doesn't seem terribly
>> > efficient.
>> >
>> > If anyone has any pointers on encryption w/ZeroMQ ... be really, really
>> > greatful :)
>> >
>> > - Oliver
>> >
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev at lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> >
>>
>>
>>
>> --
>> -
>> Pieter Hintjens
>> iMatix - www.imatix.com
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
More information about the zeromq-dev
mailing list