= Сообщение: 5098 из 8555 ========================================= RU.LINUX = От : Anatoly Sablin 2:5020/2140.704 14 May 18 07:11:42 Кому : Victor Sudakov 14 May 18 07:11:42 Тема : Прокси сервер FGHI : area://RU.LINUX?msgid=2:5020/2140.704+5f34054f На : area://RU.LINUX?msgid=2:5005/49+5af88f2b = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.LINUX?msgid=2:5005/49+5af922dc ============================================================================== Hello, Victor Sudakov. On 14.05.2018 2:04 you wrote:
AS>> а следовательно для работы ftps нужно совершать дополнительные AS>> пассы руками (удобство? Нет, не слышали), чтобы завести всё. VS> Ты ошибаешься, в AUTH TLS шифруется только логин/пароль, а не VS> control connection целиком. На команды PORT, PASV и др. nat-ы и VS> firewall-ы могут глядеть сколько им угодно.
If unprotected commands are allowed on any connection, then an attacker could insert a command on the control stream, and the server would have no way to know that it was invalid. In order to prevent such attacks, once a security data exchange completes successfully, if the security mechanism supports integrity, then integrity (via the MIC or ENC command, and 631 or 632 reply) must be used, until the CCC command is issued to enable non-integrity protected control channel messages. The CCC command itself must be integrity protected.
Стандарт требует, чтобы после установления безопасного соединения все команды шифровались, а не передавались открытым текстом (по той же причине, зачем и нужен AUTH TLS - ради безопасности).
По поводу команды CCC, оттуда же предыдущий абзац:
It is desirable in some environments to use a security mechanism to authenticate and/or authorize the client and server, but not to perform any integrity checking on the subsequent commands. This might be used in an environment where IP security is in place, insuring that the hosts are authenticated and that TCP streams cannot be tampered, but where user authentication is desired.
То есть отключение шифрования для команд может быть обоснованно только для безопасной среды. Если торчит ftps наружу, то данный вариант не подходит и нельзя использовать этот вариант.
VS> Впрочем видел я где-то ftp-клиент и сервер с поддержкой Kerberos, VS> вот там действительно была жесть: шифровались все команды. Видимо VS> потому и не прижилось. AS>> У тебя, конечно же, используется ftps? VS> На моих серверах AUTH TLS всегда включен (правда сертификат VS> используется самоподписанный). Если кто-то из пользователей VS> использует клиент без поддержки AUTH TLS, то он ССЗБ. Сам я VS> разумеется хожу через AUTH TLS (мой любимый клиент - lftp).
Тау получается, что у тебя командный режим шифруется (в соответствии с rfc2228).
В таком случае, в чём преимущество перед тем же sftp?
-- Best regards! Posted using Hotdoged on Android --- Hotdoged/2.13.5/Android * Origin: Android device, Milky Way (2:5020/2140.704)
