Client Broker Server Interaction Use cases - LLNL-Collaboration/uiuc2015 GitHub Wiki

Using Broker to help establish an SSH tunnel a general TCP/IP socket server.

client: ssh to host

client(via ssh): start server on host

server --> broker: register service and request port

broker: generate port, establish ssh tunneling for port, generate magic key

broker --> server: return port

server: open socket server on port

client(via ssh) --> broker : request port #, magic key

client: establish other end of the ssh tunnel

client: open socket to server

client(via socket) --> server: provide magic key

server --> broker: verify magic key

  • if verify fails: close socket connection to client
  • if verify passes: start general communication over socket.

Using Broker to help establish a trusted HTTPS connection between a client and server

server --> broker: register service and request port

broker: generate port,generate magic key, create ssl cert, (future: register ssl cert with trusted ca)

broker --> server: return port, ssl cert path

server: open https server on port using ssl cert

client(via ssh, or something like lorenz) --> broker : request port #, magic key

client: open https connection to server (via web browser)

client(https) --> server: provide magic key

server --> broker: verify magic key

  • if verify fails: close https connection to client
  • if verify passes: allow web traffic

Broker Functionality

From these two cases, here are the things the broker must support:

  • (register/save) Request: register service (by name) and request port

  • SSH Case:

    • Action: establish ssh tunneling for port, generate magic key
    • Reply: port

  • HTTPS Case:

    • Action: generate port,generate magic key, create ssl cert, (future: register ssl cert with trusted ca)
    • Reply: port, path to ssl cert

  • (load) Request: give info about an active service (by name?)

  • Action: look up and give info about active service (maybe help with client ssh tunnel?)

  • Reply: port, magic key

  • (verify) Request: verify magic key

  • Action: check magic key against know key

  • Reply: pass or fail

  • (query) Request: list open services

  • Action: query active registrations by name

  • Reply: list of registered services that match query

For Lorenz, or stand alone apps to use this these request should be support via a shell command, or a python library.

Notes / Quandaries:

  • N: In the above cases, the key exchange always happens via an already approved trusted channel (ssh, or lorenz)
  • Q: Instead of magic key for the HTTPS case, can we create public / private keys for the client that the https server can use to only allow that client to connect? Not commonly done, but I think TLS (https) supports this.
  • Q: For HTTPS case, instead of per service certs, and we use two certs per user (one for any server and on for any client)?