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 . [1] Доступ к ARPANET в то время был ограничен небольшим количеством военных объектов и университетов, а также узким сообществом пользователей, которые могли работать без требований безопасности данных и конфиденциальности в рамках протокола.
Когда ARPANET уступила место NSFNET , а затем и Интернету , более широкие слои населения потенциально получили доступ к данным, поскольку они проходили все более длинные пути от клиента к серверу. Возможность несанкционированного прослушивания передачи данных третьими лицами пропорционально возросла.
В 1994 году компания Netscape, занимающаяся интернет-браузером, разработала и выпустила оболочку прикладного уровня Secure Sockets Layer . [2] Этот протокол позволял приложениям обмениваться данными по сети конфиденциальным и безопасным способом, препятствуя подслушиванию, фальсификации и подделке сообщений. Хотя он мог повысить безопасность любого протокола, использующего надежные соединения, такого как TCP , чаще всего он использовался Netscape с HTTP для формирования HTTPS.
Протокол SSL в конечном итоге был применен к FTP, и в конце 1996 года был опубликован проект запроса на комментарии (RFC). [3] Вскоре после этого был зарегистрирован официальный порт IANA . Однако RFC не был завершен до 2005 года. [4]
Для вызова клиентской безопасности для использования с FTP-клиентами были разработаны два отдельных метода: Implicit и Explicit . Хотя неявный метод требует, чтобы безопасность транспортного уровня была установлена с самого начала соединения, что, в свою очередь, нарушает совместимость с клиентами и серверами, не поддерживающими FTPS, явный метод использует стандартные команды и ответы протокола FTP для обновления соединения. простое текстовое соединение с зашифрованным, что позволяет использовать один порт управления для обслуживания клиентов как с поддержкой 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 будет работать. Эту проблему можно решить, используя ограниченный набор портов для данных и настроив межсетевой экран на открытие этих портов.