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 соответственно.

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 сессия каждый раз должна быть сгенерирована заново.

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

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

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

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

• SCP
• SFTP
• FTP

• rfc 4217
• rfc 2228
• Описание FTPS, список клиентов, серверов, и прокси, поддерживающих FTPS
• Настройка FTPS соединения в файловом менеджере Total Commander