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 . ^[1] Доступ к ARPANET в то время был ограничен небольшим количеством военных сайтов и университетов и узким сообществом пользователей, которые могли работать без требований безопасности и конфиденциальности данных в рамках протокола.

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

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

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

Способы активации безопасности [ править ]

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

Неявный [ править ]

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

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

Обратите внимание, что неявное согласование не было определено в 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.

Безопасность транспортного уровня (TLS) / Уровень защищенных сокетов (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 будет работать. Эту проблему можно решить с помощью ограниченного диапазона портов для данных и настройки брандмауэра на открытие этих портов.

См. Также [ править ]

Заметки [ править ]

Внешние ссылки [ править ]

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