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

Outline and document that API #20

Open admwx7 opened 10 years ago

admwx7 commented 10 years ago

We need to get some communication going between the client and server, this will require a well documented API outlining what the server needs on a request from a client, what functions are available to a client (and the parameters for each of those requests) and then what a server request will return.

Wingie commented 10 years ago

i'd like to help out on this

nb333 commented 10 years ago

@Wingie Sounds great. I've assigned this task to you. :-)

Wingie commented 10 years ago

Thanks! had a few queries though.

  1. Does the server need to keep a track of each connected client? I am thinking that (in the future maybe) it would be useful to implement some sort of sessioning system where client id's itself to the server on connections and gets a sort of a session key that it has to use in all future requests?
  2. Would we be supporting HTTP and HTTPS? or only one of the two? or is this question redundant (by the very nature of the project)? [in case the answer is the last option, please excuse]
  3. Does the server need to treat AJAX requests differently from HTTP requests? i know the information will be there in the headers but you know.. Explicit is better than implicit.
  4. When a user requests a page, do we also encrypt-stego all assets/resources on the page. (css/js/images etc..) it doesn't make sense for the client to make multiple requests for all the assets. (the client can only make request for subsequent externally linked css/js files after receiving and decoding the request). maybe this could be an option on the client side. and server can respond as client requests.
  5. we can't do much if client wants a socket connection can we? i'm not very knowledgeable in this area but if a webpage opens up a websocket to another webpage/server - can we still provide security over that connection?
Sp3ctr3 commented 10 years ago
  1. Twisted keeps track of the clients and the endpoints. No need to do it manually. It does that till the connection is closed
  2. HTTP is working as of now. HTTPS is problematic. We are figuring out a way that does not involve certificate errors. If you have any ideas please do pitch in. 3.I'm not sure. What do you think? Which would be better?
  3. Yup. We're basically stegoing the entire page. Right now we're thinking of masking each request and stegoing them at server side. Again: please do suggest improvements wherever you see fit. 5:I guess not. The best we can do is HTTP proxying.
admwx7 commented 10 years ago

Expansion on Sp3ct3's answer:

  1. HTTPS when we can get it going.
  2. An AJAX request just makes a standardized HTTP request, HTTP is just the protocol AJAX (and other web services) use to make web requests.
  3. We're moving away from stego, no benefit when everyone knows we're using it...but one of the things that we really should do is to make all of the requests we can before we encrypt and respond to the client, for starters grab all CSS and JS then embed it into the file and respond, images will be a little trickier though and may be something we will have to implement at a later time. 5.I know very little about sockets, but from my understanding we can still configure the data to run through our server as though it was a standard proxy and add the extra security, not 100% on that though. This will probably have to be an implementation that happens later as well.
boxtown commented 10 years ago

(5). Webpages cannot open up sockets. Applications (browsers, etc.) open up sockets. If they are using a proxy (openfaux in this case), you will not have to worry about clients opening up direct socket connections to other servers. If they do, it is a conscious decision the client app does and not something a proxy has to worry about.

admwx7 commented 10 years ago

Problem solved then lol. On Dec 9, 2013 4:27 PM, "Michael Ma" notifications@github.com wrote:

  1. Webpages cannot open up sockets. Applications (browsers, etc.) open up sockets. If they are using a proxy (openfaux in this case), you will not have to worry about clients opening up direct socket connections to other servers. If they do, it is a conscious decision the client app does and not something a proxy has to worry about.

— Reply to this email directly or view it on GitHubhttps://github.com/openfaux/openfaux-server/issues/20#issuecomment-30180447 .

Wingie commented 10 years ago

i've done a first pass on the API over here. dd9197a37843508ea780a5996d75d089b385e247 i've also made some changes to testclient.py to illustrate usage.