Сессии, ID, аутентификация и прочее
This commit is contained in:
parent
8e70978778
commit
476dda2e30
@ -4,37 +4,6 @@
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
#### ID
|
|
||||||
|
|
||||||
Класс, реализующий абстракцию над более конкретными типами идентификаторов. В этой спецификации указывается в качестве типа в тех случаях, когда применим любой из трёх типов.
|
|
||||||
|
|
||||||
```C++
|
|
||||||
class ID {
|
|
||||||
private:
|
|
||||||
uint64_t object_id, server_id;
|
|
||||||
std::string server_domain;
|
|
||||||
public:
|
|
||||||
ID (uint64_t oid, uint64_t sid, std::string sd) {
|
|
||||||
this->object_id = oid;
|
|
||||||
this->server_id = sid;
|
|
||||||
this->server_domain = sd;
|
|
||||||
}
|
|
||||||
LocID GetValue () { return this->object_id; }
|
|
||||||
FedID GetValue () {
|
|
||||||
FedID fid;
|
|
||||||
fid.Object = this->object_id;
|
|
||||||
fid.Server = this->server_id;
|
|
||||||
return fid;
|
|
||||||
}
|
|
||||||
GlobID GetValue () {
|
|
||||||
GlobID gid;
|
|
||||||
gid.Object = this->object_id;
|
|
||||||
gid.Server = this->server_domain;
|
|
||||||
return gid;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
#### LocID
|
#### LocID
|
||||||
|
|
||||||
Идентификатор локального для конкретного сервера объекта.
|
Идентификатор локального для конкретного сервера объекта.
|
||||||
@ -43,25 +12,15 @@ class ID {
|
|||||||
typedef uint64_t LocID;
|
typedef uint64_t LocID;
|
||||||
```
|
```
|
||||||
|
|
||||||
#### FedID
|
|
||||||
|
|
||||||
Идентификатор объекта в пределах федерации.
|
|
||||||
|
|
||||||
```C++
|
|
||||||
typedef struct {
|
|
||||||
uint64_t Object;
|
|
||||||
uint64_t Server;
|
|
||||||
} FedID;
|
|
||||||
```
|
|
||||||
|
|
||||||
#### GlobID
|
#### GlobID
|
||||||
|
|
||||||
Идентификатор объекта за пределами федерации.
|
Идентификатор глобального объекта.
|
||||||
|
|
||||||
```C++
|
```C++
|
||||||
typedef struct {
|
typedef struct {
|
||||||
uint64_t Object;
|
uint64_t Object;
|
||||||
std::string Server; // Доменное имя целевого сервера
|
std::string Server; // Доменное имя сервера-владельца объекта
|
||||||
} GlobID;
|
} GlobID;
|
||||||
```
|
```
|
||||||
|
|
||||||
@ -75,7 +34,7 @@ typedef struct {
|
|||||||
- `0b10000000000000000000000000000000`: изменение прав доступа
|
- `0b10000000000000000000000000000000`: изменение прав доступа
|
||||||
- `0b01111111111111111111111111111000`: нераспределено
|
- `0b01111111111111111111111111111000`: нераспределено
|
||||||
|
|
||||||
Нераспределённые флаги могут быть использованы в SPX.
|
Нераспределённые флаги могут быть использованы в расширениях протокола.
|
||||||
|
|
||||||
```C++
|
```C++
|
||||||
typedef uint32_t Power;
|
typedef uint32_t Power;
|
||||||
|
|||||||
20
HANDSHAKE.md
20
HANDSHAKE.md
@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
После успешной установки защищённого соединения, происходит обмен характеристиками обоих сторон, AKA "рукопожатие". Запрашивающий соединение отправляет пакет следующего формата:
|
После успешной установки защищённого соединения, происходит обмен характеристиками обоих сторон, AKA "рукопожатие". Запрашивающий соединение отправляет пакет следующего формата:
|
||||||
|
|
||||||
`[magic number: 8B][protocol version: 4B][sizes: 1B][crypto params: 2B][reconnection flags: 2B]`
|
`[magic number: 8B][protocol version: 4B][sizes: 1B][crypto params: 2B][reconnection flags: 4B]`
|
||||||
|
|
||||||
- Магическое число
|
- Магическое число
|
||||||
- _Тип:_ `uint64_t`
|
- _Тип:_ `uint64_t`
|
||||||
@ -33,17 +33,17 @@
|
|||||||
- _Тип:_ `uint16_t`
|
- _Тип:_ `uint16_t`
|
||||||
- Описывает используемые криптографические алгоритмы.
|
- Описывает используемые криптографические алгоритмы.
|
||||||
- Если равно нулю, то используются опции данной версии протокола по умолчанию
|
- Если равно нулю, то используются опции данной версии протокола по умолчанию
|
||||||
<!-- TODO -->
|
<!-- TODO: какие алгоритмы, КАКИЕ КОРАБЛИ, СУКА -->
|
||||||
- Флаги переподключения
|
- Флаги переподключения
|
||||||
- _Тип:_ `uint16_t`
|
- _Тип:_ `uint32_t`
|
||||||
- Описывает параметры нового подключения:
|
- Описывает параметры нового подключения:
|
||||||
- `0b0000000000000000`: оставить текущее подключение
|
- `0b00000000000000000000000000000000`: оставить текущее подключение
|
||||||
- `0b0000000000000001`: переподключиться к тому-же порту
|
- `0b00000000000000000000000000000001`: переподключиться к тому-же порту
|
||||||
- `0b0000000000000010`: запросить новый порт для подключения
|
- `0b00000000000000000000000000000010`: запросить новый порт для подключения
|
||||||
- `0b0000000000000100`: использовать TCP
|
- `0b00000000000000000000000000000100`: использовать TCP
|
||||||
- `0b0000000000001000`: использовать TLS
|
- `0b00000000000000000000000000010000`: использовать TLS
|
||||||
- `0b0000111111110000`: резерв под расширение
|
- `0b00001111111111111111111111101000`: резерв под расширение
|
||||||
- `0b1111000000000000`: резерв под под нужды сторонних реализаций
|
- `0b11110000000000000000000000000000`: резерв под под нужды сторонних реализаций
|
||||||
|
|
||||||
На что целевой сервер отвечает пакетом либо с согласием, либо ошибкой.
|
На что целевой сервер отвечает пакетом либо с согласием, либо ошибкой.
|
||||||
|
|
||||||
|
|||||||
@ -6,7 +6,7 @@
|
|||||||
|
|
||||||
- Data
|
- Data
|
||||||
- _Значение:_ `0x01`
|
- _Значение:_ `0x01`
|
||||||
- _Тип:_ любой
|
- _Тип:_ не имеет значения
|
||||||
- Основные передаваемые данные.
|
- Основные передаваемые данные.
|
||||||
- ObjectID
|
- ObjectID
|
||||||
- _Значение:_ `0x02`
|
- _Значение:_ `0x02`
|
||||||
@ -46,4 +46,8 @@
|
|||||||
- CryptoKeyID
|
- CryptoKeyID
|
||||||
- _Значение:_ `0x12`
|
- _Значение:_ `0x12`
|
||||||
- _Тип:_ `uint32_t`
|
- _Тип:_ `uint32_t`
|
||||||
- Идентификатор используемого криптографического ключа для шифрования данных.
|
- Идентификатор используемого криптографического ключа для шифрования данных.
|
||||||
|
- SignedHash
|
||||||
|
- _Значение:_ `0x13`
|
||||||
|
- _Тип:_ не имеет значения
|
||||||
|
- Хэш основных передаваемых данных, зашифрованный закрытым ключом отправителя.
|
||||||
42
OVERVIEW.md
42
OVERVIEW.md
@ -1,6 +1,6 @@
|
|||||||
# Спецификация протокола Stadium v1.0
|
# Спецификация протокола Stadium v1.0
|
||||||
|
|
||||||
Протокол Stadium это протокол для безопасной коммуникации общего назначения, работающий поверх любого поддерживаемого транспорта. Данная спецификация описывает лишь базу, поверх которой может быть реализованы расширения (SPX - Stadium Protocol eXtension) для более конкретных нужд. Помимо прочего, данный протокол служит основой для полнофункционального мессенджера Marafon, спецификация расширения которого находится в папке `Marafon SPX`.
|
Протокол Stadium это протокол для безопасной коммуникации общего назначения, работающий поверх любого поддерживаемого транспорта. Данная спецификация описывает лишь базу, поверх которой может быть реализованы расширения (SPX - Stadium Protocol eXtension) для более конкретных нужд. Помимо прочего, данный протокол служит основой для полнофункционального мессенджера Marafon, спецификация расширения которого находится в папке `SPX/Marafon/`.
|
||||||
|
|
||||||
_Здесь описана спецификация базового протокола; документация касательно версии протокола используемой в мессенджере размещена в другом репозитории._
|
_Здесь описана спецификация базового протокола; документация касательно версии протокола используемой в мессенджере размещена в другом репозитории._
|
||||||
|
|
||||||
@ -89,6 +89,8 @@ _Здесь описана спецификация базового прото
|
|||||||
- Категории `0x12-0x1F` (включительно)
|
- Категории `0x12-0x1F` (включительно)
|
||||||
- Все субкатегории: для событий ошибок и предупреждений.
|
- Все субкатегории: для событий ошибок и предупреждений.
|
||||||
|
|
||||||
|
<!-- TODO: событие запроса всех сервисов на сервере -->
|
||||||
|
|
||||||
### Зарезервированные ключи ячеек
|
### Зарезервированные ключи ячеек
|
||||||
|
|
||||||
У данных в формате KLDR также существуют зарезервированные ключи, которые аналогичным образом помещаются в минимальную размерность ключа:
|
У данных в формате KLDR также существуют зарезервированные ключи, которые аналогичным образом помещаются в минимальную размерность ключа:
|
||||||
@ -106,7 +108,7 @@ _Здесь описана спецификация базового прото
|
|||||||
|
|
||||||
## Соединение, аутентификация и сессии
|
## Соединение, аутентификация и сессии
|
||||||
|
|
||||||
Первичное подключение к серверу может выполнятся разными способами, в том числе подразумевающими маскировку траффика под существующие протоколы, но при использовании вне локальных сетей - должно сводиться к установке защищённого соединения.
|
Первичное подключение к серверу может выполнятся разными способами, в том числе подразумевающими маскировку траффика под существующие протоколы, но при использовании вне локальных сетей - должно сводиться к установке защищённого соединения. В будущем также будет реализован слой сквозного шифрования уровня "клиент-сервер", но, до этого момента, предполагается использование сторонних решений.
|
||||||
|
|
||||||
### Рукопожатие
|
### Рукопожатие
|
||||||
|
|
||||||
@ -118,44 +120,28 @@ _Здесь описана спецификация базового прото
|
|||||||
|
|
||||||
<!-- TODO -->
|
<!-- TODO -->
|
||||||
|
|
||||||
### Сессии и подпись
|
### Сессии и подписи
|
||||||
|
|
||||||
Пример работы подписи; при отправке сообщения клиентом другому клиенту, оно проходит следующую цепочку:
|
См. `SESSIONS.md`.
|
||||||
|
|
||||||
1. Клиент-отправитель посылает пакет с подписанной полезной нагрузкой (далее - ППН) и подписанными основными данными (как часть содержания ППН), на свой хоумсервер (далее - ХС; место, где клиент аутентифицирован).
|
|
||||||
2. ХС проверяет подпись ППН на валидность. Допустим, что подпись верна.
|
|
||||||
3. ХС совершает релевантные действия, исходя из содержания и типа события.
|
|
||||||
4. ХС переподписывает пакет с использованием свой подписи.
|
|
||||||
5. ХС отправляет переподписанный пакет целевому серверу (далее - ЦС).
|
|
||||||
6. ЦС проверяет подпись ППН на валидность. Допустим, что подпись верна.
|
|
||||||
7. ЦС совершает релевантные действия, исходя из содержания и типа пакета.
|
|
||||||
8. ЦС переподписывает пакет с использованием своей подписи.
|
|
||||||
9. ЦС отправляет переподписанный пакет целевому клиенту (далее - ЦК).
|
|
||||||
10. ЦК проверяет подпись ППН на валидность. Допустим, что подпись верна.
|
|
||||||
11. ЦК проверяет подпись основных данных, на предмет соответствия подписи клиента-отправителя и совершает релевантные действия.
|
|
||||||
|
|
||||||
Каждый принятый сервером пакет, содержащий хэш полезной нагрузки, должен проверяться на соответствие подписи, путём расшифровки этого хэша открытом ключом подписи и последующего сравнения с реальным хэшем полезной нагрузки. Если сервер обнаруживает, что подпись неверна - сервер отвечает ошибкой, добавляет запись в журнал об инциденте, а обрабатываемый пакет игнорируется.
|
|
||||||
|
|
||||||
Каждый принятый клиентом пакет, содержащий хэш полезной нагрузки, должен быть проверен на соответствие подписи. Если клиент обнаруживает, что подпись неверна - он уведомляет об этом пользователя, а обрабатываемый пакет игнорируется.
|
|
||||||
|
|
||||||
<!-- TODO: решить: как и нужно-ли, чтобы сервер являлся средой нулевого доверия в плане передачи подписей пользователей (скорее всего "Да.") -->
|
|
||||||
|
|
||||||
Если при проверке ID серверной сессии обнаруживается несоответствие - сервер отвечает ошибкой, соединение разрывается.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Система идентификаторов
|
## Система идентификаторов
|
||||||
|
|
||||||
Практически каждый объект в Stadium имеет свой уникальный идентификатор, по которому к нему (объекту) следует обращаться. Идентификаторы делятся на два типа: локальные и федеративные.
|
Практически каждый объект в Stadium имеет свой уникальный идентификатор, по которому к нему (объекту) следует обращаться. Идентификаторы делятся на три типа: локальные и глобальные.
|
||||||
|
|
||||||
Первый тип является восьмибайтным числом без знака (`uint64_t`). Валидный объект не может иметь ID равный нулю.
|
Первый тип является восьмибайтным числом без знака (`uint64_t`). Валидный объект не может иметь ID равный нулю.
|
||||||
|
|
||||||
Второй тип является структурой из двух восьмибайтных чисел без знака, кои являют из себя ID объекта и ID федерируемого сервера соответственно.
|
Второй тип является структурой из одного восьмибайтного числа без знака и строки в кодировке ASCII, кои являют из себя ID объекта и доменное имя сервера соответственно.
|
||||||
|
|
||||||
ID федерируемого сервера определяется сервером при первой попытке коммуникации и ассоциировано с его подписью, списком доменов и IP-адресов.
|
|
||||||
|
|
||||||
Сервер должен проверять идентификатор на валидность и отвергать его, если он не валиден в текущем контексте.
|
Сервер должен проверять идентификатор на валидность и отвергать его, если он не валиден в текущем контексте.
|
||||||
|
|
||||||
|
### Доменные имена
|
||||||
|
|
||||||
|
Доменное имя может быть ассоциированно как сервером, так и клиентом с несколькими другими альтернативными доменными именами, связанными с этим сервером.
|
||||||
|
|
||||||
|
Сервер может отправить подписанное событие другому серверу, с целью ассоциировать новое доменное имя со старым, к примеру, если старое более не актуально. Сервер-получатель события обязан не только проверить подпись, но провести проверку доменного имени на его соответствие серверу-отправителю, путём отправки события с запросом подписи сервера. Это событие должно по умолчанию иметь жёсткий рейт-лимит по критерию запрашиваемого домена, т.е. не более 10 проверок одного доменного имени в час.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Список ToDo (To Document)
|
## Список ToDo (To Document)
|
||||||
|
|||||||
@ -1,5 +1,5 @@
|
|||||||
# marafon-proto-specs
|
# Stadium Protocol
|
||||||
|
|
||||||
Спецификация протокола "Марафона".
|
Спецификация протокола Stadium и его официального расширения для нашего мессенджера - Marafon SPX.
|
||||||
|
|
||||||
**ПРОЕКТ В АКТИВНОЙ РАЗРАБОТКЕ**
|
**ПРОЕКТ В АКТИВНОЙ РАЗРАБОТКЕ/PROJECT UNDER ACTIVE DEVELOPMENT**
|
||||||
53
SESSIONS.md
Normal file
53
SESSIONS.md
Normal file
@ -0,0 +1,53 @@
|
|||||||
|
# Сессии и все-все-все
|
||||||
|
|
||||||
|
## Подпись
|
||||||
|
|
||||||
|
### Обмен пакетами в неаутентифицированом соединении
|
||||||
|
|
||||||
|
До выполнения аутентификации, сервер может, но не обязан, подписывать каждый свой пакет. Клиент может проверять подпись только в случае наличия у него открытого ключа сервера. Также клиент не должен подписывать свои пакеты и должен устанавливать хэш полезной нагрузки в нулевое значение.
|
||||||
|
|
||||||
|
### Регистрация
|
||||||
|
|
||||||
|
Перед инициированием процедуры регистрации, клиент запрашивает открытый ключ подписи сервера и тот отвечает событием, с открытым ключом в качестве основных данных и подписанным закрытым ключом хэшем полезной нагрузки. Клиент должен проверить подпись этого события.
|
||||||
|
|
||||||
|
В случае успешной регистрации, клиент генерирует публичный и приватный ключи подписи, после чего отправляет событие с публичным ключом в качестве основных данных и подписанной закрытым ключом хэшем полезной нагрузки на сервер. Сервер должен проверить подпись этого события.
|
||||||
|
|
||||||
|
### Обмен пакетами в аутентифицированном соединении
|
||||||
|
|
||||||
|
Каждый принятый сервером пакет, содержащий хэш полезной нагрузки, должен проверяться на соответствие подписи, путём расшифровки этого хэша открытом ключом подписи и последующего сравнения с реальным хэшем полезной нагрузки. Если сервер обнаруживает, что подпись неверна - сервер отвечает ошибкой, добавляет запись в журнал об инциденте, а обрабатываемый пакет игнорируется.
|
||||||
|
|
||||||
|
Каждый принятый клиентом пакет, содержащий хэш полезной нагрузки, должен быть проверен на соответствие подписи. Если клиент обнаруживает, что подпись неверна - он уведомляет об этом пользователя, а обрабатываемый пакет игнорируется.
|
||||||
|
|
||||||
|
### Наглядные примеры работы с подписями
|
||||||
|
|
||||||
|
#### Отправка подписанного пакета
|
||||||
|
|
||||||
|
При отправке сообщения клиентом A клиенту Б, оно проходит следующую цепочку:
|
||||||
|
|
||||||
|
1. Клиент А посылает пакет с подписанным хэшем полезной нагрузки (далее - ХПН) и подписанными основными данными (как часть содержания полезной нагрузки), на свой хоумсервер (место, где клиент А аутентифицирован, далее - ХС А).
|
||||||
|
2. ХС A проверяет ХПН на валидность. Допустим, что подпись верна.
|
||||||
|
3. ХС А совершает релевантные действия, исходя из содержания и типа события.
|
||||||
|
4. ХС А переподписывает ХПН с использованием свой подписи.
|
||||||
|
5. ХС А отправляет переподписанный пакет хоумсерверу клиента Б (далее - ХС Б).
|
||||||
|
6. ХС Б проверяет ХПН на валидность. Допустим, что подпись верна.
|
||||||
|
7. ХС Б совершает релевантные действия, исходя из содержания и типа пакета.
|
||||||
|
8. ХС Б переподписывает пакет с использованием своей подписи.
|
||||||
|
9. ХС Б отправляет переподписанный пакет клиенту Б.
|
||||||
|
10. Клиент Б проверяет ХПН на валидность. Допустим, что подпись верна.
|
||||||
|
11. Клиент Б проверяет подпись основных данных, на предмет соответствия подписи клиента А и совершает релевантные действия.
|
||||||
|
|
||||||
|
<!-- TODO: решить: как и нужно-ли, чтобы сервер являлся средой нулевого доверия в плане передачи подписей пользователей (скорее всего "Да.") -->
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Серверные сессии и их идентификаторы
|
||||||
|
|
||||||
|
При аутентификации клиента на сервере, сервер генерирует и отправляет клиенту уникальный идентификатор серверной сессии, который также ассоциирует с текущим подключением клиента.
|
||||||
|
|
||||||
|
После успешной аутентификации, клиент обязан прилагать назначенный ему ID серверной сессии к каждому пакету.
|
||||||
|
|
||||||
|
Если при проверке ID серверной сессии в пакете обнаруживается её отсутствие среди пулла серверных сессий - сервер отвечает ошибкой, соединение разрывается.
|
||||||
|
|
||||||
|
Две серверные сессии не должны иметь одинаковое значение ID ни при каких условиях.
|
||||||
|
|
||||||
|
Разные подключения одного клиента должны иметь одинаковую ассоциированную сессию.
|
||||||
Loading…
Reference in New Issue
Block a user