63 lines
7.0 KiB
Markdown
63 lines
7.0 KiB
Markdown
# Сессии и все-все-все
|
||
|
||
## Подпись
|
||
|
||
### Серверная подпись
|
||
|
||
Сервер обязан заведомо иметь пару ключей своей подписи, прежде чем коммуницировать с кем-либо в принципе. Генерировать их желательно вручную, на этапе установки/настройки серверного ПО.
|
||
|
||
### Обмен пакетами в неаутентифицированом соединении типа клиент-сервер
|
||
|
||
До выполнения аутентификации, сервер может, но не обязан, подписывать каждый свой пакет. Клиент не должен подписывать свои пакеты и должен устанавливать хэш полезной нагрузки в нулевое значение.
|
||
|
||
Сервер должен не проверять подпись пакетов клиента. Клиент должен проверять подпись только в случае наличия у него открытого ключа сервера.
|
||
|
||
### Регистрация
|
||
|
||
Перед инициированием процедуры регистрации, клиент запрашивает открытый ключ подписи сервера и тот отвечает событием, с открытым ключом в качестве основных данных и подписанным закрытым ключом хэшем полезной нагрузки. Клиент должен проверить подпись этого события с помощью публичного ключа из него-же.
|
||
|
||
<!-- TODO: оговорка про способы регистрации? -->
|
||
|
||
В случае успешной регистрации, клиент генерирует публичный и приватный ключи подписи, после чего отправляет событие с публичным ключом в качестве основных данных и подписанным закрытым ключом хэшем полезной нагрузки на сервер. Сервер должен проверить подпись этого события с помощью публичного ключа из него-же.
|
||
|
||
<!-- TODO: оговорка про способы аутентификации? -->
|
||
|
||
### Обмен пакетами в аутентифицированном соединении
|
||
|
||
Каждый принятый сервером пакет, содержащий хэш полезной нагрузки, должен проверяться на соответствие подписи, путём расшифровки этого хэша открытом ключом подписи и последующего сравнения с реальным хэшем полезной нагрузки. Если сервер обнаруживает, что подпись неверна - сервер отвечает ошибкой, добавляет запись об инциденте в журнал, а обрабатываемый пакет игнорируется.
|
||
|
||
Каждый принятый клиентом пакет, содержащий хэш полезной нагрузки, должен быть проверен на соответствие подписи. Если клиент обнаруживает, что подпись неверна - он уведомляет об этом пользователя, а обрабатываемый пакет игнорируется.
|
||
|
||
### Наглядные примеры работы с подписями
|
||
|
||
#### Отправка подписанного пакета
|
||
|
||
При отправке сообщения клиентом A клиенту Б, оно проходит следующую цепочку:
|
||
|
||
1. Клиент А посылает пакет с подписанным хэшем полезной нагрузки (далее - ХПН) и подписанными основными данными (как часть содержания полезной нагрузки), на свой хоумсервер (место, где клиент А аутентифицирован, далее - ХС А).
|
||
2. ХС A проверяет ХПН на валидность. Допустим, что подпись верна.
|
||
3. ХС А совершает релевантные действия, исходя из содержания и типа события.
|
||
4. ХС А переподписывает ХПН с использованием свой подписи.
|
||
5. ХС А отправляет переподписанный пакет хоумсерверу клиента Б (далее - ХС Б).
|
||
6. ХС Б проверяет ХПН на валидность. Допустим, что подпись верна.
|
||
7. ХС Б совершает релевантные действия, исходя из содержания и типа пакета.
|
||
8. ХС Б переподписывает пакет с использованием своей подписи.
|
||
9. ХС Б отправляет переподписанный пакет клиенту Б.
|
||
10. Клиент Б проверяет ХПН на валидность. Допустим, что подпись верна.
|
||
11. Клиент Б проверяет подпись основных данных, на предмет соответствия подписи клиента А и совершает релевантные действия.
|
||
|
||
<!-- TODO: решить: как и нужно-ли, чтобы сервер являлся средой нулевого доверия в плане передачи подписей пользователей (скорее всего "Да.") -->
|
||
|
||
|
||
|
||
## Серверные сессии и их идентификаторы
|
||
|
||
При аутентификации клиента на сервере, сервер генерирует и отправляет клиенту уникальный идентификатор серверной сессии, который также ассоциирует с текущим подключением клиента.
|
||
|
||
После успешной аутентификации, клиент обязан прилагать назначенный ему ID серверной сессии к каждому пакету.
|
||
|
||
Если при проверке ID серверной сессии в пакете обнаруживается её отсутствие среди пулла серверных сессий - сервер отвечает ошибкой, соединение разрывается.
|
||
|
||
Две серверные сессии не должны иметь одинаковое значение ID ни при каких условиях.
|
||
|
||
Разные подключения одного клиента должны иметь одинаковую ассоциированную сессию. |