# Сессии и все-все-все

## Подпись

### Серверная подпись

Сервер обязан заведомо иметь пару ключей своей подписи, прежде чем коммуницировать с кем-либо в принципе. Генерировать их желательно вручную, на этапе установки/настройки серверного ПО.

### Обмен пакетами в неаутентифицированом соединении типа клиент-сервер

До выполнения аутентификации, сервер может, но не обязан, подписывать каждый свой пакет. Клиент не должен подписывать свои пакеты и должен устанавливать хэш полезной нагрузки в нулевое значение.

Сервер не должен проверять подпись пакетов клиента. Клиент может проверять подпись только в случае наличия у него открытого ключа сервера.

### Регистрация

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

<!-- TODO: оговорка про способы регистрации? -->

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

<!-- TODO: оговорка про способы аутентификации? -->

### Обмен пакетами в аутентифицированном соединении

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

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

### Наглядные примеры работы с подписями

#### Отправка подписанного пакета

При отправке сообщения клиентом A клиенту Б, оно проходит следующую цепочку:

1. Клиент А посылает пакет с подписанным хэшем полезной нагрузки (далее - ХПН) и подписанными основными данными (как часть содержания полезной нагрузки), на свой хоумсервер (место, где клиент А аутентифицирован, далее - ХС А).
2. ХС A проверяет ХПН на валидность. Допустим, что подпись верна.
3. ХС А совершает релевантные действия, исходя из содержания и типа события.
4. ХС А переподписывает ХПН с использованием свой подписи.
5. ХС А отправляет переподписанный пакет хоумсерверу клиента Б (далее - ХС Б).
6. ХС Б проверяет ХПН на валидность. Допустим, что подпись верна.
7. ХС Б совершает релевантные действия, исходя из содержания и типа пакета.
8. ХС Б переподписывает пакет с использованием своей подписи.
9. ХС Б отправляет переподписанный пакет клиенту Б.
10. Клиент Б проверяет ХПН на валидность. Допустим, что подпись верна.
11. Клиент Б проверяет подпись основных данных, на предмет соответствия подписи клиента А и совершает релевантные действия.

<!-- TODO: решить: как и нужно-ли, чтобы сервер являлся средой нулевого доверия в плане передачи подписей пользователей (скорее всего "Да.") -->



## Серверные сессии и их идентификаторы

При аутентификации клиента на сервере, сервер генерирует и отправляет клиенту уникальный идентификатор серверной сессии, который также ассоциирует с текущим подключением клиента.

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

Если при проверке ID серверной сессии в пакете обнаруживается её отсутствие среди пулла серверных сессий - сервер отвечает ошибкой, соединение разрывается.

Две серверные сессии не должны иметь одинаковое значение ID ни при каких условиях.

Разные подключения одного клиента должны иметь одинаковую ассоциированную сессию.