Comments 19
Интересный обзор, но выводы неправильные.
его защищённые версии
SFTP — это не новая версия того FTP, а новый протокол с аналогичным функционалом (причём в самой статье выше это было написано).
Оба новых протокола имеют свои плюсы и минусы и выполняют немного разные роли. В тех областях, где необходим именно файловый архив предпочтительнее использовать FTPS, особенно если раньше там уже использовался классический FTP
Нет, плюсы есть только у SFTP, а от FTP и всех его модификаций надо избавляться. Это жуткое легаси, совершенно непригодное в современных реалиях нигде, кроме локальной домашней сети, и костыльная SSL-обёртка не особо что-то меняет. Ну а в домашней сети его лучше тоже не использовать, чтобы не привыкать к плохим вещам.
1) Я знаю, я просто обобщил
2) В домашних сетях FTP вполне себе нормальная вещь для передачи файлов между разношерстными устройствами. Можете предложить альтернативу?
а можно детальнее что не так с ftps?
Разумно такую штуку постить в час ночи, конечно) Узнать в общих чертах об этом древнем протоколе конечно познавательно. Но кажется, что настройка и факты лежат отдельно не с проста. Ведь протокол просто используют. То есть ни у кого нет интереса к его внутреннему устройству, а те кому интересно, собирают факты и читают RFC.
Это удобный, многофункциональный и стандартизированный протокол.
Такое словосочетание кажется неуместным. Может, широко известный, но стандартизация явно не главный плюс стричка.
Ну, я, к сожалению, выбираюсь что-то написать только к вечеру. А почему неуместно? Вполне себе стандартизированный. FTP сервера и клиенты есть везде и все друг с другом совместимы.
Это не так. Клиенты FTP совместимы до тех пор пока не ушли далеко от telnet-а. Как только к ним пытаются прикрутить какой-то UI, сразу появляются проблемы. Самая большая из них — в FTP никогда не было стандартизированной возможности получить список файлов с атрибутами (размер, права и т.д.). Точнее команда то есть, но её вывод не стандартизирован, так как предполагалось, что будет читаться человеком.
В 'современном' FTP это починено, только MLST умеют не все серверы и не все клиенты… Такой себе 'все друг с другом совместимы' честно говоря.
Наоборот. 'Консольные' клиенты выведут листинг как есть (грубо говоря аналог ls -l). А GUI-ным нужно это как-то парсить, чтобы красиво показать. Понятно что под 'популярные' серверы парсеры уже написаны.
Вот как это выглядит в жизни:
https://github.com/curl/curl/blob/master/lib/ftplistparser.c
Я не могу это называть "стандартизированно". FTP давно уже пора похоронить и забыть как страшный сон.
После обмена ключами используется много разных шифров: RC2, RC4, IDEA, DES и TripleDES. Также используется MD5
Копаться в книгах — хорошо, только не двадцатилетней давности :) И ниже по тексту тоже обновить надо. За примером далеко ходить не надо: нажать на зелёный замочек возле HTTPS. Curl с включенным дебагом вроде тоже покажет, во что может другая сторона.
Каждый раз, когда кто-то ещё шифрует с DES — умирает котёнок. А с 3DES — сразу три котёнка.
Главное, что отличает SFTP от стандартного FTP и FTPS, это то, что SFTP шифрует абсолютно все команды, имена пользователей, пароли и другую конфиденциальную информацию.
Коллеги, поясните, пожалуйста, что именно не шифруется в FTPS?
Явный – намного более удобен, так как использует команды стандартного FTP, но при ответе шифрует данные, что позволяет использовать одно и тоже управляющее соединение как для FTP, так и для FTPS. Клиент должен явно запросить защищенную передачу данных у сервера, а после утвердить способ шифрования. Если клиент не запросит защищенную передачу, FTPS сервер вправе как сохранить, так и закрыть незащищенное соединение. Механизм согласования идентификации и защиты данных был добавлен под RFC 2228 который включает в себя новую FTP команду AUTH. Хотя этот стандарт не определяет явно механизмы защиты, он определяет, что защищенное соединение должен инициировать клиент с помощью описанного выше алгоритма. Если защищенные соединения не поддерживаются сервером, должен быть возвращен код ошибки 504. FTPS клиенты могут получить информацию о поддерживаемых сервером протоколах защиты при помощи команды FEAT, тем не менее сервер не обязан разглашать то, какие уровни безопасности он поддерживает. Наиболее распространены FTPS команды AUTH TLS и AUTH SSL, обеспечивающие защиту TLS и SSL соответственно.
Из этого описания я делаю вывод что не шифруются команды отправляемые клиентом серверу, ответы сервера на команды и канал перадачи файлов шифруется, верно?
Протоколы SFTP и FTPS