HTTPS over HTTP or how to fit a handshake in one HTTP request?

Question

Information Security

Actually, the task:

There is a park of various sites. Some are spinning on shared hostings, others on VPS/Dedics, others can even be spaced through a balancer. On each site, upon request, a full backup will be launched at a specific URL. A separate scheduler server will be responsible for these requests.

At this request, it will be easy to DDoS any of these sites, because lockfile cannot be used due to the fact that many of them are distributed through a balancer, and not all site owners will be satisfied with creating a separate entity in the database. Not all sites support HTTPS. But it is possible to put any number of sets of encryption keys.

From the above, there are conclusions:

1) basic authentication using a key stored in the application (of the form /make_backup?key=0f0f0f0f0f0f0f0f0) is not suitable, because when this key is intercepted (through the same MitM), the site can be easily laid down.

2) I also can’t make a semblance of an HTTPS handshake through HTTP GET parameters (taking into account the fact that the scheduler and the site have all the necessary set of keys), because there it is necessary at least that the site responds to the scheduler's request with a random string encrypted with their key pair, but the scheduler needs to send this random string to the site again for authentication, and there is nowhere to store it on the site for the second request.

Actually, how can you arrange authentication in such conditions?

Answer 1

just do a web authorization

Answer 2

Make the script generate one-time passwords based, for example, on time.
The server makes requests with this key, the client checks if everything is fine, and if so, it is executed.
This will at least complicate the life of that MitM.

Answer 3

I agree with V2NEK , you can simply encrypt (hash) UNIXTIME using a predetermined algorithm and verify it when requested. It can save you from MItM attacks.