Кратко

  • В RFC 1459 префикс обозначал протокольный источник, но принимающий сервер искал его в локальной базе и сверял с каналом, по которому пришло сообщение.
  • Уникальность ника, регистрация клиента, соответствие ветви и допуск строки были разными фактами; ни один не устанавливал личность автора-человека.
  • Несоответствие могло закончиться молчаливым удалением, поэтому объяснение требовало исторического состояния соединения и базы, отсутствующего в самой строке.

Разделение сети делало имя временным

RFC 1459 вышел в мае 1993 года как экспериментальный протокол. IRC уже вырос из чата на BBS в мировую сеть клиентов и серверов. Серверы соединялись деревом, а каждый узел хранил сведения, необходимые для поиска клиентов и дальнейшей пересылки.

Сообщение оставалось короткой текстовой строкой. Перед командой мог стоять префикс — имя сервера или ник, иногда с пользователем и хостом. Без префикса источником считалось текущее соединение. С префиксом документ называл указанное имя происхождением сообщения.

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

Синтаксический разбор подтверждал форму. База подтверждала существование протокольного объекта. Карта соединений подтверждала допустимое направление его появления. Решение о допуске возникало только из совпадения этих записей.

«Настоящее происхождение» имело узкие границы

Проверка защищала полезное свойство. Локальный клиент не мог просто написать чужой ник и получить его позицию в маршрутизации. Соседний сервер не должен был проецировать известный источник из неправильной ветви.

Это не было подписью человека. Ник служил адресом сессии в текущем состоянии IRC. Сервер также знал имя пользователя, хост и домашний сервер. Соединения могли проходить прямую и обратную DNS-проверку, необязательный пароль и запрос Ident. Сам RFC признавал, что без паролей трудно надёжно определить, кто находится на другом конце, и настоятельно рекомендовал пароль между серверами.

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

Коллизия сохраняла пространство, а не владельца

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

При появлении одинакового ника для другого клиента возникала коллизия. Серверы удаляли экземпляры и распространяли KILL. Они не выбирали человека с более сильным внешним правом. Для непосредственно подключённого нового клиента можно было ограничиться локальным отказом.

WHOWAS показывал недавнюю историю ников. Серверы также отслеживали смены имени, чтобы KILL, MODE и KICK при гонке не попали в прежнего владельца. RFC 1459 прямо предупреждал, что ошибочное воздействие всё равно возможно. Одинаковая строка в разные моменты не является одной личностью.

При разрыве возникали две базы сравнения

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

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

Молчаливое удаление не создавало дополнительной нагрузки, но лишало отправителя причины. Отсутствие текста у получателя могло означать ошибку разбора, отсутствие источника, неправильную ветвь, сбой дальнейшей пересылки или отсутствие показа клиентом.

Спецификации 2000 года раскрыли цену решения

RFC 2810 выделил архитектуру IRC и назвал копирование глобального состояния на каждом сервере серьёзным ограничением масштаба. Эта копия была одновременно материалом для проверки происхождения.

RFC 2812 сохранил клиентское правило: при отсутствии префикса источником служит соединение, а клиент вправе назвать только зарегистрированный ник. RFC 2813 уточнил серверную сторону. Не найденный источник удалялся; неизвестное имя сервера могло привести к закрытию канала. Если база помещала источник за другой связью, сообщение всегда отбрасывалось, а затем мог последовать KILL клиента или разрыв соединения.

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

Там же серверный token был уникален только внутри одного пирингового соединения. За его пределами число не имело глобального значения. Область действия была частью идентификатора.

Исправление одного байта сохранило историю ошибки

RFC 1459 ошибочно обозначил двоеточие как 0x3B — это код точки с запятой. Показанный символ и грамматика указывали на намерение, а проверенная errata 4091 исправила значение на 0x3A.

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

TLS защищал не ту же самую границу

PASS и OPER передавались открытым текстом. RFC 2813 предложил потоковое шифрование наподобие TLS, а RFC 7194 позднее зарегистрировал стандартный порт IRC через TLS/SSL. Это могло защитить учётные данные и содержание на охваченном соединении.

Шифрование не заменяло сопоставление префикса. Аутентифицированный пир мог прислать устаревшее состояние; защищённый канал мог нести источник из неверной ветви. Верное совпадение, наоборот, не доказывало шифрования. Регистрация порта не свидетельствовала о развёртывании или доставке.

RFC 1459 оставил точную границу: написанное имя должно соответствовать наблюдаемому отношению в серверном дереве. Человек, конфиденциальность, дальнейший маршрут и чтение оставались за этой границей.