Разработчики проекта Chromium сообщили (https://groups.google.com/a/chromium.org/forum/#!msg/securit...) о решении помечать обращение к ресурсам по протоколу FTP как небезопасное соединение. Изменение будет доведено до пользователей в релизе Chrome 63, намеченном на декабрь. По статистике Google число обращений по FTP оценивается на уровне 0.0026% от общего числа начальных запросов. При этом протокол FTP рассматривается как уступающий HTTP по уровню защиты, так как у HTTP есть возможность применения HSTS (HTTP Strict Transport Security) для автоматизации проброса на HTTPS. Администраторам FTP ресурсов рекомендуется последовать примеру (https://www.opennet.ru/opennews/art.shtml?num=45935) kernel.org и перевести серверы загрузки на применение HTTPS.
URL: https://groups.google.com/a/chromium.org/forum/#!msg/securit...
Новость: https://www.opennet.ru/opennews/art.shtml?num=47204
Ага, даешь https для передачи всех сорцов. И в каждую кофеварку. И в пределах одной машины тоже. Мне кажется, они там совсем уже поехали.
Почему же поехали. Это же браузер, их наверное заботит то, что по ftp может быть загружен js- или html-файл без шифрования соединения. В этом плане он от http не сильно отличается.
Мне вот, что интересно, а если запретить кроссдоменные запросы вообще (от слова полностью), то безопасность просто взлетит до небывалых небес. И что они ждут :-D
Так можно запретить уже сейчас. uMatrix в помощь.
Я вообще за локальные HTML страницы.
сам создал, сам посмотрел, клёво и безопасно :)
> а если запретить кроссдоменные запросы вообще (от слова полностью), то безопасность
> просто взлетит до небывалых небеса заодно исчезнет возможность подглядывания за пользователями дерьмосайтов, владельцам и горе-сайтописателям которых не приходит в голову, почему тянуть в рот всякую каку с cdn'ов (гугля ;-) а то и вовсе с rawgit - совершенно идиотская и при этом вредная привычка.
мы на это пойтить не могем.
А вот по ftp мы уже давно ничего не раздаем, слишком сложный для нас протокол. А если вы раздавали, то больше не будете. Товарищ майор должен покупать данные у нас, а не получать на халяву прямо со сниффера.
Да бог с ними с CDN. Для распространенных либ уже дополнения с локальными копиями есть. И кеширование хорошее.Но ведь все рекламные сетки отвалятся! Этого допустить никак нельзя!
Развалится же весь уеб :)Я даже больше напишу: у меня есть железка с реле, всякими GPIO, ADC - короче для умного дома). Так вот ее вебморда тянет jquery и bootstrap с каких-то модных cdn. То есть зайти на нее в сетке где нет инета просто невозможно! :facepalm: Хорошо что эти чудаки хоть snmp для нее сделали.
Это фэйспалм конечно. Пользуйся нормальными железками и прошивками :).//Transmission от таких поползновений отучили.
есть же ftps
в SFTP и то больше смысла
Создал бы кто новый FTP, всего то и надо:
- Такой же простой как FTP;
- Без дури с сетью, ACTIV*\PASSIV* и др. УЁ :-\
- C параллельными get- put- ; (да вообще - взять и реюзнуть код HTTP/2 ?)
- Возможно даже с отключаемым шифрованием собственно файлового трафика. Аутентификация - безальтернативно шифрованная;
- Чтобы понимал PAM\GSSAPI\локальные базы юзеров AKA .htpass и чтобы можно было скормить те же сертификаты, что и для web-сервера;
- Должен не уметь запускать команды на хосте и на клиенте;
- Должен чрутить клиента на запрашиваемый ресурс (на хомяка?);
- Ну и желательно чтобы клиент мог маунтить ресурс в fs tree типо nfs-a;Неужто никому не надо?
> Неужто никому не надо?А зачем, раз уж HTTP/2 уже есть?
> А зачем, раз уж HTTP/2 уже есть?Собссно PUT был даже в первой версии.
Протокол не должен никого чрутить, это делает реализация ПО. И запихивать это в стандарт такая себе идея. То же с сертификатами.
Вообще, WebDAV же есть.
> Неужто никому не надо?ну, в общем-то, у нас уже есть... ftp ;-)
"дурь с сетью" на самом деле вовсе не дурь, а вполне разумная идея отделить командный канал от данных (то что кривые пакетные фильтры и дрянные наты не способны это переварить - решительно не проблема протокола, а проблема использующих кривые фильтры и дрянные наты)
Напоминаю, что в изначальном варианте PORT мог содержать не только _твой_ ip.
Другое дело, что никто как-то не собрался сделать нормальной реализации.параллельным put/get в общем быть ничто не мешает, кроме древности и кривизны доступных серверов.
аутентификация - есть otp, не нуждающийся в шифровании чего не надо, и стойкий к мэну-за-плечом, жаль, опять же, что хороших современных генераторов не найти.
шифрование траффика - в целом, ненужно. Для проверок аутентичности есть pgp подписи (у которых дополнительный бонус - что когда не нужны, просто не проверяй), боишься в принципе засветить траффик - лучше всего убрать его весть в ipsec.> Должен не уметь запускать команды на хосте и на клиенте;
зачем? Прелесть ftp в том что он это умеет, и при этом это ни разу не шелл (ахиллесова пята sftp). И да, фичи wu-ftpd с get somebigdir.tar мне очень не хватает.
остальное уже есть в существующих серверах и клиентах.
> то что кривые пакетные фильтры и дрянные наты не способны это переварить - решительно не проблема протокола, а проблема использующих кривые фильтры и дрянные натыЭто как раз проблема протокола. Какой бы не был прямой фаервол - ему всё равно придётся заглядывать внутрь пакета и смотреть какой там порт был передан с командой. А это лишняя трата ресурсов, в отличии от фильтрации по заголовкам TCP/IP (это вообще можно при желании оффлоадить).
Если ftp-сервер использует полтора человека, то пофигу конечно.А NAT это конечно кривая штука сама по себе, но это реальность в которой мы сейчас живём и уйти от неё в ближайшем будущем мы не сможем (привет IPv6, как ты там?).
Ну и штука которая мне в ftp очень не нравится - медленная передача большого количества мелких файлов.Протокол был полезен и был с нами долгие годы служа нам верой и правдой, но теперь ему пора на покой, он не подходит для современных реалий.
>Протокол был полезен и был с нами долгие годы служа нам верой и правдой, но теперь ему пора на покой, он не подходит для современных реалий.При этом он намного удобнее в использовании чем MTP, передаю через FTP по локалке файлы между компом и мобилой и не нарадуюсь.
> Неужто никому не надо?Кому надо, давно настроили sftp в openssh, без шелла и с авторизацией по ключам, и горя не знают.
> Почему же поехали. Это же браузер, их наверное заботит то, что по
> ftp может быть загружен js- или html-файл без шифрования соединения. В
> этом плане он от http не сильно отличается.Может быть загружен любой файл, пропатченый по пути кем-то посторонним, так что в нем окажется совсем не то. Качал ты файрфокс, а тебе скачался зверь-лиса, с пятью тулбарами и троянцем для майнинга биткоинов.
Надо создать hftps который может работать только с сертификатами letsencrypt
Если сертификат выдан другим сервисом, помечать его как незащищенный.
И вообще надо все что не google помечать незащищенным.
Вы слишком радикальны в этом плане.Переезд с FileTransferProtocol на HypertextTransferProtocolSecured немного ломает понятие передачи файлов. Теперь вместо файлов будет всегда передаваться гипертекст.
Может теперь отбросить определение "файл" заменив его понятием "гипертекст"? (Получается по мнению Google: File is Hypertext.)
Меньше цепляйтесь за названия
> Меньше цепляйтесь за названияА вы логику включите. (Я хоть и понимаю что через HTTP{/,S} можно передавать файлы, но протокол явно(Как назвали, так его и следует использовать.) не предназначен для этого.)
А для чего же он предназначен? В чём принципиальное отличие гипертекста от любого другого файла с точки зрения HTTP?
> А для чего же он предназначен?По идее он предназначался для передачи текстовых сообщений оформленных по определенному правилу.
> В чём принципиальное отличие гипертекста от любого другого файла с точки зрения HTTP?
Используя гипертекстовый протокол передается гипертекстовое сообщение => любой файл на стороне сервера это есть оформленное по определенному правилу текстовое сообщение.
(Если я прав/неправ, хорошо приму к сведенью.)
> Надо создать hftps который может работать только с сертификатами letsencrypt
> Если сертификат выдан другим сервисом, помечать его как незащищенный.нет, это неправильно. Пользователь туп и может понять неверно.
Надо выдавать огромную КРАСНУЮ страницу, на которой написана какая-то непонятная пользователю и бессмысленная для админов и разработчиков херня.
С единственной видимой без лупы и приседаний огромной кнопкой "показать котиков!" (и кнопкой поменьше - "пожаловаться". нам страсть как интересно, по каким это неправильным сайтам вы лазаете)
> Надо создать hftps который может работать только с сертификатами letsencrypt
> Если сертификат выдан другим сервисом, помечать его как незащищенный.Удали у себя все CA кроме letsencrypt, получишь желаемое.
Так и будет, и это правильно.
> Ага, даешь https для передачи всех сорцовА как же. Иначе скачаются пропатченые по пути каким-нибудь умником.
> Мне кажется, они там совсем уже поехали.
Это ты поехал и не понимаешь самых базовых реалий в современном состоянии дел. Когда качаемый сорец может оказаться слегка протрояненым.
> помечать обращение к ресурсам по протоколу FTP как небезопасное
> соединение.Про gopher забыли, оболтусы.
> Про gopher забыли, оболтусы.Так ведь в Chrome нету поддержки gopher. Разве что через аддон -- но это уже не официальная поставка, так что не их забота.
У гофера даже (s) расширения нету.Единственный более-менее популярный (более 3х людей этим пользуются!) уровень шифрования там через onion initiative, "развиваемый" в рамках bitreich.
Представить chromium со встроенной поддержкой тора — сложно, представить гугл поддерживающий людей мечтающих убить современный вэб как явление — невозможно.
> Представить chromium со встроенной поддержкой тораА зачем ему встроенная? На onion он может сходить и обычным методом - через tor в виде socks5 который указан браузеру. Tor сам все сделает.
Идите вы в попу! Очень удобно выкачивать файловые архивы при помощи Filezilla.
Да хоть TotalCommander!
Речь ведь о WEB-браузерах.
вы говорите так, будто в хроме запретили пользоваться ftp
> вы говорите так, будто в хроме запретили пользоваться ftpОн говорит так, как будто изменения в хроме как-то затрагивают работу FileZilla
Как-то иконка перед надписью "Not secure" мало похожа на фекалии мамонта. Непорядок.
> Как-то иконка перед надписью "Not secure" мало похожа на фекалии мамонта. Непорядок.Ассенизаторы-археологи в треде..!
> Ассенизаторы-археологикопрофилы-палеонтологи
Очень правильно. Всё нешифрованное должно отмереть.
> Всё нешифрованное сертификатами, которые Google считает "доверенными", должно отмереть.Fixed.
> Очень правильно. Всё нешифрованное должно отмереть.Шифрование ради шифрования не нужно. Зачем шифровать публично доступные сайты типа блогов и хоумпаг, например? Обычно в ответ слышу всякий визг о подсовывании левого кода опсосами и хозяевами вайвай-точек — ну так их право, они задёшево связь предоставляют, не хотите — голосуйте рублём, не за кого голосовать — обращайтесь в антимонопольный комитет. А весь этот протестный криптоанархизм в век радикально потребительского отношения общества к IT и трансформации общества в большую деревню, где все всё про друга знают, грозит перерасти (уже перерастает) в нечто априори противоправное: есть что скрывать — вон из социума.
> Шифрование ради шифрования не нужно. Зачем шифровать публично доступные сайты типа блогов
> и хоумпаг, например?Потому что иначе MITMы всех мастей и прочие умники начинают лезть в чужой трафф. Некоторые настолько офигели что им уже недостаточно шпионить, они еще и хакать хотят, начиная от отгрузки троянов до врезки своей рекламы.
> есть что скрывать — вон из социума.
Это ты приперся к нам и смеешь учить нас как нам жить? Убирайся.
> Очень правильно. Всё нешифрованное должно отмереть.Угу. Кому он нужен, этот ваш email?! Он по умолчанию не шифрованный, должен отмереть немедленно я сказал! :)
Как это ты разместил у себя на машине index.html с текстом "привет я вася", и отдаёшь без шифрования?! Явно замыслил недоброе. :)
Кому нужны широковещательные трансляции? Будем отдельно транслировать каждому, и шифровать-шифровать-шифровать. :)
> Угу. Кому он нужен, этот ваш email?! Он по умолчанию не шифрованный, должен отмереть немедленно я сказал! :)Не знаю, на моём сервере все нешифрованные соединения идут лесом. Да, дебиановский багтрекер тоже идёт лесом.
> Угу. Кому он нужен, этот ваш email?! Он по умолчанию не шифрованный,
> должен отмереть немедленно я сказал! :)Ну, в e-mail хотя бы есть опциональная поддержка шифрования (клиент-серверная и сервер-серверная), да и большинство популярных почтовых серверов используют шифрование по-умолчанию для SMTP.
Т.е. про ftps эти чудики даже не слышали?
> Т.е. про ftps эти чудики даже не слышали?т.е. про технологию, обламывающуюся о первый же _надежно_ настроенный файрволл? Слышали, слышали, как и еще про массу поделок недоучек, вчера узнавших про openssl и начавших пихать ее куда ни попадя, не давая себе труда подумать головой. Поддерживать не собираемся, пусть себе сдохнет спокойненько.
И нет, в данном случае рептилоиды не в наших рядах.
Самый надежно настроенный файрвол - это отсутствие у вас компьютера.
Покажите мне сервер с поддержкой этого.
Имею в виду не софт, а именно публичный сервер.
ftp://serv.valdikss.org.ru/
уже давно пора перейти на SFTP
SFTP не умеет в анонимный доступ
> SFTP не умеет в анонимный доступанонимного доступа и в фтп нет, браузер или другой клиент фтп посылают туда определённое имя! ftp, Anonymous, guest или что-то другое. и если имя из списка допустимых, то клиент считается анонимным, нет, то проверяется в базе обычных пользователей, если там тоже нет, то доступ блокируется!
Пишешь ftp://DmAblablabla@mirror.yandex.ru и они уже требует пароль(хотя такого пользователя явно там нет), а пишешь ftp://ftp@mirror.yandex.ru вводишь любой пароль и вот ты завалился как ftp пользователь
> ftp, Anonymous, guest или что-то другое. и если имя из списка допустимых, то клиент считается анонимным,ну вроде как логично. можно конечно замапить всех несуществующих юзеров на anonymous - вроде некоторые фтп серверы так умеют. но зачем?
> SFTP не умеет в анонимный доступкстати, да. анонимный фтп с поддержкой аплода - очень удобная штука. для той же функциональности на https придется кучу блотвари (скрипты и т.д.) на сервер поставить.
Зачем скрипты для заливки файлов через метод PUT?
> Зачем скрипты для заливки файлов через метод PUT?А если про конкретную рабочую реализацию? WebDAV?
>> SFTP не умеет в анонимный доступ
> кстати, да. анонимный фтп с поддержкой аплода - очень удобная штука. для
> той же функциональности на https придется кучу блотвари (скрипты и т.д.)
> на сервер поставить.Достаточно создать в системе аккаунт anonymous и задать ему пароль guest.
Однако, в этом случае блотварью будет SSH-сервер и шелл ОС.
Мне казалось, что RFC 4217: Securing FTP with TLS, не реализован в Chrome, но, даже если бы он был реализован, как бы это влияло на тот факт, что FTP является не безопасным с точки зрения того, что передаваемые данные открыты?То есть вы согласны, что логично было бы видеть в таком случае надпись Secure, только для FTP over TLS и Not Secure для FTP? Как сейчас это сделано для случая с HTTP и HTTPS.
Самое интересное что про TelNet нет ни слов, ни статей в последнее время.Вроде отмер, а вроде ещё жив(Используется).
А каких статей вы ждёт о telnet? К слову мы же про RFC 854: TELNET PROTOCOL SPECIFICATION говорим?Протокол существует не один десяток лет, его недостатки с точки зрения защиты передаваемых команд давно известны, любое руководство по безопасности Management Plane содержит рекомендации по использованию SSH или любого другого подходящего защищённого протокола.
В случае, когда использование telnet строго регламентировано, следует использовать внешние по отношению к telnet протоколы и механизмы для обеспечения защищённого канала передачи данных, например IPSec.
> Протокол существует не один десяток лет, его недостатки с точки зрения защиты передаваемых команд давно известны, любое руководство по безопасности Management Plane содержит рекомендации по использованию SSH или любого другого подходящего защищённого протокола.
> В случае, когда использование telnet строго регламентировано, следует использовать внешние по отношению к telnet протоколы и механизмы для обеспечения защищённого канала передачи данных, например IPSec.Все отвечено верно.
> А каких статей вы ждёт о telnet?
Об его официальном и явном прекращении его использования всеми без исключений.
> К слову мы же про RFC 854: TELNET PROTOCOL SPECIFICATION говорим?
Да, верно.
А кем всеми? В Windows начиная по-моему с Windows Vista он идёт отдельным пакетом, не установленным по умолчанию. В Unix like среде, включая GNU/Linux и подавно никто не заставляет других использовать telnet.
> А кем всеми? В Windows начиная по-моему с Windows Vista он идёт отдельным пакетом, не установленным по умолчанию. В Unix like среде, включая GNU/Linux и подавно никто не заставляет других использовать telnet.netcat вам на что? Telnet там ещё остался.
От Telnet'а не откажешься, невозможно т.к это часть любого TCP-сокета. (Если неправ, то покажите мне это так чтобы было понятно не только мне.)
Я не понимаю к чему вы ведёте? Мне не понятно какой результат вы хотите видеть в конечном счёте?
> От Telnet'а не откажешься, невозможно т.к это часть любого TCP-сокета.Кто сказал такую глупость? Читай man socket. Telnet всего лишь один из возможных протоколов поверх TCP/IP. Некоторые текстовые протоколы (SMTP, POP3, HTTP 1.x, IRC, ...) можно изобразить программой предназначенной изначально для телнета. Правда протокол будет реализовывать сам человек путем ввода соответствующих конструкций. Для более бинарных протоколов типа HTTP/2, Torrent и проч - номер не прокатит.
Вас я понял, да это верно с вами полностью согласен.Запутался в своих словах в частности про TCP-Socket.
>> А каких статей вы ждёт о telnet?
>Об его официальном и явном прекращении его использования всеми без исключений.Запрещун, тля :)
Ну подумай - вот как ты можешь что то там запретить ну скажем мне? :)
Ты можешь сказать что ты такой протокол у себя не поддерживаешь, и всио ...
Это - Интернет, детка!(С)
> Ну подумай - вот как ты можешь что то там запретить ну скажем мне?Сказать что небезопасно его использовать? Да все это знают и продолжают использовать.
Неудобный протокол? Особых неудобств я пока не видел.
Юридический не обосновано разрешение его использования? А запрета на его использование нет и не будет.(В ветке выше описал почему так, а не иначе.)> Запрещун, тля
Запретить нельзя, разрешить.
Только смысла в этом запрете нет.> Ты можешь сказать что ты такой протокол у себя не поддерживаешь, и всио ...
Из комментария выше.
"официальном и явном прекращении его использования"
Такого не будет, глупо слишком.> Это - Интернет, детка!(С)
Ну это вы к месту. :D
> Из комментария выше.
> "официальном и явном прекращении его использования"
> Такого не будет, глупо слишком.Угу. Особенно учитывая засилье дешёвых роутеров (напр. dlink-ов), у которых telnet наружу по умолчанию торчит, и вендора это не колышет. ;)
> Самое интересное что про TelNet нет ни слов, ни статей в последнее время.Как это нет? В новости про каждую вторую роутерную малварь упоминается как средство распространения.
> Как это нет? В новости про каждую вторую роутерную малварь упоминается как средство распространения.Похоже я проглядел, спасибо буду пересматривать старые новости. (Хотя в роутерах можно и IP-ACL настроить под это, только всё равно будет обходится, IP и MAC можно менять => любой ACL и прочее бесполезно.)
С каких это пор пользователей Хрома стала интересовать безопасность?
Они просто и не заметят этого "not secure"!
Гугл просто пиарится!
Да просто помечать всё, что не https как небезопасное да и делу край :-)
lftp уже некоторое время поддерживает HTTP/HTTPS.$ lftp https://www.kernel.org/pub/
cd ok, каталог=/pub
lftp www.kernel.org:/pub> ls
drwxr-xr-x -- ..
drwxr-xr-x - 2011-12-01 19:56 dist
drwxr-xr-x - 2014-11-11 21:50 linux
drwxr-xr-x - 2008-09-23 23:35 media
drwxr-xr-x - 2017-04-18 18:28 scm
drwxr-xr-x - 2013-08-09 17:23 site
drwxr-xr-x - 2011-11-27 17:31 software
drwxr-xr-x - 2008-04-30 22:31 tools
lftp www.kernel.org:/pub> get tools/crosstool/files/patches/patches.tar.bz2
951102 байта перемещены за 2 секунды (446.1 Киб/с)
lftp www.kernel.org:/pub>
> lftp уже некоторое время поддерживает HTTP/HTTPS.Он уже давно поддерживает HTTP как минимум. Пользуюсь им для скачивания с подобных сайтов, очень удобная штука, особенно если нужно рекурсивно выкачать каталоги.
FTP устарел. Пользуйтесь SFTP (SSH File Transfer Protocol).
Ок, а что делать с DVR который не понимет sftp? а вот ftp понимает
Подростков послушать, все вокруг устарело.