[zeromq-dev] Secure proxies
Charles West
crwest at ncsu.edu
Wed Apr 15 05:50:32 CEST 2015
Hey Steve,
That is a fair point (and thank you for answering). By encrypting the
stream using keys established between the two endpoints you could bypass
the flow of open data across the proxy. This has some costs associated
with it, however. The client/server other side of the proxy needs to be
aware that the proxy is acting on behalf of someone else and that standard
ZMQ security cannot be used. You also have to manually implement your
encryption/security protocol (which historically has been prone to errors).
If you could intercept the raw frames from a ZMQ socket and do IP in IP
routing (client -> proxy -> other client) to deliver them to the other side
of the proxy it would still be possible to use the ZMQ security features
without modification. The client on the other side of the proxy would not
need to be aware that the proxy was acting on behalf of another computer.
It would just appear to be one computer which had two software nodes.
The question is, how could you grab the segments coming to/from a secure
ZMQ and pass them to an internal process? In other words, how can you bind
a secure ZMQ socket (with its own key that the proxy can't access) and have
it appear to the rest of the world that the port that was bound is on the
proxy.
I've been thinking about it a lot today and I think I've come up with one
approach that would work except there is no way to intercept the outbound
traffic from the ZMQ socket without needing to bind 1 loopback socket for
every flow (binding the ZMQ socket to a loopback address and using a
RAW_SOCKET to do package encapsulation). Does anyone know if there is a
way to portably divert the the TCP segments that ZMQ sends?
Thanks,
Charlie West
On Tue, Apr 14, 2015 at 2:54 PM, Steve Eley <sfeley at gmail.com> wrote:
> On Apr 14, 2015, at 1:52 PM, Charles West <crwest at ncsu.edu> wrote:
>
>
> The simple way to act as a proxy would be just to make a ZMQ socket on
> each side and forward the data. The problem with that is that this would
> require the data to be unencryped on one side, copied and reencrypted.
> This introduces both overhead and allows the proxy to snoop (bad for
> general principles).
>
>
> I might be missing something obvious, but why would it require that? The
> proxy might need to be able to read *addressing* information to do its
> job, but why would it need to see the payload? Just establish a
> header/body separation, encrypt the header with a shared key that's
> readable by your whole routing system, and encrypt the body with keys that
> are only known to the endpoints.
>
>
> Have Fun,
> Steve Eley
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150414/27d966bc/attachment.htm>
More information about the zeromq-dev
mailing list