[nanomsg] Re: issue with "received" message size
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx, Paul Colomiets <paul@xxxxxxxxxxxxxx>
- Date: Tue, 11 Mar 2014 08:59:28 -0700
On March 11, 2014 at 7:57:13 AM, Paul Colomiets (paul@xxxxxxxxxxxxxx) wrote:
Hi Garrett,
On Tue, Mar 11, 2014 at 4:37 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
> One thing that would be nice to include would be a way to obtain information
> about the connected peer -- particularly if the client cert has been
> presented. This then can be used not just for secrecy but for
> authentication as well. I need to think about that some more -- there are
> probably some bigger ramifications here because nanomsg doesn't currently
> offer any kind of API identification of peers.
>
> (I'm thinking that what is really desirable here -- and again easier to do in
> my new implementation in Go -- is an optional extended form of recv that
> includes information about the party the message was received from. This
> could be a handle to get the peer's IP address, certificates (if using TLS),
> or other kinds of information.)
>
I would say, that there should be option NN_ROOT_CERT, which if
set make socket only accept client with certificates signed by that
root. I think
its more in spirit of nanomsg than authenticating each connection.
That’s certainly a simpler solution, and it provides gross support for
“authentication”, but it prevents the possibility of using the certificate as
part of any “authorization” check. I think there may be circumstances when its
particularly useful to know not only that one client connected using a valid
cert, but that you know *who* that client is.
Lacking that, you have to perform application layer identity verification.
(Username/password, etc.) That’s a shame, given that we’d already have the
client’s identity available to us in a cryptographically strong manner if only
we had the API to get at it.
Authorization is *certainly* an application layer problem (apart from
authorization to access the transport itself, which your proposal addresses),
but SSL/TLS also give us the ability to use strong crypto to get user identity,
which I just see far too incredibly useful to leave by the way side.
Admittedly, use of this sort of prevents some of the rich topologies that
nanomsg and 0mq make possible, but I think there’s a huge number of
applications that would benefit even given the limitations.
- Garrett
Other related posts:
