FTPS

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

FTPS (File Transfer Protocol + SSL, или FTP/SSL) — это расширение широко используемого протокола передачи данных FTP, которое добавляет поддержку для криптографических протоколов уровней транспортной безопасности и защищенных сокетов.

FTPS не следует путать с SFTP, он так же отличается и от FTP через SSH — передачи FTP данных и команд в защищённом SSH соединении.

Предпосылки[править | править код]

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

С течением времени, сеть ARPANET постепенно перерастала в сеть NSFNET а позже, во Всемирную паутину. Вместе с этим росло количество пользователей, увеличивались расстояния между конечными FTP клиентами и FTP серверами, а также, увеличивался шанс несанкционированного доступа третьих лиц к секретным военным или научным файлам.

В 1994 году, компания Netscape разработала и опубликовала протокол SSL — обертку над протоколами уровня приложений (согласно стеку протоколов TCP/IP). Этот протокол позволял приложениям взаимодействовать между собой по сети в защищенном режиме, предотвращая подслушивание, фальсификацию и разглашение приватных данных. SSL протокол добавлял защиту любому протоколу, который использует надежные соединения (такие как TCP) и начал активно использоваться в браузере Netscape а позже, для формирования защищенного протокола HTTPS.

Протокол SSL был в конечном итоге применен к протоколу FTP в проекте рабочего предложения (RFC) в 1996 году. Немногим позже, этот проект был зарегистрирован администрацией адресного пространства Интернет. Тем не менее, проект поправок не был завершен до 2005 года.

Методы предоставления безопасности[править | править код]

Существует два различных метода для обеспечения безопасности FTP клиенту: явный и неявный. Использование неявного метода предполагает, что будет установлена сессия TLS или SSL перед отправкой каких либо данных, это, в свою очередь, нарушает совместимость с FTP клиентами и серверами, которые не поддерживают протокол FTPS. Явный метод использует команды стандартного протокола FTP, но при ответе шифрует данные, что позволяет использовать один и тот же контрольный порт как для протокола FTP так и для FTPS. Такой способ используются в HTTPS, STARTTLS при реализации TLS для протоколов HTTP и SMTP соответственно.

Неявный метод[править | править код]

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

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

Явный метод[править | править код]

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

Защита транспортного уровня (TLS)/ Уровень защищенных сокетов (SSL)[править | править код]

Общая поддержка[править | править код]

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

Область использования[править | править код]

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

Защищенное контрольное соединение[править | править код]

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

Защищенное соединение передачи данных[править | править код]

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

Причины, по которым следует отключить шифрование[править | править код]

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

  • Передаваемые файлы уже зашифрованы прикладным приложением или передача происходит через зашифрованное VPN соединение
  • Доступные TLS или SSL протоколы не предоставляют требуемый уровень безопасности.

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

  • Использование протокола FTPS, когда клиент и/или сервер работают поверх межсетевого экрана или устройства преобразования сетевых адресов
  • Многократное использование команд AUTH и CCC/CDC анонимным FTP клиентом во время одной сессии. Такое поведение может быть принято за атаку типа «отказ в обслуживании», потому что TSL/SSL сессия каждый раз должна быть сгенерирована заново.

SSL сертификаты[править | править код]

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

Сертификаты должны быть подписаны доверенным центром сертификации[1], это обеспечивает гарантию того, что клиент подключится к запрошенному серверу, избегая атаки «человек посередине». В случае, если сертификат не подписан, клиент FTPS генерирует предупреждение о недействительности сертификата. Клиент вправе как принять сертификат, так и отклонить соединение.

Поддержка сертификатов отличает FTPS от SFTP, который не предоставляет подписанные сертификаты, но вместо этого полагается на открытые ключи ключевой пары.

Проблемы межсетевых экранов[править | править код]

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

См. также[править | править код]

Примечания[править | править код]

  1. Что такое корневой сертификат SSL и зачем он нужен? Дата обращения: 18 февраля 2016. Архивировано 25 февраля 2016 года.

Ссылки[править | править код]