ДокументацияDocs Home БезопасностьSecurity ПрозрачностьTransparency
Транспорт и метаданные / Ревизия 2026-03-01 / v1.1

Транспортная архитектура и наблюдаемость метаданных

Настоящий документ определяет сетевые пути, видимость трафика для наблюдателя и границы между E2E-контентом и эксплуатационными метаданными.

Оглавление

1. Клиентские сетевые пути (актуально для этой ревизии)

  • API и сигнализация: `api.kasty.app` (HTTPS/WSS).
  • Путь ретрансляции звонков: `api.kasty.app` и выделенный ретрансляционный путь в зависимости от согласованного режима.
  • Сайт и правовые страницы: `kasty.app` (HTTPS).
  • Потоковые сервисы: `stream.kasty.live`, `hls.kasty.live` (HTTPS).
  • Стек комнат (при применимости): `rooms.kasty.live` (HTTPS/WSS).
При существенном изменении топологии маршрутов публикуется новая ревизия документа.

2. Порты и протоколы

  • Основной защищенный путь: `443/tcp` (TLS/HTTPS/WSS).
  • `80/tcp` используется для HTTP-редиректа и технического обслуживания веб-слоя.
  • Для ретрансляции звонков в отдельных режимах может использоваться `4002/tcp`.

На уровне потребительского роутера обычно наблюдаются IP-адрес назначения, порт, длительность и объем трафика.

3. Что видит сетевой наблюдатель

3.1 Роутер и провайдерский уровень

  • Видимы IP-адреса, порты назначения, время, длительность и счетчики трафика.
  • При использовании TLS/WSS E2E-полезная нагрузка НЕ ДОЛЖНА быть доступна в открытом виде.

3.2 Захват пакетов (`pcap`)

  • Видимы сетевые заголовки и шифротекстовые данные.
  • Содержимое приватных сообщений и голоса в читаемом виде не наблюдается.

3.3 Ограничения

  • E2E не скрывает сам факт соединения и не устраняет все метаданные сетевого уровня.

4. Границы серверных метаданных

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

5. Нормативные требования

  • Клиент ДОЛЖЕН предпочитать защищенный транспорт (`443/tcp`, TLS/WSS) для API и сигнализации.
  • Пакеты медиапотока звонка ДОЛЖНЫ шифроваться до передачи в ретрансляционный транспорт.
  • Серверный транспорт ДОЛЖЕН обеспечивать маршрутизацию шифротекста без зависимости от открытого содержимого.
  • При изменении транспортной топологии документацию СЛЕДУЕТ обновлять синхронно со страницами раскрытия сведений о безопасности.
Для криптографических деталей см. KSMP Whisper Ultra OOB и KSMP Whisper / WhisperStreamVoice.
Transport & Metadata / Revision 2026-03-01 / v1.1

Transport Architecture and Metadata Visibility

This document defines network paths, observer visibility, and boundaries between E2E content and operational metadata.

Contents

1. Client network paths (for this revision)

  • API and signaling: `api.kasty.app` (HTTPS/WSS).
  • Call relay path: `api.kasty.app` plus dedicated call-relay path depending on negotiated mode.
  • Website/legal pages: `kasty.app` (HTTPS).
  • Streaming services: `stream.kasty.live`, `hls.kasty.live` (HTTPS).
  • Rooms stack (where applicable): `rooms.kasty.live` (HTTPS/WSS).
If topology changes materially, a new revision is published.

2. Ports and protocols

  • Primary protected path: `443/tcp` (TLS/HTTPS/WSS).
  • `80/tcp` is used for HTTP redirect and web-layer maintenance.
  • `4002/tcp` may be used for call relay in selected modes.

At consumer-router level, destination IP, port, duration, and traffic volume are typically visible.

3. Observer visibility

3.1 Router and ISP level

  • Visible: destination IP, port, timing, duration, traffic counters.
  • With TLS/WSS, E2E payload should not be visible in plaintext.

3.2 Packet capture (pcap)

  • Visible: network headers and ciphertext blobs.
  • Readable private message/voice plaintext is not visible.

3.3 Limitations

  • E2E does not hide the existence of connectivity and does not remove all network metadata.

4. Server metadata boundaries

  • Server processes metadata for authentication, routing, anti-abuse, reliability, and billing.
  • E2E paths are designed so plaintext private payloads do not enter operational server storage.
  • Disclosure under valid legal requests is limited to data actually possessed.

5. Normative requirements

  • Client MUST prefer protected transport (`443/tcp`, TLS/WSS) for API/signaling.
  • Call media payloads MUST be encrypted before relay transport.
  • Server transport MUST support ciphertext routing without plaintext dependence.
  • Transport-topology changes SHOULD be documented in sync with security-disclosure pages.
For cryptographic details, see KSMP Whisper Ultra OOB and KSMP Whisper / WhisperStreamVoice.