Использование HTTPS для связи клиент-сервер

Question

Я хотел бы использовать HTTPS для обеспечения связи между моим клиентом и сервером. Первое зашифрованное сообщение будет использоваться для аутентификации пользователя, то есть проверки его/ее имени пользователя и пароля.

После того, как учетные данные пользователя будут успешно проверены сервером, я хотел бы начать получать некоторые данные в последующих запросах. НО, как сервер будет определять, что последующий запрос отправляется пользователем, чьи учетные данные уже были проверены?

Поскольку соединение TCP может быть закрыто между логином и последующими HTTPS-запросами, это означает, что контекст SSL должен быть освобожден сервером, поэтому с новым запросом GET необходимо установить новое TCP-соединение и должно быть выполнено новое соединение SSL (TLS) (т.е. новый общий пароль для шифрования должен быть заменен обеими сторонами и т. д.)

Для этого я думаю, что серверу необходимо отправить обратно клиенту ответ 200 OK для первоначальная проверка подлинности требует некоторого произвольно сгенерированного nonce (который действителен в течение определенного времени), который я буду включать в каждый последующий запрос, поэтому сервер сможет обнаруживать на основе этого случайно сгенерированного nonce, какое имя пользователя находится за запросом и убедитесь, что этот пользователь уже вошел в систему. I Насколько я понимаю?

Большое спасибо за ответ BR Sten

Answer 1

Самый простой способ не требует все коммуникации, чтобы перейти через HTTPS (поэтому данные являются конфиденциальными, никто, кроме клиента и сервер может видеть) и использовать простые имя пользователя и пароль по каждому запросу внутри этого безопасного соединения. Это практически невозможно сделать на практике (имя пользователя и пароль действительно передают соединение как HTTP-заголовок, что здесь ОК, потому что мы используем HTTPS), и сервер может проверять каждый раз, когда разрешен пользователю. Вам не нужно беспокоиться о рукопожатиях SSL; это уровень SSL/HTTPS-уровня (и поэтому HTTPS/SSL - nice).

В качестве альтернативы, вход в систему может быть выполнен любым способом и сгенерировать магическое число (например, UUID или криптографический хеш случайного числа и имя пользователя), который хранится в файле cookie сеанса. Последующие запросы могут просто проверить, что магический номер - тот, который он распознает с начала сеанса (и что с момента его выдачи прошло слишком много времени); logout просто забывает магическое число на стороне сервера (и просит клиента забыть тоже). Это немного больше, чтобы реализовать это, но все еще не сложно, и есть библиотеки для серверной стороны для обработки работы осла.

Первый вариант особенно хорош для того, где вы пишете что-то, что будет использоваться другими программами, поскольку его очень легко реализовать. Второй вариант лучше, когда клиент является веб-браузером, поскольку он дает пользователям больше контроля, когда их браузер разрешен (программные API не так уж нужны). Всякий раз, когда клиент будет браузером, вам нужно также позаботиться о защите от других видов атак (например, различные типы подделок запроса), но это почти не зависит от всего остального.

Answer 2

Изобретение пользовательского механизма аутентификации в вашем случае очень рискованно - легко ошибиться, что позволит делать много ошибок. Таким образом, правильный подход, как и мне, заключается в использовании HTTPS и передаче пользовательских учетных данных с каждым запросом.