7.0 KiB
Сессии и все-все-все
Подпись
Серверная подпись
Сервер обязан заведомо иметь пару ключей своей подписи, прежде чем коммуницировать с кем-либо в принципе. Генерировать их желательно вручную, на этапе установки/настройки серверного ПО.
Обмен пакетами в неаутентифицированом соединении типа клиент-сервер
До выполнения аутентификации, сервер может, но не обязан, подписывать каждый свой пакет. Клиент не должен подписывать свои пакеты и должен устанавливать хэш полезной нагрузки в нулевое значение.
Сервер не должен проверять подпись пакетов клиента. Клиент может проверять подпись только в случае наличия у него открытого ключа сервера.
Регистрация
Перед инициированием процедуры регистрации, клиент запрашивает открытый ключ подписи сервера и тот отвечает событием, с открытым ключом в качестве основных данных и подписанным закрытым ключом хэшем полезной нагрузки. Клиент должен проверить подпись этого события с помощью публичного ключа из него-же.
В случае успешной регистрации, клиент генерирует публичный и приватный ключи подписи, после чего отправляет событие с публичным ключом в качестве основных данных и подписанным закрытым ключом хэшем полезной нагрузки на сервер. Сервер должен проверить подпись этого события с помощью публичного ключа из него-же.
Обмен пакетами в аутентифицированном соединении
Каждый принятый сервером пакет, содержащий хэш полезной нагрузки, должен проверяться на соответствие подписи, путём расшифровки этого хэша открытом ключом подписи и последующего сравнения с реальным хэшем полезной нагрузки. Если сервер обнаруживает, что подпись неверна - сервер отвечает ошибкой, добавляет запись об инциденте в журнал, а обрабатываемый пакет игнорируется.
Каждый принятый клиентом пакет, содержащий хэш полезной нагрузки, должен быть проверен на соответствие подписи. Если клиент обнаруживает, что подпись неверна - он уведомляет об этом пользователя, а обрабатываемый пакет игнорируется.
Наглядные примеры работы с подписями
Отправка подписанного пакета
При отправке сообщения клиентом A клиенту Б, оно проходит следующую цепочку:
- Клиент А посылает пакет с подписанным хэшем полезной нагрузки (далее - ХПН) и подписанными основными данными (как часть содержания полезной нагрузки), на свой хоумсервер (место, где клиент А аутентифицирован, далее - ХС А).
- ХС A проверяет ХПН на валидность. Допустим, что подпись верна.
- ХС А совершает релевантные действия, исходя из содержания и типа события.
- ХС А переподписывает ХПН с использованием свой подписи.
- ХС А отправляет переподписанный пакет хоумсерверу клиента Б (далее - ХС Б).
- ХС Б проверяет ХПН на валидность. Допустим, что подпись верна.
- ХС Б совершает релевантные действия, исходя из содержания и типа пакета.
- ХС Б переподписывает пакет с использованием своей подписи.
- ХС Б отправляет переподписанный пакет клиенту Б.
- Клиент Б проверяет ХПН на валидность. Допустим, что подпись верна.
- Клиент Б проверяет подпись основных данных, на предмет соответствия подписи клиента А и совершает релевантные действия.
Серверные сессии и их идентификаторы
При аутентификации клиента на сервере, сервер генерирует и отправляет клиенту уникальный идентификатор серверной сессии, который также ассоциирует с текущим подключением клиента.
После успешной аутентификации, клиент обязан прилагать назначенный ему ID серверной сессии к каждому пакету.
Если при проверке ID серверной сессии в пакете обнаруживается её отсутствие среди пулла серверных сессий - сервер отвечает ошибкой, соединение разрывается.
Две серверные сессии не должны иметь одинаковое значение ID ни при каких условиях.
Разные подключения одного клиента должны иметь одинаковую ассоциированную сессию.