Question

I want to set up a project page on GitHub, so that it acts as a live site.

The site would require an API sid & token (both just long strings of text) that, in a self-hosted environment, the user would just add to the config file.

If I host this through GitHub project pages, users will supply their sid/token through a form. The page with the form will need to be served over SSL so that the sid/token aren’t transferred as cleartext. The problem is that GitHub project pages don’t allow SSL.

So, if I can find another secure way to take input through a form aside from using SSL, then I can host this whole thing a hosted service through GitHub project pages.

The project would be open source, so I don’t expect any sort of encoding/hashing scheme to work, since the methods would be public.

The sid/token are being used in curl calls to an API which is sent over SSL. Perhaps there’s a way to direct the form input directly to that SSL URL instead of having it go through the non-SSL GitHub project page…

Any ideas?

Answer 1

You can just give the action attribute of the form the HTTPS URL of the target script, if that’s possible.

You could also use some kind of Challenge-Response encryption/hashing scheme using Javascript. The algorithm for that would be something like this:

1. Server generates unique, random token, saves it and sends it to the client along with the form HTML.
2. On the client side, Javascript intercepts the form submission and hashes the sensitive form data with the server-generated token as a salt.
3. Server can now check whether the hash is equal to its own calculated hash value

HOWEVER

A man-in-the-middle attacker with the ability to modify traffic (for example through ARP poisening, DHCP or DNS spoofing) could always strip all your client-side protection mechanisms from the served HTML. Have a look at SSLStrip for a tool to rewrite HTTPS URLs to unsecure HTTP URLs on the fly. The challenge-response could be defeated something like this:

1. Save token sent by the server, remove the Javascript from the HTML form.
2. As the form submission is not intercepted now, we get the raw input data.
3. Hash the data using the same algorithm that the Javascript would have performed.
4. Thank you for all the fish.

You see, an intercepting attacker can probably defeat any defense mechanism you try to make up.