Войти
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 с черновиком Request for Comments (RFC), опубликованным в конце 1996 года. Вскоре после этого был зарегистрирован официальный порт IANA. Однако RFC не был доработан до 2005 года.
Были разработаны два отдельных метода для активации безопасности клиента для использования с FTP-клиентами: неявный и явный. В то время как неявный метод требует, чтобы безопасность транспортного уровня была установлена с самого начала соединения, что, в свою очередь, нарушает совместимость с клиентами и серверами, не поддерживающими FTPS, явный метод использует стандартные команды протокола FTP и ответы для обновления соединение обычного текста с зашифрованным, что позволяет использовать один порт управления для обслуживания клиентов, поддерживающих и не поддерживающих FTPS.
Согласование не поддерживается с неявными конфигурациями FTPS. Ожидается, что клиент немедленно вызовет сервер FTPS с сообщением TLS ClientHello. Если такое сообщение не получено сервером FTPS, сервер должен разорвать соединение.
Для обеспечения совместимости с существующими клиентами, не поддерживающими FTPS, предполагалось, что неявный FTPS будет прослушивать хорошо известный IANA порт 990 / TCP для канала управления FTPS и порт 989 / TCP для данных FTPS. канал. Это позволило администраторам сохранить унаследованные службы на исходном канале управления 21 / TCP FTP.
Обратите внимание, что неявное согласование не было определено в 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.
FTPS включает полную поддержку криптографических протоколов TLS и SSL, включая использование сервера -side сертификаты аутентификации с открытым ключом и сертификаты авторизации на стороне клиента. Он также поддерживает совместимые шифры, включая 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 будет работать. Эта проблема может быть решена путем использования ограниченного диапазона портов для данных и настройки брандмауэра на открытие этих портов.
