HTTP Transport for the Skylive Protocol overview:
-------------------------------------------------


CLIENT                          SERVER

=================================================================|
_________________________________________                        |
                                         |                       |
      ------ GET /new  ------->          | Initialization new    |
      <----- TOKEN ------------          | connection            |  Request for a new
_________________________________________|                       |  Connection
                                                                 |
_________________________________________                        |
                                         |                       |
      ------ POST /auth ------->         | Authentication        |
      <-------- OK|kO ----------         | phase                 |
_________________________________________|                       |
                                                                 |
============================================================================================
_________________________________________                        |
                                         |                       |
      ------ POST /client ----->         | Client -> Server      |
      <-------- OK|KO --------           | communication channel |   Connection established
_________________________________________|                       |   data channels
                                                                 |
_________________________________________                        |
                                         |                       |
      ------ POST /server ----->         | Server -> Client      |
      <-------- DATA -----------         | communication channel |
_________________________________________|                       |
                                                                 |
=================================================================|


Description:


All the requests are encapsulated in a XML protocol to be definied.
Now we will use some example tags, they are not stable now.

Note: we use an authentication mechanism to establish our tunnel not for the real 
communication of user credential, but only to get a way to generate a key for 
encrypt the data inside the tunnel with a know key for both the peers without 
passing it on in clear text on the tunnel layer.
To do this we need to have something that both parts know before they 
try to establish a connection, and the only secrets things they know 
are the username ( that can't be used alone cause it pass over the protocol
in clear text) and the hash of the password ( that never pass in clear ).
Other transport (like the SSL/TLS one) can't need to pass
user/password information, so, the encapsulated protocol 
will need another and indipendent authentication mechanism.
Maybe we will try to find another solution in future.

Note 2: we try to use HTTP/1.1 to get more probability to 
have a working Keep-Alive HTTP support by our proxy.

------------------------------
Initialization new connection:
------------------------------

 * Client Request: 
   ---------------
    
    GET /new HTTP/1.1
 
  - Only to start a new connection.
 
 * Server response: 
   ----------------

    <response><token>TOKEN</token></response>
 
  - TOKEN is an unique id generated by the server and used by the client
    to identify a unique "connection". it is generated 

---------------------
Authentication phase:
---------------------

 * Client Request: 
   ---------------
      
     POST /auth HTTP/1.1

  - Data:
    o token=TOKEN (the one generated by the server in initialization)
    o user=USERNAME
    o hash=HASH (where HASH is the md5sum of a string composed 
                 by the TOKEN, USERNAME and the storated hash of the password)

 * Server Response:
   ----------------

     <response><auth>OK|KO</auth></response>

------------------------------
Data channel Client -> Server:
------------------------------

The client make a request that emulate a POST of a file with a fixed size.
When the size of the transfer will reach the size limit or if the upload in any way 
blocked and the connection goes down, it will re-establish a new one 
in a loop.

Also, we will maybe need to have a sort of keep-alive "ping-pong" system, but it can be 
demanded on the encapsulated protocol, like a sort of error correction and/or 
checksum for every bit of real communication in the encapsulated protocol.

 * Client Request:
   ---------------
   
     POST /client HTTP/1.1

   - Data:
     o token=TOKEN
     o data=DATA (where DATA is our encapsulated protocol encrypted with AES256 and encryption key 
                  generated by md5sum of token+hash of the password, packetized(1) and in base64)

  * Server Response:
    ----------------

      <response><client>OK|NO</client></response>


------------------------------
Data channel Server -> Client:
------------------------------

The client make a request that emulate the download of a big file. It is the exact
opposite with the client->server data channel, but with the same checksum, ping and other
considerations.

 * Client Request:
   ---------------

     POST /server HTTP/1.1

    - Data:
      o token=TOKEN
      o data=DATA (where DATA is used to check the identity of the client and is 
                   the token+the hash of the password encrypted in aes256 using the md5sum of 
                   the token+username+the hash of the password as key for encryption
                   in base64)

  * Server Response:
    ----------------
    
     an emulated  file download stream of the data encrypted with aes256 with the md5sum of 
     token+hash of the password as key, packetized(1) and in base64

--------------------
NOTE #1. Packetized:
--------------------
We choose to encrypt our data cause is the best way to be sure that noone can takeover our tunnel.
If we want to bypass at leas any proxy, we can't simply use SSL/TLS,  cause
we need to appears to the proxy like a normal http request in clear text, at least 
more close to a normal http stream that we can.
every splice of data is encrypted in AES256. As we don't know the exact lenght of any
splice of data, and aes256 can't decrypted dinamically, we need another way to 
know when to decrypt our data.
So,  we will "packetize" it in our data stream by converting every packet to 
base64, and we insert a separator to let's both client and server recognize where a packet
is complete and need to be decrypted.

TODO: Choose a separator!

ISSUE: won't this way to transport data add too many overhead? Isn't better to simply 
use connectSSL on the client and listenSSL on the server, and encapsulate the
stream a clear text simple http tunnel? But this way, how we can have the client ip
on the server side?

