Stand-alone watcher service

[admwx7]

The original scope was to have a single entry-point script we call (encrypt.py for example) and it initiates this connection. I know we've moved away from this by integrating with twisted. Another step from there (if we haven't already, haven't crawled through the server script to see yet) is to move to a watcher service running on the server. So it will just monitor incoming requests, if they have some identifier in their header to say they are coming from an openfaux client then it initiates the encryption process. Ideally this would spawn a new thread to run asynchronously so while the server is computing what to do with the request (this use case is best viewed as a partner using our software, someone wants to get data encrypted from a partner (FB)) it will send off to start the encryption handshake with the client which would spawn the key on the server. Once the process to collect the data was done instead of sending it to the client it would run it through the encryption process then respond to the client with the encrypted data.

This would allow partners to run our software and not have to rely on a middle-man server (us) to reroute everything and would allow their non OpenFaux clients (don't send the header) to continue to operate as expected. So in the case where the client is requesting encrypted data from an official partner the plugin would (instead of redirecting) add our flag and any other required data into the header and let it take it's normal course of action.

Discuss!

[boxtown]

I'm a little confused as to the process. Are you saying that when we get an OpenFaux client request (possibly indicated by a header), we asynchronously begin the encryption handshake while sending the request along to the intended destination and then only encrypting the data on the return leg between the server and client?

Also it is of my opinion that having just a header as identification for an OpenFaux client request makes it easy to spoof. Why couldn't anyone who's not the client similarly append such a header? Unless we don't particularly care about other (non-OpenFaux) clients being able to utilize our server's capabilities.

[admwx7]

Anyone that looks at our source will be able to see exactly what is needed
to make a server request, and it's open source in order to promote
development of multiple client options. Once the request is on the server
there is no encryption to be done until we have a response for the client,
this would just allow combining the initial request with the key
negotiation, it would however open up the initial request to the server,
but the very first request you make to a server for a session is never
dealing with anything sensitive. Alternatively we can keep the client as
is, it would still block until key negotiations are done then send the
initial request encrypted all of this would need some header or flag that's
not encrypted to notify a watcher to start handling the request instead of
letting the default handler take care of things. I think it would add more
appeal to third party services that don't want to interrupt the flow of
their service by suddenly requiring our plugin.
On Jan 10, 2014 3:13 PM, "Michael Ma" [email protected] wrote:

I'm a little confused as to the process. Are you saying that when we get
an OpenFaux client request (possibly indicated by a header), we
asynchronously begin the encryption handshake while sending the request
along to the intended destination and then only encrypting the data on the
return leg between the server and client?

Also it is of my opinion that having just a header as identification for
an OpenFaux client request makes it easy to spoof. Why couldn't anyone
who's not the client similarly append such a header? Unless we don't
particularly care about other (non-OpenFaux) clients being able to utilize
our server's capabilities.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/35#issuecomment-32066697
.