[zeromq-dev] EncryptedSocket added to pyzmq in branch

[Burak Arslan]

hello martin,

sorry, for the late reply, i had a work urgency to tackle.

 On 11/06/10 15:27, Martin Sustrik wrote:
> 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.

i agree, this can't be prevented.

> 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.
>

those are regular DoS attacks that are possible with zeromq simply
because you trust your input.

if you're using a sat-comms solution like inmarsat, every byte counts.
so if i'm using zeromq to route messages via an inmarsat link, a
malicious client may flood that link with messages, causing damage that
costs real money.

if the message destinations are signed, the "tries to read its own
handwriting" (from the user guide) will become "reads and verifies that
it was its own handwriting". please notice that this is in line with
your "zeromq should run in untrusted environments" statement. i agree,
and that's an improvement towards that goal.

the email spam problem as we know it would not exist today, if smtp was
properly set up with cryptography from day one. so when your ambitions
include building an internet-scale messaging system, it's best to learn
from past engineering mistakes of similar systems.

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

you misunderstand. let's say you've implemented dns over zeromq, and
have server a responsible for zeromq.com and b is responsible for
blog.zeromq.com and server c is responsible for static.blog.zeromq.com

when there's a request for, say, 3.static.blog.zeromq.com, the a server
can route it directly to c to speed things up. for that to happen, the
whole routing information must be readable, and not just the next hop.
it's after this decision that the routing infrastructure at the ip-level
will do its job.

but, when i said this, i was just thinking out loud. so i don't think
you should worry about this :)

best regards,
burak