[nanomsg] Re: Adding support for TLS
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sun, 23 Mar 2014 22:55:37 -0700
On Mar 23, 2014, at 10:23 PM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 24/03/14 02:34, Garrett D'Amore wrote:
>
>> Anyway, we need to have a common agreement about wire formats, and
>> addresses. This becomes more important now that there exists more
>> than a single implementation of nanomsg’s SP protocols. (Btw, I’m
>> *not* sure this can be said to be true of 0MQ. :-)
>>
>> I propose that for TLS, we would have the following:
>>
>> 1. Addresses look the same as TCP, but take the form
>> “tis://<server>:<port>” . No provision is made in the *address*
>> for specify certificates, SSL/TLS protocol version, cipher options,
>> etc. The natural way to handle those is via socket options or
>> something similar. (“Implementation specific.”)
>>
>> 2. The “wire-format” packet exchanges follow the same format as
>> for TCP, except that the message exchanges will occur over an
>> encrypted TLS stream, rather than a TCP stream. That is, the same
>> 8 byte bi-directional handshake will occur at the start of the
>> connection, and the same 8 byte length (big endian) will precede
>> each message exchanged.
>>
>> None of the above is meant to be a surprise. In fact, it is meant
>> to be the most trivial mapping of the TCP protocol to layer on top
>> of TLS. But doing this gives immediate usability of the nanomsg
>> protocols over untrusted transports.
>
> Yes. That looks like the most neat solution. It would be nice to have
> it written down in one very short RFC.
I’ll go ahead and draft one if you would like. Just let me know.
>
>> I’d be happy to spend some cycles implementing C extensions to
>> support this as well in libnanomsg itself, but that will require
>> importing OpenSSL. (I have *no* desire to reimplement all of
>> SSL/TLS from scratch, and any the most naive and security-ignorant
>> fool would desire this, given the “challenges” associated in
>> creating a “correct” implementation of SSL/TLS. :-)
>
> Yes. It would have to be an compile-time option (--enable-tls) for
> those who don't want to drag the openssl dependency in.
Yeah, obviously. This feels like another autoconf/automake check… *cough* I
still remember when I thought automake/autoconf were cool. Ah, the naiveté of
youth! :-)
>
>> As a side note, I noticed that when we “package” nanomsg, we don’t
>> include the RFC subdirectory. I think this is a mistake. There
>> are various legitimate reasons why the protocol details should be
>> readily available to other consumers.
>
> Yes. It's definitely a mistake. I'll fix that. I'll also create empty
> RFCs for UDP and TLS mapping to give you something to start with.
Thanks!
>
>> (Indeed, I’ve considered writing snoop or tcpdump extensions to
>> decode the handshake… I think this would be useful to
>> administrators trying to figure out what is going on.
>
> I once implemented a plug-in for wireshark (AMQP) and IIRC it was an
> easy enough task to do.
>
> As for SP, there are some problems though:
>
> 1. The TCP wire format is so "packed" that it's impossible to
> distinguish message boundaries unless you are following the connection
> from it's very beginning. Catching up in the middle of a stream can be
> tricky (unless you make an assumptio that messages are aligned with
> TCP packets of course).
>
> 2. Similar problem with different SP protocols: You know which one is
> used only if you sniff the beginning of TCP connection. Later on
> there's no way to tell.
Yeah I didn’t think about that. Still, you often are sniffing at the start of
the connection. If you are catching up in the middle of the connection, you’re
hosed, but I think this is common with other protocols. For example, web
socket, even HTTP, you don’t get useful information except during the initial
handshake phase. Folks doing debugging with these tools probably are used to
this limitation.
- Garrett
Other related posts:
