FTPS (также известный как FTP-SSL и FTP Secure ) — это расширение широко используемого протокола передачи файлов (FTP), которое добавляет поддержку криптографических протоколов Transport Layer Security (TLS) и, ранее, Secure Sockets Layer (SSL, который теперь запрещен RFC7568).
FTPS не следует путать с протоколом передачи файлов SSH (SFTP), защищенной подсистемой передачи файлов для протокола Secure Shell (SSH), с которым он несовместим. Он также отличается от FTP over SSH , который представляет собой практику туннелирования FTP через соединение SSH.
Протокол передачи файлов был разработан в 1971 году для использования в научно-исследовательской сети ARPANET . [1] Доступ к ARPANET в то время был ограничен небольшим числом военных объектов и университетов, а также узким сообществом пользователей, которые могли работать без требований безопасности данных и конфиденциальности в рамках протокола.
По мере того, как ARPANET уступила место NSFNET , а затем и Интернету , более широкие слои населения потенциально имели доступ к данным, поскольку они проходили все более длинные пути от клиента к серверу. Возможность для неавторизованных третьих лиц прослушивать передачи данных увеличивалась пропорционально.
В 1994 году компания Netscape, занимающаяся разработкой интернет-браузеров, разработала и выпустила оболочку прикладного уровня Secure Sockets Layer . [2] Этот протокол позволял приложениям общаться по сети конфиденциальным и безопасным образом, препятствуя подслушиванию, фальсификации и подделке сообщений. Хотя он мог повысить безопасность любого протокола, использующего надежные соединения, например TCP , он чаще всего использовался Netscape с HTTP для формирования HTTPS.
Протокол SSL в конечном итоге был применен к FTP, с проектом Request for Comments (RFC), опубликованным в конце 1996 года. [3] Вскоре после этого был зарегистрирован официальный порт IANA . Однако RFC не был окончательно оформлен до 2005 года. [4]
Для вызова клиентской безопасности для использования с FTP-клиентами были разработаны два отдельных метода: неявный и явный . В то время как неявный метод требует, чтобы Transport Layer Security был установлен с самого начала соединения, что, в свою очередь, нарушает совместимость с несовместимыми с FTPS клиентами и серверами, явный метод использует стандартные команды и ответы протокола FTP для обновления соединения с простым текстом до зашифрованного, что позволяет использовать один порт управления для обслуживания как совместимых с FTPS, так и несовместимых с FTPS клиентов.
Согласование не поддерживается с неявными конфигурациями FTPS. Клиент должен немедленно бросить вызов серверу FTPS с помощью сообщения TLS ClientHello . Если такое сообщение не получено сервером FTPS, сервер должен разорвать соединение.
Для поддержания совместимости с существующими клиентами, не поддерживающими FTPS, предполагалось, что неявный FTPS будет прослушивать хорошо известный порт IANA 990/TCP для канала управления FTPS и порт 989/TCP для канала данных FTPS. [5] Это позволило администраторам сохранить совместимые с устаревшими версиями сервисы на исходном канале управления FTP 21/TCP.
Обратите внимание, что неявное согласование не было определено в RFC 4217. Таким образом, оно считается более ранним, устаревшим методом согласования TLS/SSL для FTP. [6]
В явном режиме (также известном как 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.
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 (очистить канал данных).
Использование шифрования канала данных может оказаться невыгодным при выполнении передач в следующих сценариях:
Использование шифрования канала управления может оказаться невыгодным в следующих сценариях:
Подобно HTTPS , серверы FTPS должны предоставлять сертификат открытого ключа . Эти сертификаты можно запросить и создать с помощью таких инструментов, как OpenSSL .
Когда эти сертификаты подписаны доверенным центром сертификации , это обеспечивает гарантию того, что клиент подключен к запрашиваемому серверу, избегая атаки типа «человек посередине» . Если сертификат не подписан доверенным центром сертификации ( самозаверяющий сертификат ), клиент FTPS может выдать предупреждение о том, что сертификат недействителен. Клиент может принять сертификат или отклонить соединение.
Это отличается от протокола передачи файлов SSH (SFTP), который не предоставляет подписанных сертификатов, а вместо этого полагается на внеполосную аутентификацию открытых ключей.
Поскольку FTP использует динамический вторичный порт (для каналов данных), многие брандмауэры были разработаны для отслеживания сообщений управления протоколом FTP, чтобы определить, какие вторичные соединения данных им необходимо разрешить. Однако, если соединение управления FTP зашифровано с помощью TLS/SSL, брандмауэр не может определить номер порта TCP соединения данных, согласованного между клиентом и сервером FTP. Поэтому во многих сетях с брандмауэрами развертывание FTPS не будет работать, когда будет работать незашифрованное развертывание FTP. Эту проблему можно решить, используя ограниченный диапазон портов для данных и настроив брандмауэр на открытие этих портов.