HTTPS over HTTP или как уместить рукопожатие в одном HTTP-запросе?
Собственно, задача:
Есть парк разномастных сайтов. Одни крутятся на shared-хостингах, другие на VPS/Dedic'ах, третьи вообще могут быть разнесены через балансировщик. На каждом сайте по запросу по определённому урлу будет запускаться полный бекап. За эти запросы будет отвечать отдельный сервер-планировщик.
По этому запросу можно будет легко DDoS'ом положить любой из этих сайтов, ибо lockfile невозможно использовать в связи с тем, что многие из них разнесены через балансировщик, а создавать отдельную сущность в БД устроит не всех владельцев сайтов. Далеко не все сайты поддерживают HTTPS. Зато есть возможность положить любое количество наборов ключей шифрования.
Из вышеперечисленного есть выводы:
1) обычная аутентификация по ключу, сохранённому в приложении (вида /make_backup?key=0f0f0f0f0f0f0f0f0) не подходит, т.к. при перехвате этого ключа (через тот же MitM) сайт можно легко уложить.
2) сделать подобие HTTPS-рукопожатия через HTTP GET-параметры я тоже не могу (с учётом того, что у планировщика и сайта есть весь необходимый набор ключей), т.к. там необходимо как минимум чтобы на запрос планировщика сайт отвечал случайной строкой, зашифрованной их парой ключей, но планировщику для аутентификации эту случайную строку снова нужно сайту отправить, а на сайте её негде хранить для второго запроса.
Собственно, как можно в таких условиях устроить аутентификацию?
защита по айпи
https сделайте везде
сказать честно ваш школьный костыль крайне не сочетается с фразой коммерческая отвественность
разверните нормальную симстему бекапа
@opium сабж нужен для облачного сервиса бекапов. сайты - клиенты, у них если нет HTTPS, то и не будет. про школьность - ваше личное мнение, в ваших словах я профессионализма не особо увидел.
@opium свой хттпс? каким образом? вы понимаете устройство хттпс? он в первую очередь гарантирует клиенту аутентичность сервера (при условии авторитетности подписи сертификата), во вторую шифрует соединение. он не гарантирует серверу аутентичность клиента, это уже делает переданный по защищённому каналу токен сессии. у меня обратная задача: мне нужно аутентифицировать клиента (сервер-планировщик) для сервера (сайт). и всё это в условиях отсутствия родной поддержки HTTPS сервером.
Сделайте в скрипте генерацию одноразовых паролей, основываясь, например на времени.
Сервер делает запросы с этим ключом, клиент проверяет все ли хорошо, и если да - выполняется.
Это как минимум усложнит жизнь тому MitM.
Согласен с V2NEK, можно просто по заранее определенному алгоритму шифровать (хешировать) UNIXTIME и при запросе сверять его. От MItM атаки может уберечь.
Средний
Средний
