Кратко

  • RFC 3323 описывала приватность относительно конкретного наблюдателя: личность могла быть известна посреднику или системе аутентификации и одновременно скрыта от адресата.
  • Значение critical задавало отказ при невозможности выполнить защиту; наличие заголовка Privacy само по себе не доказывало, что служба что-либо скрыла.

Известен сети, неизвестен собеседнику

В SIP идентичность появлялась не в одном месте. From мог содержать адрес записи и отображаемое имя. Contact и Via поддерживали маршрутизацию текущего диалога. SDP мог раскрывать сетевой адрес медиапотока. Call-ID, User-Agent, Organization и другие поля тоже позволяли связать сообщение с человеком или устройством. Аутентификация обычно открывала личность хотя бы одной стороне.

Пользовательский агент мог использовать в From имя Anonymous и зарезервированный анонимный SIP-домен, удалить необязательные поля и не включать имя хоста в Call-ID. Но он не мог без последствий подменить всё. Неработающий Contact мешал последующим запросам, ложный Via ломал ответы, а прямой медиапуть показывал участникам сетевые адреса.

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

Наблюдатель был частью утверждения

Документ различал несколько целей. Пользователь мог скрыть личность от назначения, оставив её посредникам; скрыть часть сведений от посредников, но передать их конечной стороне защищённым способом; либо попытаться скрыть от обеих групп. Фраза «вызов анонимен» неполна, пока не назван тот, от кого скрывали.

Это объясняет, почему подтверждённая личность и приватность могли сосуществовать. Оператор мог знать абонента для доступа, учёта или политики, но не выдавать его адрес другой стороне. RFC 3325 параллельно описывала утверждение личности в доверенной сети. Поздние документы об identity и истории меняли другие доказательства, не превращая их в глобальную видимость.

Запрос не был квитанцией

Значения header, session и user просили сетевую обработку заголовков, маршрута сессии или пользовательских данных. Они фиксировали намерение. Правовые ограничения, отсутствующая функция, ошибка настройки или исключительная ситуация могли помешать выполнению. Поэтому обнаруженный Privacy header нельзя считать доказательством результата.

critical делал последствие явным: если запрошенную функцию нельзя предоставить, запрос следует отвергнуть. Молчаливое продолжение раскрывало бы идентичность именно при попытке её защитить. Утечка необратима: поздний ответ не удалит сведения из памяти и журналов получателя.

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

Доверие начиналось до службы

RFC настойчиво рекомендовала TLS или аналогичную защиту до службы приватности. Иначе предыдущий посредник мог увидеть данные до удаления или снять сам запрос. Прямое соединение позволяло проверить сертификат и уменьшить число точек раскрытия.

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

Прокси и получатели сохраняли право отвергать неидентифицируемых отправителей. Просьба об анонимности не давала власти принудить другую сторону к приёму. Историческое достижение RFC 3323 заключалось именно в разнесении ролей: кто просил, кто видел, кто удалял, кто маршрутизировал и что происходило при невозможности выполнить обещание.

Ответный путь тоже требовал предварительного устройства. SIP-ответ возвращался через узлы запроса, поэтому после его получения нельзя было задним числом вставить новый сервис. Анонимный callback URI, регистрация через посредника или защищённое постоянное соединение должны были существовать заранее. Приватность становилась свойством маршрута, а не косметикой заголовка.

Так же нельзя было смешивать header и session. Чистые From и Via не скрывали SDP и медиапакеты; медиарелей не удалял Call-ID или User-Agent. Проверка должна была независимо охватывать сигнализацию, медиапуть и аутентификацию, каждый раз называя наблюдателя.

Sources