Comments 78
Немного позанудствую: шифровать для этого необязательно, достаточно просто подписывать (у того же ВК все запросы к API таки подписывались, пока на HTTPS не перешли; криво-косо, правда, но не суть, суть в самой идее)
Но всё же картинки условного ВК шифровать надо как минимум затем, чтобы провайдер мои личные фотки не разглядывал (условному ВК я, допустим, доверяю, а провайдеру не очень)
Ну, теоретически допилить браузер, чтобы проверял, думаю, ничего не мешает. На практике все ударились в HTTPS и это никому не нужно)
Хотя вообще есть проверка чексумм для сторонних ресурсов типа CDN, но она другую задачу решает
Хотя вообще есть проверка чексумм для сторонних ресурсов типа CDN
Без шифрования трафика это не работает. Информация о том, какой должен быть хэш, передается либо в http-заголовках, либо в мета-тэге html-я.
Что мешает злоумышленнику поменять не только скрипт, но и указать в http-заголовках и мета-тэгах «правильный» хэш?
Ничего не мешает. Я ж сказал, этот механизм другую задачу решает, вы зануда ещё больше чем я.
Типа habrahabr — https; habrastorage — http.
Без шифрования трафика это не работает.
Вы:
Это работает, если у вас html идёт по https
Вопрос: а когда https у нас стал нешифрованным?)
Современный подход требует шифровать вообще всё (сайт, загружающий нешифрованные картинки помечается как «не совсем безопасный»)
Если это не так — ни о какой security речи быть не может.
А сейчас веб не имеет механизмов правил для медиа и требует всё передавать по защищённому(интересно распространяется ли паника «не-https» на стили, полученные по http, но с integrity). Я пытаюсь оппонировать именно позиции «передавать всё-всё-всё по защищённому, всё что не передаётся по защищённому — потенциально скомпрометировано», которую как раз и продвигает Хром.
сейчас веб не имеет механизмов правил для медиа и требует всё передавать по защищённомуНасколько я понимаю, непосредственно веб вполне позволяет задавать правила применительно к различным типам контента.
интересно распространяется ли паника «не-https» на стили, полученные по http, но с integrityЭто вопрос уже не к самой CSP, а к конкретной её реализации браузерами.
Лично я, например, навскидку не вижу проблем в описанном случае (контент, полученный по небезопасному каналу, который считается «разрешенным» автором сайта/сервиса).
Если же какой-то браузер считает по-другому, то никто не мешает завести соответствующий тикет и как минимум в процессе обсуждения понять, какую угрозу безопасности это может создать.
Пусть сервер вам отправил в корневой html
<script src="http://example.com/app.js"></script><script src="http://evil.com/evil_app.js"></script>Может, вы и останетесь защищены от подделки запросов/ответов (в случае, если при каждом обращении к API в ответе кроме собственно ответа будет приходить одноразовый токен для следующего обращения к API), но от прослушки и утечки данных налево — уже нет.
А без шифрования соединения защититься от такой подмены вы не сможете. Content security policy определяется в http-заголовках и мета-тэгах, а значит, также может (и будет) подменена злоумышленником.
Пусть сервер вам отправил в корневой html
Этот код, естественно, тоже должен быть подписан. И заголовки content security policy тоже должны быть подписаны. А если это всё подписано, то и трансформация в evil_app.js будет невозможна. Я прав :)
Про прослушку я и сам выше упоминал. Выкидывать шифрование и юзать только подписи я не призываю.)
Этот код, естественно, тоже должен быть подписан. И заголовки content security policy тоже должны быть подписаны. А если это всё подписано, то и трансформация в evil_app.js будет невозможна. Я прав :)
Как браузер проверит, что подпись — правильная и принадлежит example.com, а не вставлена злоумышленником?
Да хоть с помощью тех же HTTPS-сертификатов. Насколько я знаю, технически ничего не мешает юзать их как для шифрования, так и для подписи.
Расскажете, в чем смысл использовать механизмы сертификатов для наложения подписей, но не для шифрования всего трафика (hint: ассиметричное шифрование используется при установке соединения, сам трафик шифруется уже симметричным ключом)?
Я нигде не говорил и не собираюсь говорить, что в этом есть какой-то смысл. Я лишь немного позанудствовал, сказав, что для защиты от подмены данных достаточно подписи. Всё остальное вы додумали за меня.
Ещё раз, по пунктам персонально для вас:
- я НЕ утверждаю, что подпись лучше шифрования;
- я НЕ утверждаю, что браузеры должны реализовать создание и проверку подписей в протоколе HTTP;
- я НЕ утверждаю, что нужно бросать шифрование и переходить на подписи;
- я в первом же своём комментарии сказал, что всё равно всё нужно шифровать для скрытия данных. Чего вы до меня докопались — я не понимаю.
я в первом же своём комментарии сказал, что всё равно всё нужно шифровать для скрытия данных. Чего вы до меня докопались — я не понимаю.
Этот же самый комментарии был начат с утверждения, что шифрование необязательно для защиты от подмены контента.
Я тоже зануда, и согласен с автором первого комментария — для защиты от подмены контента «по дороге» нужна TLS.
Вы же утверждаете, что без шифрования соединения можно обойтись, но при этом на ходу начинаете придумывать механизмы, удивительно похожие на имеющиеся)
механизмы, удивительно похожие на имеющиеся)
Подписи, внезапно, базируются на тех же механизмах, что и шифрование, ага :)
Я лишь немного позанудствовал, сказав, что для защиты от подмены данных достаточно подписи.Нет, недостаточно.
Нужен механизм проверки аутентичности данной подписи.
Подписи, внезапно, базируются на тех же механизмах, что и шифрованиеДа, механизмы подписей и ассиметричного шифрования вообще, базируются на тех же механизмах.
А вот шифрование канала передачи включает в себя такие механизмы, как tls-handshake и certificate authority, решающие проблему проверки аутентичности сторон.
Именно эти существующие в tls механизмы Вы начали добавлять по ходу обсуждения в первоначально «достаточную» подпись.
Именно эти существующие в tls механизмы Вы начали добавлять по ходу обсуждения в первоначально «достаточную» подпись.
Это неотъемлемая часть подписи, я не знаю, с чего это вы вдруг решили, что я считал, что без них «достаточно», ничего подобного. Вы уже не зануда, вы просто выдумываете то, чего не было. Мне надоело опровергать несуществующие события, наверно я вам прекращу отвечать уже
При желании можно подделать и зашифрованный трафик.
Конечно, это будет достаточно сложно, но не невозможно. Естественно, для этого надо быть посредником в передаче трафика (например, провайдером или владельцем локальной сети с выходом в интернет) и иметь достаточно ресурсов, чтобы поднять свой DNS, свой удостоверяющий центр, имитирующий работу настоящего, настроить маршрутизацию и т.п…
Можно даже сделать так, что конечный пользователь ничего не заметит, кроме дополнительных тормозов.
А многим сайтам хватило бы проверяемой подписи. Тогда и достоверность подтверждается, и закэшировать можно без лишних проблем.
А с чего бы это браузеру пользователя доверять «своему удостоверяющему центру»? Здесь возможно только свой сертификат пользователям втюхивать, как это, например, делают в Казахстане, иначе невозможно
Хотя бы потому, что он отвечает, с точки зрения браузера как настоящий.
Там, конечно, есть ряд сложностей, но при желании и наличии ресурсов они вполне преодолимы. Например, при помощи уязвимости в ОС можно подменить пользователю браузер. В этом случае свой удостоверяющий центр нужен только для того, чтобы был трафик к удостоверяющему центру.
при помощи уязвимости в ОС
А, ну если так разве что… Но для этого сперва нужно найти подходящие уязвимости во всех популярных ОС всех популярных версий и каким-то образом защититься от переустановок
При желании можно подделать и зашифрованный трафик.Смелое заявление!
свой удостоверяющий центрА корневой сертификат (поддельного CA) пользователю как добавить?
+ косвенные деньги — процессорное время для работы с шифрованием вроде как не бесплатное.
Я не против самого SSL, но я против его повсеместного применения. Моим сайтам, нужным десятку человек в день, вполне себе хватает бесплатного шареда от провайдера и введение шифрования для меня будет дополнительной финансовой нагрузкой (смена тарифа как минимум), которые лично я нести не очень хочу, т.к. все проекты на энтуазизме.
Я же отметил- за счёт гугла как минимум. А на сайте LE указаны остальные 49 спонсоров.
Коммерческие компании вводят SSL чтоб их рекламу не резали провайдеры местечковые, а весь мир радуется защите… Заманчиво…
Сейчас большинство процессоров, включая серверные, имеют блоки ускорения AES.
А они не потребляют энергии? Оо
Проблемы вашего шареда, который не может ввести поддержку бесплатных сертификатов. Пишите в поддержку, пускай поправляют.
Даже не подумаю. Для моих нужд не нужен https, у меня там и авторизации нет, и пользовательских данных ноль.
В счетах за электричество этого не найти.
Ну да, только вот в масштабе датацетра я думаю это будет заметно.
Вы тут уже написали больше символов, чем нужно для открытия тикета с названием «Прикрутите бесплатные сертификаты от LE».
Еще раз: Мне НЕ НУЖЕН сертификат на мой го*сайт. Мне не нужен не платный, не бесплатный, со скидкой или без, от LE или нортона. Меня устраивает работа по обычному протоколу http, в одностороннем порядке — я показываю людям котиков, они радуются и закрывают картинку.
Я не буду писать провайдеру или доказывать вам и другим. Я лишь высказываю свою мысль, недовольство, собственно как и все остальные комментаторы на хабре.
Вопрос не в том, как ему быть с провайдером, а насколько (и почему) котики требуют шифрования.
Что случится если этот комментарий не будет зашифрован?
Что случится если график в посте не будет зашифрован?
Что случится если лого Яндекса не будет зашифровано?
Что случится если этот комментарий не будет зашифрован?
Туда будет встроена реклама от провайдера.
Что случится если график в посте не будет зашифрован?
Туда будет встроена реклама от провайдера.
Что случится если лого Яндекса не будет зашифровано?
Туда будет встроена реклама от провайдера.
Это если из относительно безобидного и не вспоминать про майнеры биткоинов и про RCE в png-файлах :)
В данном случае первая претензия моя в первую очередь эстетическая: инструмент (шифрование) используется ненадлежащим образом. При этом происходит определённое навязывание шифрования как вещи столь фундаментальной, как будто ничего вообще без него работать не может (включая запрос аптайма с роутера).
С практической точки зрения… ну я не имел бы ничего против, если бы мой провайдер кешировал у себя популярные ролики с ютуба, чтобы сэкономить на трафике и дать мне более высокую скорость. При этом ему бы не потребовалось получать у Гугла защищённое оборудование, могущее шифровать каждый ролик от имени Гугла. Подпись при этом может браться у Гугла, а вот данные уже локально.
В принципе я бы тоже был не против описанного вами, если предоставить выбор. Например, я не хочу, чтобы мой провайдер знал, что я смотрю, кхм, «овальные» ролики на ютубе, или что я любуюсь на котиков, которые выкладывает daggert на своём сайте — я хочу, чтобы это всё шифровалось (про всякие косвенные каналы, позволяющие даже при шифровании узнать, что я смотрю, пока молчу). Если отказываться от шифрования и ограничиваться подписью, то я буду лишён права выбора, и мне придётся подключать какой-нибудь VPN (но тогда уже владелец VPN будет знать, что я смотрю овального и котиков, мда).
То есть глубина паранойи определяется не потребителем, не источником, а интернетом как таковым. При этом тенденция в том, что даже источник не должен определять необходимо ли что либо шифровать или нет. Ну… мне не нравится, когда кто бы то ни было диктует что бы то ни было. Даже если это благожелательное сообщество беспокоится о моей безопасности.
Есть такая полезная штука — кэш между поставщиком контента и компьютером получателя. Внезапно, эта простая мера позволяет неплохо оптимизировать трафик.
Конечно, есть методы кэширования и для зашифрованного трафика, но это дополнительные сложности.
Можно поставщику контента, если он богатый, ставить локальные сервера в сети провайдера (как у гугла).
Можно применять методы, вынуждающие браузер ругаться на сертификат.
Но проще кэшировать незашифрованный контент.
Так что подписывание (теми же сертификатами, что и в HTTPS, на другом подобном механизме) вполне может пригодиться.
И это совсем не означает отказа от шифрования там, где оно действительно нужно.
Поясните пожалуйста…
Ну, понятно, что подписывать надо, например, каждое загружаемое через AJAX сообщение. Но эти сообщения всё ещё могут совпадать в части публичных данных.
Но в большей части я имел ввиду такие штуки как картинки или встраиваемые видео. В общем то, что описывается не как «сообщение» а как «данные».
Кстати видео — очень яркий пример абсурдности подписи на уровне приложения — вы должны скачать его целиком, чтобы проверить подпись :) Ну или подписывать динамически каждый переданный набор байт, что дороже, чем симметричное шифрование того же набора байтов.
Ну вот в целом вопрос сводится к а)может не значит будет; б)произвольности кусков.
То есть например если посмотреть на этот пост, то ни текст поста, ни картинки разбивать на части смысла нет.
Собственно и видео можно подписать некоторые куски размерами от GOP/Scene до эпизода.
Но в целом меня напрягает не то, что в большинстве случаев шифрование оказывается востребованным, а то, что, как следует из поста, «большинство» начинают экстраполировать на «всегда».
То, что данные могут биться на произвольные куски(или даже если данные часто бьются на произвольные куски) не означает, что никто не передаёт данные одним куском.
Разница в трудоёмкости зависит от сценариев использования: если вы постоянно отдаёте данные, которые не предполагается интерпретировать фрагментарно, при этом одни и те же (хостинг картинок), то подпись будет и энергетически/вычислительно эффективнее шифрования, поскольку вместо тысячи согласований сессии будет одно подписание.
habrahabr.ru/post/272253/#comment_8679103
Есть целые направления, где сертификаты не нужны чуть более чем полностью (локальные ресурсы, локальные сети, например). Есть более обширные направления, где должно хватать самоподписанных сертификатов (закрытые сети организаций, например). Но нет — или «плати за то, что мы поддерживаем» или полируй эбонитовую палочку шерстяной тряпочкой вприсядку подстраивая под себя каждый второй браузер и рассказывай каждому первому пользователю, что это не страшно и так и задумано.
То есть замысел как-бы хороший и правильный, но исполнение слишком уж суровое.
Например, в Казахстане для этого сертификаты сайтов подменяются национальным сертификатом безопасности
Это не соответствует действительности. Да, статья по ссылке компрометирующая, однако дальше инициатив дело не пошло и никаких нац. сертификатов не используется, кроме сайтов госуслуг.
Chrome 68 будет помечать все сайты HTTP как «небезопасные»