[zeromq-dev] EncryptedSocket added to pyzmq in branch

Martin Sustrik sustrik at 250bpm.com
Sat Nov 6 14:27:58 CET 2010


Hi Burak,

I have very little experience with security so bear with me if my 
questions are stupid.

> (X)REP/REQ sockets use message parts to store target nodes. If the
> payload of the message is important enough to bother with complex
> cryptography, its routing state also should be.
>    

What's the possible attack scenario here?

1. Someone may find out that A is sending message to B.
2. Someone may fake a reply to be sent to the particular endpoint 
instead of regular reply.
3. Someone may fake a request to solicit a reply to be sent to a 
particular endpoint.

If we want 0mq to become a generic internet-scale fabric, we have to 
treat intermediary nodes as untrusted. Otherwise we would be able to 
build only topologies that are fully owned by a single entity. If the 
intermediary nodes are untrusted they can track how messages are being 
routed. Thus I think scenario 1. cannot be prevented.

As for 2. and 3. I would assume there are ways to ensure that reply 
corresponds to a particular request and that it was generated by the 
authorised service. I would further guess that it can be done on message 
level rather than having to mess with routing info.

> It doesn't make sense to encrypt routing state as it has to be readable
> by intermediate nodes. It may make sense to expose only the NEXT node,
> but it will prevent routers from making shortest path decisions (???)
> and will also force a router to handle both the requests and the
> responses of a message exchange. so it's not a good idea to enrypt
> message identities.
>    

Finding shortest path is a functionality provided on IP level. 
Implementing a duplicit functionality on 0mq level would be a bad design 
choice.

Also, passing both request and corresponding reply through the same 
middle node  is a desirable characteristic as it allows for all kinds of 
interesting services provided by the intermediaries.

Martin




More information about the zeromq-dev mailing list