FTPS

Эта статья о FTP через SSL. Информацию о FTP Software, несуществующей компании, занимающейся сетевым программным обеспечением, см. в разделе « Программное обеспечение FTP» .

Протокол передачи файлов через TLS

Протокол связи
Цель	Передача файлов
На основе	FTP , TLS
Порт(ы)	Для неявного FTPS: 990 для управления, 989 для передачи данных.
RFC(ы)	RFC 959 (FTP), RFC 8446 (TLS 1.3), RFC 4217 (явный FTPS)

FTPS (также известный как FTP-SSL и FTP Secure ) — это расширение широко используемого протокола передачи файлов (FTP), которое добавляет поддержку Transport Layer Security (TLS) и, ранее, Secure Sockets Layer (SSL, который теперь запрещено RFC7568) криптографическими протоколами.

FTPS не следует путать с протоколом передачи файлов SSH (SFTP), подсистемой безопасной передачи файлов для протокола Secure Shell (SSH), с которой он несовместим. Он также отличается от FTP через SSH , который представляет собой практику туннелирования FTP через SSH-соединение.

Фон

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

Когда ARPANET уступила место NSFNET , а затем и Интернету , более широкие слои населения потенциально получили доступ к данным, поскольку они проходили все более длинные пути от клиента к серверу. Возможность несанкционированного прослушивания передачи данных третьими лицами пропорционально возросла.

В 1994 году компания Netscape , занимающаяся интернет-браузером, разработала и выпустила прикладного уровня оболочку Secure Sockets Layer . Этот протокол позволял приложениям обмениваться данными по сети конфиденциальным и безопасным способом, препятствуя прослушиванию, фальсификации и подделке сообщений. Хотя он мог повысить безопасность любого протокола, использующего надежные соединения, такого как TCP , чаще всего он использовался Netscape с HTTP для формирования HTTPS.

Протокол SSL в конечном итоге был применен к FTP, а проект запроса на комментарии (RFC) был опубликован в конце 1996 года. официальный порт IANA Вскоре после этого был зарегистрирован . Однако RFC не был завершен до 2005 года.

Способы вызова безопасности

Для вызова клиентской безопасности для использования с FTP-клиентами были разработаны два отдельных метода: Implicit и Explicit . Хотя неявный метод требует, чтобы безопасность транспортного уровня была установлена ​​с самого начала соединения, что, в свою очередь, нарушает совместимость с клиентами и серверами, не поддерживающими FTPS, явный метод использует стандартные команды и ответы протокола FTP для обновления соединения. простое текстовое соединение с зашифрованным, что позволяет использовать один порт управления для обслуживания клиентов как с поддержкой FTPS, так и без нее.

Скрытый

Согласование не поддерживается при неявных конфигурациях FTPS. Ожидается, что клиент немедленно отправит FTPS-серверу сообщение TLS ClientHello . Если такое сообщение не получено сервером FTPS, сервер должен разорвать соединение.

Для обеспечения совместимости с существующими клиентами, не поддерживающими FTPS, предполагалось, что неявный FTPS будет прослушивать хорошо известный IANA порт 990/TCP для канала управления FTPS и порт 989/TCP для канала данных FTPS. Это позволило администраторам сохранить устаревшие службы на исходном канале управления FTP 21/TCP.

Обратите внимание, что неявное согласование не было определено в RFC 4217. Таким образом, оно считается более ранним устаревшим методом согласования TLS/SSL для FTP.

Явный

В явном режиме (также известном как FTPES) клиент FTPS должен «явно запросить» безопасность у сервера FTPS, а затем перейти к взаимосогласованному методу шифрования. Если клиент не запрашивает безопасность, сервер FTPS может либо разрешить клиенту продолжить работу в незащищенном режиме, либо отклонить соединение.

Механизм согласования аутентификации и безопасности с FTP был добавлен в RFC 2228, который включал новую команду FTP AUTH. Хотя этот RFC явно не определяет какие-либо необходимые механизмы безопасности, например SSL или TLS, он требует, чтобы клиент FTPS запрашивал сервер FTPS с помощью взаимно известного механизма. Если клиент FTPS запрашивает сервер FTPS с помощью неизвестного механизма безопасности, сервер FTPS ответит на команду AUTH кодом ошибки 504 (не поддерживается) . Клиенты могут определить, какие механизмы поддерживаются, запросив FTPS-сервер с помощью команды FEAT, хотя от серверов не обязательно требуется честно раскрывать, какие уровни безопасности они поддерживают. Общие методы вызова безопасности FTPS включали AUTH TLS и AUTH SSL.

