[nanomsg] Re: How is security going to be implemented in nanomsg?
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Mon, 16 Jun 2014 19:32:51 -0400
Disagree. But apps separate transport from authentication. Thing https with
basic auth.
You need to do real security analysis here. There are no short answers.
Sent from my iPhone
> On Jun 16, 2014, at 6:59 AM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx> wrote:
>
> Hop-by-hop is only satisfactory in the case where you trust all nodes on the
> network. This is sometimes known as the “trusted client” problem. For
> example in a REQREP scenario, you trust that every XREP that is connectable
> according to your TLS policy will forward your request intact and unmodified
> to the desired REP and not to some attacker. In the BUS scenario, you trust
> that every node will only read and write data that is appropriately addressed
> to that node. And so on.
>
> There are certainly applications that can fit nicely in these requirements.
> But I think they are primarily, if not entirely, enterprise-style messaging
> applications. So this reinforces what I said earlier, that this trajectory
> leads to being a great messaging framework, and not an internet
> communications library.
>
>
> Also,
>
>>
>> It's also messaging-pattern-agnostic,
>
> Is only true in the sense that TLS can *technically* be used with any message
> pattern. It does not mean that TLS works the same way or provides the same
> security guarantees. A TLS transport provides different security guarantees
> even within a protocol, in the case of REP vs XREP, for example—in the XREP
> case a MITM attack is possible between REQ and REP. Using TLS securely
> requires wire-level knowledge of what the protocol is doing. So for many
> practical senses, TLS is decidedly *not* message-pattern agnostic. It is
> only agnostic in the sense that it provides a consistent API for shooting
> yourself in the foot no matter what message pattern you need to use.
>
> If we relax the requirements for end-to-end security to match the standard we
> apply for TLS—essentially, we require TLS to provide largely arbitrary
> security guarantees for every protocol—we would find that end-to-end becomes
> trivial as well. This has nothing to do with end-to-end or hop-to-hop, it
> has to do with whether we require a system that provides confidentiality or
> MITM or replay protection or we do not.
>
> There are many TLS configurations that are open to all of those attack
> vectors and more. But, when it comes to the end-to-end case, we insist that
> problems that were “out of scope” for hop-to-hop suddenly become hard
> requirements for end-to-end.
>
> Drew
>
>
>> On Jun 16, 2014, at 2:32 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
>>
>> Signed PGP part
>> Hi Drew,
>>
>> > As long as these set of facts are true, it is time to get
>> > realistic about what we are doing. This is a messaging library for
>> > use on your private network. It’s not a general-purpose internet
>> > communications library. By our actions, we prioritize things that
>> > are useful for messaging on a private network over things are are
>> > useful for internet communication. With each new plaintext
>> > protocol, we increase the difficulty setting for securing nanomsg
>> > as a whole. When you take the limit of the current trajectory, you
>> > get a fantastic messaging library. But you don’t get a library that
>> > is suitable for deployment on the naked Internet.
>>
>> From my point of view the matter is actually much simpler:
>>
>> 1. End-to-end security (whatever it is supposed mean) is a hard
>> problem, may require original research and neither nanomsg, nor other
>> messaging solution can really solve it today. Luckily though, its
>> end-to-end nature means that the solution can be built entirely on top
>> of nanomsg and thus anyone can experiment with it, propose solutions,
>> package them as libraries etc.
>>
>> 2. Before there are viable end-to-end solutions, hop-by-hop is the way
>> to address existing security requirements. This is indeed part of
>> nanomsg, in form of a new transport (say, TLS-over-TCP) and is doable
>> even today. It's also messaging-pattern-agnostic, so it's not even
>> that hard to implement.
>>
>> Martin
>
Other related posts:
