Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Outline and document that API #20

Open
admwx7 opened this issue Dec 6, 2013 · 8 comments
Open

Outline and document that API #20

admwx7 opened this issue Dec 6, 2013 · 8 comments
Assignees
Labels

Comments

@admwx7
Copy link

admwx7 commented Dec 6, 2013

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
Copy link
Member

Wingie commented Dec 9, 2013

i'd like to help out on this

@ghost ghost assigned Wingie Dec 9, 2013
@nb333
Copy link
Member

nb333 commented Dec 9, 2013

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

@Wingie
Copy link
Member

Wingie commented Dec 9, 2013

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
Copy link
Contributor

Sp3ctr3 commented Dec 9, 2013

  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
Copy link
Author

admwx7 commented Dec 9, 2013

Expansion on Sp3ct3's answer:
2. HTTPS when we can get it going.
3. An AJAX request just makes a standardized HTTP request, HTTP is just the protocol AJAX (and other web services) use to make web requests.
4. 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
Copy link
Contributor

boxtown commented Dec 9, 2013

(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
Copy link
Author

admwx7 commented Dec 9, 2013

Problem solved then lol.
On Dec 9, 2013 4:27 PM, "Michael Ma" [email protected] 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//issues/20#issuecomment-30180447
.

@Wingie
Copy link
Member

Wingie commented Dec 15, 2013

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants