RFC 2228

RFC 2228 — это спецификация, опубликованная в октябре 1997 года в серии документов Internet Engineering Task Force (IETF) под названием «FTP Security Extensions» (Расширения безопасности для FTP). Документ определяет набор расширений к протоколу передачи файлов (FTP), направленных на обеспечение аутентификации, целостности и конфиденциальности данных при передаче по сети. RFC 2228 является историческим стандартом, который заложил основу для создания защищённых версий FTP, в частности FTPS (FTP over SSL/TLS).

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

К середине 1990-х годов протокол FTP, определённый в RFC 959 (1985), стал основным средством передачи файлов в сети Интернет. Однако его архитектура имела фундаментальные уязвимости с точки зрения безопасности:

• Аутентификация в открытом виде: Имя пользователя и пароль передавались по каналу управления (порт 21) в незашифрованном виде (ASCII). Это позволяло злоумышленнику, контролирующему сетевой трафик (например, в сегменте локальной сети или на маршрутизаторе), перехватывать учётные данные.
• Отсутствие шифрования данных: Данные, передаваемые по каналам данных (порты 20 или динамические порты), также не шифровались. Любой файл, загружаемый или скачиваемый по FTP, мог быть прочитан третьей стороной.
• Уязвимость к атакам «человек посередине» (MITM): Из-за отсутствия механизмов проверки подлинности сервера и клиента злоумышленник мог выдать себя за легитимный FTP-сервер или перехватить и модифицировать данные в пути.
• Проблемы с брандмауэрами и NAT: Активный режим FTP (PORT) требовал, чтобы сервер инициировал соединение к клиенту, что создавало сложности для брандмауэров и трансляторов сетевых адресов (NAT). Пассивный режим (PASV) решал эту проблему, но не добавлял безопасности.

Эти недостатки делали FTP непригодным для передачи конфиденциальной информации, особенно в корпоративных и финансовых сетях. RFC 2228 был разработан как ответ на эти угрозы, предлагая механизмы для защиты FTP без полной переработки протокола.

Основные положения RFC 2228

RFC 2228 не определяет конкретный криптографический протокол (например, TLS или SSH), а предоставляет фреймворк для добавления безопасности в FTP. Он вводит новые команды, коды ответов и механизмы согласования параметров защиты.

Ключевые нововведения

1. Новые команды безопасности:

• AUTH (Authentication/Security Mechanism): Команда, с помощью которой клиент и сервер согласовывают используемый механизм безопасности (например, TLS, Kerberos, GSSAPI). Клиент отправляет AUTH <тип_механизма>, сервер отвечает кодом 234 (готов к согласованию) или 504 (механизм не поддерживается).
• ADAT (Authentication/Security Data): Команда для обмена данными аутентификации. Используется для передачи токенов, сертификатов и другой информации, необходимой для установления защищённого соединения.
• PBSZ (Protection Buffer Size): Команда, устанавливающая максимальный размер буфера для защищённых данных. Клиент и сервер согласовывают размер блока, который будет передаваться в зашифрованном виде.
• PROT (Data Channel Protection Level): Команда, определяющая уровень защиты для канала данных. RFC 2228 определяет четыре уровня:
• C (Clear): Канал данных не защищён (по умолчанию).
• S (Safe): Канал данных защищён с помощью механизма целостности (например, MAC — код аутентичности сообщения), но не шифруется.
• E (Confidential): Канал данных шифруется.
• P (Private): Канал данных одновременно шифруется и защищается с помощью целостности.

1. Новые коды ответов:

• 234: Готов к согласованию безопасности.
• 334: Запрос на дополнительные данные аутентификации.
• 335: Запрос на данные аутентификации для канала данных.
• 431: Неизвестный или неподдерживаемый механизм безопасности.
• 503: Ошибка последовательности команд (например, попытка установить защиту до аутентификации).

1. Механизм согласования: RFC 2228 вводит концепцию «защищённого согласования» (secure negotiation). Клиент и сервер могут установить защищённое соединение на канале управления (команды AUTH, ADAT), а затем, используя команду PROT, отдельно настроить защиту для канала данных. Это позволяет, например, шифровать только передаваемые файлы, оставляя команды управления незашифрованными (хотя на практике обычно шифруется и то, и другое).

1. Интеграция с существующим FTP: Все новые команды и ответы являются расширениями к базовому протоколу FTP (RFC 959). Серверы, не поддерживающие RFC 2228, просто игнорируют неизвестные команды, и клиент может работать в незащищённом режиме. Это обеспечивает обратную совместимость.

Реализация и влияние

RFC 2228 стал основой для двух основных подходов к защищённому FTP:

FTPS (FTP over SSL/TLS)

Наиболее распространённая реализация RFC 2228. FTPS использует протокол TLS (Transport Layer Security) или его предшественник SSL (Secure Sockets Layer) для шифрования и аутентификации. Процесс установки соединения по FTPS включает:

1. Клиент подключается к серверу на порт 21.
2. Клиент отправляет команду AUTH TLS (или AUTH SSL).
3. Сервер отвечает кодом 234 и предлагает свой сертификат.
4. Происходит рукопожатие TLS (handshake), в ходе которого клиент и сервер обмениваются ключами и проверяют сертификаты.
5. После установления защищённого канала управления клиент отправляет команду USER и PASS (уже в зашифрованном виде).
6. Для передачи данных используется команда PROT P (приватный уровень), и канал данных также шифруется с помощью TLS.

FTPS широко используется в корпоративных средах и приложениях, где требуется надёжная защита данных. Он поддерживается большинством современных FTP-клиентов (FileZilla, WinSCP, CuteFTP) и серверов (ProFTPD, vsftpd, Microsoft IIS).

SFTP (SSH File Transfer Protocol)

Важно не путать FTPS с SFTP. SFTP — это отдельный протокол, не основанный на FTP и RFC 2228. Он является частью пакета SSH (Secure Shell) и работает через порт 22. SFTP обеспечивает шифрование, аутентификацию и целостность на уровне протокола SSH. В отличие от FTPS, SFTP не использует отдельные каналы управления и данных, а передаёт файлы в рамках одного защищённого соединения.

Недостатки и ограничения RFC 2228

Несмотря на свою важность, RFC 2228 имеет ряд недостатков:

• Сложность согласования: Процесс согласования механизмов безопасности (AUTH, ADAT, PBSZ, PROT) может быть сложным для реализации и отладки. Разные серверы и клиенты могут по-разному интерпретировать спецификацию.
• Проблемы с брандмауэрами: FTPS, особенно в активном режиме, по-прежнему сталкивается с проблемами при прохождении через брандмауэры и NAT, так как требует открытия большого количества динамических портов.
• Необходимость в сертификатах: Для FTPS требуется инфраструктура открытых ключей (PKI) — сертификаты сервера и, опционально, клиента. Это добавляет сложности в управлении.
• Обратная совместимость: Хотя RFC 2228 и обеспечивает обратную совместимость, на практике многие старые FTP-клиенты и серверы не поддерживают расширения безопасности, что ограничивает их применение в устаревших системах.

Современное состояние и альтернативы

RFC 2228 был опубликован в 1997 году и с тех пор неоднократно обновлялся (например, RFC 4217, который уточняет использование TLS с FTP). Однако с развитием технологий безопасности он постепенно уступает место более современным протоколам:

• SFTP (SSH File Transfer Protocol): Стал де-факто стандартом для защищённой передачи файлов в Unix-подобных системах и в средах разработки. Он проще в настройке, не требует сертификатов и решает проблему с брандмауэрами.
• HTTPS (HTTP over TLS): Для загрузки и скачивания файлов через веб-интерфейсы всё чаще используется HTTPS, который обеспечивает шифрование и аутентификацию на уровне веб-протокола.
• WebDAV over HTTPS: Протокол WebDAV, работающий поверх HTTPS, позволяет не только передавать файлы, но и управлять ими (создавать, удалять, переименовывать) через защищённое соединение.
• AS2 (Applicability Statement 2): Протокол, используемый в электронном обмене данными (EDI), который обеспечивает безопасную передачу файлов через HTTP или SMTP с использованием шифрования и цифровых подписей.

Несмотря на эти альтернативы, FTPS (основанный на RFC 2228) остаётся востребованным в некоторых корпоративных средах, особенно в тех, где уже развёрнута инфраструктура FTP и требуется обратная совместимость с устаревшими системами.

Критика

Основная критика RFC 2228 связана с его архитектурной сложностью. Фреймворк, предлагаемый спецификацией, требует от разработчиков реализации большого количества дополнительных команд и состояний, что увеличивает вероятность ошибок и уязвимостей. Кроме того, сам процесс согласования безопасности (AUTH/ADAT/PBSZ/PROT) может быть подвержен атакам типа «понижение версии» (downgrade attack), если злоумышленник может вмешаться в начальный этап рукопожатия. Также отмечается, что RFC 2228 не решает проблему с активным режимом FTP и брандмауэрами, что делает его менее удобным для современных сетей.

Источники

• RFC 2228 — FTP Security Extensions (октябрь 1997)
• RFC 959 — File Transfer Protocol (октябрь 1985)
• RFC 4217 — Securing FTP with TLS (октябрь 2005)
• RFC 4251 — The Secure Shell (SSH) Protocol Architecture (январь 2006)
• Спецификация протокола FTPS (IETF)
• Материалы конференций USENIX по безопасности сетевых протоколов (1998-2005)