Secure Haxe Remoting

[kevin...@gmail.com]

I have successfully set up my remoting servicing following the instructions on http://haxe.org/doc/remoting/client_server. Next step I am trying to do some secured remoting using some sort of public-private-key algorithms. Any idea where should I start? Do I have to write my own "Connection" class?

[Jason O'Neil]

Hi Kevin

I don't imagine you would have to override the HttpConnection class on the server.  For myself I simply used regular cookies that also went with my web-app - if they were logged into the website, they had a cookie with the session ID.  In my remoting API I would check the cookie and verify that they had a valid session before allowing them to make calls that require authentication.  If your entire API needs authentication, you could also check that before you call `HttpConnection.handleRequest(ctx)`, and then not worry about it in your connection.

Remoting connections are standard HttpRequests, so you can pass information (such as user/password, or key info) via either GET, POST or COOKIE.  If you want to integrate this into the remoting call, cookies are sent automatically, or you could extend `haxe.remoting.HttpAsyncConnection` and override the `call` method to send a custom GET or POST parameter, which you can process on the server.  You could even use custom HTTP headers or built in Http authentication if you wanted.

That would allow you to send some data from the client to the server, and use it to authenticate on your server before doing a remoting call.  The next question is how to do private/public keys.  I'm not sure what the best approach is here, because I stuck with a more traditional user/pass/session model.  I guess in that model a SessionID really is like a temporary key in some ways.  I would be interested to hear what you decide on though!

Jason

On Fri, Oct 4, 2013 at 11:17 AM, <kevin...@gmail.com> wrote:

I have successfully set up my remoting servicing following the instructions on http://haxe.org/doc/remoting/client_server. Next step I am trying to do some secured remoting using some sort of public-private-key algorithms. Any idea where should I start? Do I have to write my own "Connection" class?

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/groups/opt_out.

[Dion Whitehead Amago]

Use https?

[Jason O'Neil]

On Fri, Oct 4, 2013 at 11:42 AM, Dion Whitehead Amago <dio...@gmail.com> wrote:

Use https?

And that ;)

[kevin...@gmail.com]

Hi Jason,

Thanks for your prompt and informative reply. 

Actually I'm quite new to Http / connection stuffs, however I've been doing some reading on this topic and wish to know more. Please forgive me if I am asking the wrong question

What I am experimenting on is an mobile app (AIR target at the moment) which requires login to do various actions like retrieving info and uploading info (think about the facebook app). I would like secure the messages transmitted, but I cannot use a symmetric encryption (like the default haxe serializer, if you treat that as some sort of "encryption") due to the swf insecurity. That's why I go for the public-private key solution.

I am not sure if the user/pass/session model applies on this case? I have only done similar things on desktop websites but not on mobile app.

I would like to know more about Https in this case too, does that mean I can simply use the https protocol through the HttpConnection class?

Kevin

[Juraj Kirchheim]

Why not just use https instead of reinventing the wheel and probably
introducing more vulnerability and runtime overhead (compared to
natively supported solutions)?

Asymmetric encryption is prone to man-in-the-middle attacks which is
why you need some type of public key infrastructure. Most browsers are
explicitly built against one and I would assume that's true for AIR
also.

Regards,
Juraj

[kevin...@gmail.com]

My concern is the cost of https and seems that it won't work on shared hosting.

My basic idea is to encrypt the string serialized by the haxe serializer and then send it out, and decrypt before the haxe unserializer do its job. I think is is pretty straight forward and shouldn't introduce much drawbacks.