Явный метод определен в RFC 4217. В более поздних версиях документа соответствие FTPS требовало, чтобы клиенты всегда согласовывались с использованием метода AUTH TLS.

Безопасность транспортного уровня (TLS)/Secure Socket Layer (SSL)

Основная статья: Безопасность транспортного уровня

Общая поддержка

FTPS включает полную поддержку криптографических протоколов TLS и SSL, включая использование сертификатов аутентификации с открытым ключом на стороне сервера и сертификатов авторизации на стороне клиента. Он также поддерживает совместимые шифры, включая AES , RC4 , RC2 , Triple DES и DES . Он также поддерживает хэш-функции SHA , MD5 , MD4 и MD2 .

Область использования

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

Безопасный командный канал

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

Безопасный канал передачи данных

В защищенный канал данных можно войти, подав команду PROT. По умолчанию он не включен при вводе команды AUTH TLS. По истечении этого времени предполагается, что вся связь по каналам данных между клиентом и сервером FTPS зашифрована.

Клиент FTPS может выйти из режима защищенного канала данных в любое время, выдав команду CDC (очистить канал данных).

Причины отключить шифрование

Использование шифрования канала данных может оказаться невыгодным при выполнении передачи в следующих сценариях:

• Передаваемые файлы не имеют конфиденциального характера, что делает шифрование ненужным.
• Передаваемые файлы уже зашифрованы на уровне файлов или передаются через зашифрованную VPN , что делает шифрование ненужным.
• Доступные режимы шифрования TLS или SSL не соответствуют желаемому уровню шифрования. Это характерно для старых клиентов или серверов FTPS, которые могли быть ограничены 40-битным SSL из-за предыдущих законов США об экспорте с высоким уровнем шифрования.

Использование шифрования канала управления может оказаться невыгодным в следующих сценариях:

• Использование FTPS, когда клиент или сервер находится за сетевым брандмауэром или устройством трансляции сетевых адресов (NAT). (См. раздел «Несовместимость брандмауэра» ниже.)
• Повторное использование команд AUTH и CCC/CDC анонимными FTP-клиентами в рамках одного сеанса. Такое поведение может быть использовано как атака типа «отказ в обслуживании» на основе ресурсов, поскольку сеанс TLS/SSL необходимо каждый раз заново создавать, используя время процессора сервера.

SSL-сертификаты

Как и HTTPS , серверы FTPS должны предоставлять сертификат открытого ключа . Эти сертификаты можно запросить и создать с помощью таких инструментов, как OpenSSL .

Когда эти сертификаты подписаны доверенным центром сертификации , это обеспечивает уверенность в том, что клиент подключен к запрошенному серверу, избегая атаки «человек посередине» . Если сертификат не подписан доверенным центром сертификации ( самозаверяющий сертификат ), клиент FTPS может выдать предупреждение о том, что сертификат недействителен. Клиент может принять сертификат или отклонить соединение.

В этом отличие от протокола передачи файлов SSH (SFTP), который не предоставляет подписанные сертификаты, а вместо этого использует внеполосную аутентификацию открытых ключей.

Несовместимость брандмауэра

Поскольку FTP использует динамический вторичный порт (для каналов данных), многие межсетевые экраны были разработаны для отслеживания управляющих сообщений протокола FTP, чтобы определить, какие вторичные соединения для передачи данных им необходимо разрешить. Однако если управляющее соединение FTP зашифровано с использованием TLS/SSL, брандмауэр не может определить номер TCP-порта соединения для передачи данных, согласованного между клиентом и FTP-сервером. Таким образом, во многих сетях с брандмауэром развертывание FTPS завершится неудачно, если развертывание незашифрованного FTP будет работать. Эту проблему можно решить, используя ограниченный набор портов для данных и настроив межсетевой экран на открытие этих портов.

См. также

• FTP через SSH
• Сравнение протоколов передачи файлов
• Сравнение программного обеспечения FTP-клиента
• Список программного обеспечения FTP-сервера
• Безопасное копирование (SCP) — протокол передачи файлов с использованием протокола Secure Shell (SSH).
• Протокол передачи файлов SSH (SFTP)
• Файлы, передаваемые по протоколу оболочки (FISH)
• Список номеров портов TCP и UDP

Внешние ссылки

• Обзор FTPS и списки клиентов, серверов
• Curl-loader — инструмент загрузки/тестирования FTPS с открытым исходным кодом.