Implement ssh tunnelling about circus HOT 16 CLOSED

I was thinking we could something like http://www.erlang.org/doc/apps/erts/erl_dist_protocol.html but indeed the message signing is interresting here.

from circus.

it seems quite trivial with pyOpenSSL.

Maybe we could have a pluggable way to do this by defining a transport layer where you pick a specific plugin that's in charge of exchanging the data. T

from circus.

it should be present in 0.1 imo

from circus.

also - SSH tunneling feature in pyzmq - http://zeromq.github.com/pyzmq/ssh.html

from circus.

an ability to encrypt & sign messages would be hugely beneficial for using circus on systems that run customer code

from circus.

Have a look at how salt does can be useful: http://salt.readthedocs.org/en/latest/topics/specs/salt_auth_proto_abs.html

from circus.

I propose a very simple first step here:

1/ circus has a pub/private key
2/ each client has its own pub/private key
3/ the circus configuration file lists all authorized client public keys
4/ a client ask Circus for a session, given its fingeprint
5/ Circus generates a passphrase and encrypt it using the client key
6/ The client stores the passphrase and uses it to encrypt all messages sent to Circus
7/ The session dies after a while, so the client has to ask the server to regenerate a new passphrase

from circus.

I'm trying here to rephrase your proposition so we're sure to be on the same page:

I can see two ways to send information, from the client to the server (circus) (a) and the other way around (b). Both cases needs to establish a session (that's a part of (a)).

(a) Sending messages from the client to the server

Client                                                 Server
     --( 1 )--------------------------------------------->
     <--------------------------------------------( 2 )---
       ( 3 )

1. The client registers itself to the server and ask for a new session. It sends with its request its public key.
2. the server generates a new random session passphrase, stores it and return it, signed with the public key of the client so the client is the only one able to read it.
3. the client reads and stores the passphrase for later messages.

(b) Sending information from the server to the client

This can be done by directly using the public key of the client from the server. then only the client will be able to read the message in question.

Having said this, here are some thoughts:

• Why do we need to have a pub/priv keypair for circus itself? If each time we're sending information from a client we need to be in a session, then doesn't seems to be needed.
• How are you defining the fingerprint for a client? Sounds to me that we can generate it completely randomly, and then I would call it a nonce rather than a fingerprint, but I may have missed something in the design you're proposing.

from circus.

The client theoretically wants to know that the server is the server, because sensitive information may be getting passed to / received from (e.g. get data back from server, put it in important database as authoritative information) the server, so a MITM is a concern

My mental model is more, one "client" many circusd "servers", so the central client wants to know who it's talking to, as well as ensure no one unauthorized is talking to the servers

from circus.

The detailed scheme I had in mind:

assumption: the client has the server public key

1/ client asks for a session, provides his own public key, encrypted with the server's public key
2/ server optionaly checks if the client is in a white list
3/ server decrypts and build a session passphrase for that client
4/ server encrypts the passhprase w/ client public key, and tramsmits it
5/ client uses the key to encrypt all data for the session , using AES

from circus.

Makes sense to me then. Waiting for crypto review and will go for the
implementation.

from circus.

pedantic crypto first-pass question: is there a need to invent a new protocol? I don't quite have the full architecture in mind, so bear with me... but I see mentions of ssh tunneling (yay!) In general, I would recommend away from reinventing a new approach if you can layer an existing secure session layer.

Is that possible?

from circus.

Thinking again about it, maybe we could implement the SSH2 protocol using http://www.lag.net/paramiko/

And have on the server-side some kind of ssh proxy in front of ZMQ

from circus.

pyzqm has a paramiko integration

http://zeromq.github.com/pyzmq/api/generated/zmq.ssh.tunnel.html

from circus.

http://zeromq.github.com/pyzmq/ssh.html

from circus.

woot done by Nick at http://git.io/uA7K7A

from circus.