search

openfaux / openfaux-server

Browser add-on for encrypting and masking internet traffic.
https://openfaux.org
GNU Affero General Public License v3.0
72 stars 18 forks source link

Stand-alone watcher service #35

Open admwx7 opened 10 years ago

admwx7 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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" notifications@github.com 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/openfaux/openfaux-server/issues/35#issuecomment-32066697 .