Google и Mozilla давно агитируют за повсеместное шифрование веб-трафика и установку сертификатов SSL/TLS. В 2013 году по инициативе Mozilla создана организация Internet Security Research Group, которая в 2015 году запустила сервис Lets's Encrypt по автоматической выдаче бесплатных сертификатов для TLS-шифрования. Google является платиновым спонсором этого сервиса.
Сегодня любой сайт может внедрить HTTPS без особых проблем (см. «Полное руководство по переходу с HTTP на HTTPS»). Более того, в наше время HTTPS практически обязателен для каждого веб-сайта: Chrome и Firefox уже сейчас помечают как небезопасные веб-сайты с формами на страницах без HTTPS. Отсутствие HTTPS влияет на позиции в поисковой выдаче и оказывает серьёзное влияние на приватность в целом.
А дальше сайтам HTTP станет ещё труднее жить. Разработчики браузера Chrome объявили, что с версии Chrome 58 в июле 2018 года начнут помечать как небезопасные не только страницы с формами, но абсолютно все страницы HTTP. Сообщение о небезопасности сайта пользователи увидят в адресной строке рядом с URL сайта (см. скриншот вверху).
Разработчики Chrome отмечают, что за прошлый год очень большую часть трафика в интернете удалось перевести на HTTPS. Сейчас в зашифрованном виде передаётся:
- Более 68% трафика Chrome на Android и Windows
- Более 78% трафика Chrome на Chrome OS и Mac
- 81 из 100 крупнейших сайтов интернета установили HTTPS по умолчанию
Например, скачок популярности HTTPS в прошлом году произошёл в Японии. Сертификаты установили крупные сайты вроде Rakuten, Cookpad, Ameblo и Yahoo Japan, а доля HTTPS-трафика в Chrome под Windows подскочила с 31% до 55%.
В США доля зашифрованного трафика за прошлый год выросла с 59% до 73%.
Сама компания Google перевела все свои сервисы на HTTPS по умолчанию.
«Новый интерфейс Chrome поможет пользователям понять, что все HTTP-сайты являются небезопасными. Он способствует дальнейшему движению веба к использованию защищённого стандарта HTTPS по умолчанию, — сказано в официальном блоге Chromium. — Сейчас установить HTTPS проще и дешевле, чем когда бы то ни было, и он открывает возможности по улучшению производительности и мощные новые функции, которые слишком деликатны для HTTP».
Что ж, компания Google верна своему слову. Ещё в сентябре 2016 года она пообещала, что начнёт помечать как небезопасные все сайты HTTP, и вот с июля 2018 года это произойдёт.
По такому же пути идёт и браузер Firefox. Начиная с версии Firefox 51 (вышла в январе 2017 года) помечаются как небезопасные страницы HTTP, на которых нужно вводить пароли. В адресной строке для них указан значок с перечёркнутым замком.
С точки зрения восприятия пользователями это важное изменение интерфейса. Исследования показали, что пользователи не воспринимают отсутствие зелёной иконки с замочком «Защищено» в качестве предупреждения. Явное указание на опасность сайта — прямо в адресной строке — станет заметным изменением.
Таким образом, в ближайшее время можно ожидать массового обращения сайтов за сертификатами TLS. После появления бесплатных краткосрочных сертификатов Let's Encrypt, расчитанных только на защиту домена (DV) доля сайтов HTTPS начала быстро расти, но до сих пор она не слишком велика. Например, по статистике за январь 2018 года, в Рунете из 4 016 205 узлов валидные сертификаты TLS есть только у 405 698, самоподписанные — у 32 395. Количество корректных узлов HTTPS составляет 458 674. То есть доля корректных узлов HTTPS в Рунете — всего лишь 11,4%.
Но это всё равно значительный прогресс, ведь ещё в июле 2015 года количество корректных узлов HTTPS в Рунете составляло скромные 34 305 штук, то есть 0,9% от общего количества. После этого начался достаточно устойчивый рост числа действующих сертификатов.
Количество корректных узлов HTTPS в Рунете с июля 2015-го по январь 2018 года. Источник: statdom.ru
Да и нужно понимать, что «живых» веб-узлов в Рунете очень мало. Здесь статистики нет, но коды Google Analytics обнаруживаются только на 534 тыс. веб-узлов, а «Яндекс.Метрика» — на миллионе с небольшим. Хотя устанавливать эти следящие трекеры крайне не рекомендуется, но они служат косвенным показателем, сколько примерно активных узлов в Рунете. Так что среди сайтов с реальной поддержкой доля HTTPS может быть ближе к 40-50%. Кстати, это соответствует данным телеметрии Mozilla: доля веб-страниц HTTPS в браузере Firefox сейчас составляет около 49%.
Возможно, на рост популярности TLS в России повлияло и ужесточение слежки за гражданами в интернете, в том числе принятие так называемого «закона Яровой», который требует сохранения всего интернет-трафика. Правда, по этому закону операторы и веб-сайты обязаны предоставлять ключи шифрования (см. утверждённый порядок получения ключей шифрования от интернет-сервисов). Если владелец сервера отказывается предоставить ключ, необходимый для расшифровки трафика, на него может быть наложен штраф в миллион рублей. То есть спецслужбы рассчитывают отслеживать и зашифрованный трафик.
Не совсем понятно, как будет реализована расшифровка трафика в случае с веб-узлами TLS. Например, в Казахстане для этого сертификаты сайтов подменяются национальным сертификатом безопасности, выпущенным Комитетом связи, информатизации и информации. Возможно, и в России будет реализовано нечто подобное.
Но в случае использования стандартного сертификата TLS от доверенного Центра Сертификации, например GlobalSign «предоставить ключи» фактически невозможно, потому что для шифрования соединения каждый раз генерируется новый сеансовый ключ на базе сертификата сервера, открытого ключа клиента и сгенерированных случайных чисел.
Разработчики браузеров дают понять, что каждому сайту нужно шифрование HTTPS. Так и есть. Каждому сайту есть что терять: это или информация о пользователях, или репутация, или просто защита от внедрения сторонних баннеров и криптомайнеров на страницы, например, со стороны провайдера или WiFi-хотспота, через который идёт трафик. Если пользователь подключается к любому сайту по незащищённому каналу HTTP, то он фактически открывает свой браузер для любого постороннего кода, который захотят запустить на компьютере посторонние лица. И представьте, что будет, если уязвимости вроде Meltdown и Spectre можно эксплуатировать через JavaScript?
Комментарии (77)
andreymal
19.02.2018 12:24Ну и нахрена мне пихать HTTPS в мой роутерный 192.168.1.1, доступ к которому есть только по непосредственно подключенному к нему кабелю?
SirEdvin
19.02.2018 15:24Не обязательно, но вы просто будете видеть плашку «Небезопасно». Вроде не так плохо, нет?
andreymal
19.02.2018 15:28Не совсем: мой фаерфокс уже давно забыл пароль от роутера, потому что HTTPS отсутствует, приходится каждый раз руками набирать. Хром пока вроде бы запоминает, но нет уверенности, что так останется и в будущем или что в будущем не добавится каких-нибудь новых ограничений
daggert
19.02.2018 13:28-1Сегодня гугл решает что с людей надо больше денег брать за ssl, завтра он начнет контролировать какие центры сертификации ему выгодны. Монополия, мать ее… А ведь еще недавно все так радовались концу моноплии IE…
OnYourLips
19.02.2018 13:45Гугл ничего не запрещает и не навязывает.
Он просто начинает помечать небезопасные сайты (сайты, содержимое которых может быть перехвачено и/или подменено третьими лицами) как небезопасные.andreymal
19.02.2018 14:37Сегодня просто помечает, завтра не открывает без добавления в исключения, послезавтра не открывает вообще, послепослезавтра Let's Encrypt закрывается и оставшиеся сертификаты резко дорожают… [/параноик_mode]
daggert
19.02.2018 14:50Это запрет и навязывание. Прямое использование своей монополии для навязывания технологии. Завтра он решит вообще не заходить на сайты без https и все, половина шаредов глубоко в ..., тогда как многим он вообще не нужен.
sumanai
19.02.2018 14:54половина шаредов глубоко в ...,
Они уже там, туда им и дорога, как и хостингам, которые за установку сертификата требуют отдельной платы. Я понимаю, что так делали 10 лет назад, когда SNI не так хорошо поддерживался, но в 2018 это свинство, которое должно быть наказано.daggert
19.02.2018 15:00А что вам не нравится в шареде? Или вы предпочтете криво настроенный VPS, который может стать частью ботнета, после его настройки по первой инструкции с интернета? Разница для простого смертного большая — найти и поставить бложик на шареде, и найти и поставить бложик на VPS'е. Это уровень вообще разный.
sumanai
19.02.2018 15:05Мне всё нравится, в нормальных хостерах, которые имеют актуальный софт, возможность настройки всего и вся, выбор версии из всех актуальных и парочки устаревших, нормальную панель, возможность настроить nginx + php-fpm и прочее. С такими я с удовольствием работаю. А вот говношареды с выбором между PHP 5.2 и PHP 5.3, без сертификатов и прочего, должны умереть в конкурентной борьбе, и требование сертификатов лишь приблизит их смерть.
sumanai
19.02.2018 14:28Сегодня гугл решает что с людей надо больше денег брать за ssl
При помощи поддержки LE, который выдаёт сертификаты всем и бесплатно? Странные решения.
А монополия да, всё близится. FF умер в моих глазах, браузеры от МС имеют свои приколы, остальные перешли на движок хрома. Печально.daggert
19.02.2018 14:55А простите за чей счет пир с LE? Я как-то не доверяю продуктам которым я не плачу деньги, ибо иначе я становлюсь их продуктом. И почему я должен доверять их центру? Совсем недавно symantec был доверенным и надежным. И где гарантии что они не введут платную подписку, когда хром станет весь простой трафик помечать как небезопасный?
+ косвенные деньги — процессорное время для работы с шифрованием вроде как не бесплатное.
Я не против самого SSL, но я против его повсеместного применения. Моим сайтам, нужным десятку человек в день, вполне себе хватает бесплатного шареда от провайдера и введение шифрования для меня будет дополнительной финансовой нагрузкой (смена тарифа как минимум), которые лично я нести не очень хочу, т.к. все проекты на энтуазизме.sumanai
19.02.2018 15:02А простите за чей счет пир с LE?
Я же отметил- за счёт гугла как минимум. А на сайте LE указаны остальные 49 спонсоров.
+ косвенные деньги — процессорное время для работы с шифрованием вроде как не бесплатное.
Сейчас большинство процессоров, включая серверные, имеют блоки ускорения AES.
Моим сайтам, нужным десятку человек в день, вполне себе хватает бесплатного шареда от провайдера и введение шифрования для меня будет дополнительной финансовой нагрузкой (смена тарифа как минимум),
Проблемы вашего шареда, который не может ввести поддержку бесплатных сертификатов. Пишите в поддержку, пускай поправляют.daggert
19.02.2018 15:06Я же отметил- за счёт гугла как минимум. А на сайте LE указаны остальные 49 спонсоров.
Коммерческие компании вводят SSL чтоб их рекламу не резали провайдеры местечковые, а весь мир радуется защите… Заманчиво…
Сейчас большинство процессоров, включая серверные, имеют блоки ускорения AES.
А они не потребляют энергии? Оо
Проблемы вашего шареда, который не может ввести поддержку бесплатных сертификатов. Пишите в поддержку, пускай поправляют.
Даже не подумаю. Для моих нужд не нужен https, у меня там и авторизации нет, и пользовательских данных ноль.
sumanai
19.02.2018 15:21А они не потребляют энергии? Оо
В счетах за электричество этого не найти.
Для моих нужд не нужен https, у меня там и авторизации нет, и пользовательских данных ноль.
Вы тут уже написали больше символов, чем нужно для открытия тикета с названием «Прикрутите бесплатные сертификаты от LE».daggert
19.02.2018 15:31В счетах за электричество этого не найти.
Ну да, только вот в масштабе датацетра я думаю это будет заметно.
Вы тут уже написали больше символов, чем нужно для открытия тикета с названием «Прикрутите бесплатные сертификаты от LE».
Еще раз: Мне НЕ НУЖЕН сертификат на мой го*сайт. Мне не нужен не платный, не бесплатный, со скидкой или без, от LE или нортона. Меня устраивает работа по обычному протоколу http, в одностороннем порядке — я показываю людям котиков, они радуются и закрывают картинку.
sumanai
19.02.2018 15:38Ну да, только вот в масштабе датацетра я думаю это будет заметно.
Может быть.
Еще раз: Мне НЕ НУЖЕН сертификат на мой го*сайт.
Да вам в общем-то ни HTTP не нужен, ни TCP, ни даже кабель с интернетом. Вам нужно показывать котиков. И я вас прекрасно понимаю.
Просто раньше котики прекрасно показывались по небезопасным протоколам, а с нынешними реалиями это не желательно. И проще написать тикет хостеру, чем доказывать всем подряд, что вам не нужен сертификат. Потому что всем всё равно не докажете, а хостер один, и он, если адекватным, внемлет вашей просьбе.daggert
19.02.2018 15:47Подождите, а кто сказал что это нежелательно? Какая-то корпорация? Вам не кажется что это абсурд? 10 лет показывается без ssl и все ок, теперь надо обязательно ssl потому что… захотела корпорация.
Я не буду писать провайдеру или доказывать вам и другим. Я лишь высказываю свою мысль, недовольство, собственно как и все остальные комментаторы на хабре.
Scondo
19.02.2018 15:50Мне кажется вы не совсем корректно формулируете претензии: человек же по сути обсуждает не своего провайдера, а будущее интернета в котором каждый котик должен передаваться в зашифрованном виде.
Вопрос не в том, как ему быть с провайдером, а насколько (и почему) котики требуют шифрования.
Что случится если этот комментарий не будет зашифрован?
Что случится если график в посте не будет зашифрован?
Что случится если лого Яндекса не будет зашифровано?andreymal
19.02.2018 15:56Что случится если этот комментарий не будет зашифрован?
Туда будет встроена реклама от провайдера.
Что случится если график в посте не будет зашифрован?
Туда будет встроена реклама от провайдера.
Что случится если лого Яндекса не будет зашифровано?
Туда будет встроена реклама от провайдера.
Это если из относительно безобидного и не вспоминать про майнеры биткоинов и про RCE в png-файлах :)
Scondo
19.02.2018 16:27-1Вообще-то это означает, что мы используем шифрование не по назначению. Шифрование должно использоваться, чтобы защитить данные от перехвата. Для того, чтобы защитить данные от подмены надо использовать механизмы подписей и хэшей, отличающиеся тем, что данные могут быть доступны и вне шифровки.
andreymal
19.02.2018 16:31Выше уже была начатая мной ветка про подписи. Ну а вообще — во-первых, зачем делать одновременно подписи и шифрование, когда можно сделать сразу шифрование всем? Во-вторых, для подписи тоже нужны те же сертификаты для проверки подлинности, и снова привет, Let's Encrypt
Scondo
19.02.2018 17:01+1Для проверки целостности не обязательно требуются подписи, можно обойтись хэшами, если они пришли из подписанного/зашифрованного документа.
В данном случае первая претензия моя в первую очередь эстетическая: инструмент (шифрование) используется ненадлежащим образом. При этом происходит определённое навязывание шифрования как вещи столь фундаментальной, как будто ничего вообще без него работать не может (включая запрос аптайма с роутера).
С практической точки зрения… ну я не имел бы ничего против, если бы мой провайдер кешировал у себя популярные ролики с ютуба, чтобы сэкономить на трафике и дать мне более высокую скорость. При этом ему бы не потребовалось получать у Гугла защищённое оборудование, могущее шифровать каждый ролик от имени Гугла. Подпись при этом может браться у Гугла, а вот данные уже локально.andreymal
19.02.2018 17:08В принципе я бы тоже был не против описанного вами, если предоставить выбор. Например, я не хочу, чтобы мой провайдер знал, что я смотрю, кхм, «овальные» ролики на ютубе, или что я любуюсь на котиков, которые выкладывает daggert на своём сайте — я хочу, чтобы это всё шифровалось (про всякие косвенные каналы, позволяющие даже при шифровании узнать, что я смотрю, пока молчу). Если отказываться от шифрования и ограничиваться подписью, то я буду лишён права выбора, и мне придётся подключать какой-нибудь VPN (но тогда уже владелец VPN будет знать, что я смотрю овального и котиков, мда).
Scondo
19.02.2018 17:34+1Вот в этом ключевой момент: во-первых, шифрование факта просмотра. Мне не кажется, что мир в котором настолько всё шифруется — это нормально. ВЫ хотите — вы используете VPN/TOR/что вам угодно. А сейчас мы говорим, что все разработчики должны исходить из того, что дать возможность оператору узнать о факте доступа к публично доступной информации — это плохо.
То есть глубина паранойи определяется не потребителем, не источником, а интернетом как таковым. При этом тенденция в том, что даже источник не должен определять необходимо ли что либо шифровать или нет. Ну… мне не нравится, когда кто бы то ни было диктует что бы то ни было. Даже если это благожелательное сообщество беспокоится о моей безопасности.
geher
19.02.2018 21:24Есть такая полезная штука — кэш между поставщиком контента и компьютером получателя. Внезапно, эта простая мера позволяет неплохо оптимизировать трафик.
Конечно, есть методы кэширования и для зашифрованного трафика, но это дополнительные сложности.
Можно поставщику контента, если он богатый, ставить локальные сервера в сети провайдера (как у гугла).
Можно применять методы, вынуждающие браузер ругаться на сертификат.
Но проще кэшировать незашифрованный контент.
Так что подписывание (теми же сертификатами, что и в HTTPS, на другом подобном механизме) вполне может пригодиться.
И это совсем не означает отказа от шифрования там, где оно действительно нужно.
foal
20.02.2018 20:35Хорошо бы еще брать в расчет энергитическую стоимость — как я знаю подпись значительно дороже, чем симетричное шифрование. Я говорю о полностью динамическом варианте. Если у вас данные не меняются, то можно подписать один раз, теоретически. Практически это не реально, потому что надо подписывать чанки — никто не передает данные одним куском. Ну вобщем практически проше шифровать :)
Scondo
20.02.2018 23:35>Практически это не реально, потому что надо подписывать чанки — никто не передает данные одним куском.
Поясните пожалуйста…
Ну, понятно, что подписывать надо, например, каждое загружаемое через AJAX сообщение. Но эти сообщения всё ещё могут совпадать в части публичных данных.
Но в большей части я имел ввиду такие штуки как картинки или встраиваемые видео. В общем то, что описывается не как «сообщение» а как «данные».foal
21.02.2018 00:04Грубо говоря сейчас шифрование идёт на уровне транспорта — на этом уровне есть наборы байтов — каждый набор придётся подписывать заново потому что нет никакой гарантии, что при передаче одного и того же файла он будет разбит на тот же набор пакетов. Если подняться выше на уровень HTTP протокола, то он уже оперирует ресурсами, но все равно может их бить на произвольные куски (partial content) при передаче — из-за этого на этом уровне мы всё равно должны пере-подписывать каждый запрос/ответ. И только перейдя на уровень приложения мы можем не пере-подписывать статические ресурсы. Но только браузер этот уровень не контролирует — то есть доверие только на уровне приложения, что серьёзно ниже доверия браузеру (в среднем).
Кстати видео — очень яркий пример абсурдности подписи на уровне приложения — вы должны скачать его целиком, чтобы проверить подпись :) Ну или подписывать динамически каждый переданный набор байт, что дороже, чем симметричное шифрование того же набора байтов.Scondo
21.02.2018 00:38>может их бить на произвольные куски (partial content) при передаче
Ну вот в целом вопрос сводится к а)может не значит будет; б)произвольности кусков.
То есть например если посмотреть на этот пост, то ни текст поста, ни картинки разбивать на части смысла нет.
Собственно и видео можно подписать некоторые куски размерами от GOP/Scene до эпизода.
Но в целом меня напрягает не то, что в большинстве случаев шифрование оказывается востребованным, а то, что, как следует из поста, «большинство» начинают экстраполировать на «всегда».
То, что данные могут биться на произвольные куски(или даже если данные часто бьются на произвольные куски) не означает, что никто не передаёт данные одним куском.foal
21.02.2018 09:30Что-то мы с вами не туда углубились, коллега :) Речь в моём комментарии шла не о том – надо или нет подписывать/шифровать данные, а о сравнении эффективности этих процессов. При том, что я согласен, что подпись достаточна в большинстве случаев, на практике эффективней применить шифрование, как менее трудоемкий процесс.
Scondo
21.02.2018 10:29>шифрование, как менее трудоемкий процесс.
Разница в трудоёмкости зависит от сценариев использования: если вы постоянно отдаёте данные, которые не предполагается интерпретировать фрагментарно, при этом одни и те же (хостинг картинок), то подпись будет и энергетически/вычислительно эффективнее шифрования, поскольку вместо тысячи согласований сессии будет одно подписание.foal
21.02.2018 17:34Давайте так. У нас есть единичный набор байт, и мы его передаём один раз – его подпись будет дороже, чем его симметричное шифрование. Это всё что я утверждаю.
>сценариев использования
Вообще не спорю – флаг в руки, барабан на шею и вперёд с песней. Но я пасс.
Andrusha
19.02.2018 17:06А что не так с Firefox?
sumanai
19.02.2018 18:03Отвалились все человеческие дополнения, остались одни вебэксты, то есть по сути браузер превратился в хром, только без хрома внутри.
Andrusha
19.02.2018 18:28Не буду спорить, из того, чем пользовался я, насовсем отвалился только DownThemAll, но по мне сам браузер стал работать значительно лучше.
Они, вроде, обещали вернуть часть функционала в дальнейшем?
fukkit
19.02.2018 21:00Слишком много всякой дряни включено по умолчанию. Но возможность для её отключения все же есть.
sumanai
19.02.2018 14:24Но в случае использования стандартного сертификата TLS от доверенного Центра Сертификации, например GlobalSign «предоставить ключи» фактически невозможно, потому что для шифрования соединения каждый раз генерируется новый сеансовый ключ на базе сертификата сервера, открытого ключа клиента и сгенерированных случайных чисел.
Perfect forward secrecy, что тут описывается, не зависит от самого сертификата, это комбинация настроек веб-сервера и новых браузеров, поддерживающих эти протоколы.
Revertis
19.02.2018 17:22Ура! Кто-то таки задумался о том, о чем я писал в 2015-ом году!
habrahabr.ru/post/272253/#comment_8679103
Lopar
19.02.2018 18:38+1Чем дальше в лес… Если полностью абстрагироваться — это шантаж и рэкет 90х: «либо ты оплатишь крышу, либо будет ой-ой».
Есть целые направления, где сертификаты не нужны чуть более чем полностью (локальные ресурсы, локальные сети, например). Есть более обширные направления, где должно хватать самоподписанных сертификатов (закрытые сети организаций, например). Но нет — или «плати за то, что мы поддерживаем» или полируй эбонитовую палочку шерстяной тряпочкой вприсядку подстраивая под себя каждый второй браузер и рассказывай каждому первому пользователю, что это не страшно и так и задумано.
То есть замысел как-бы хороший и правильный, но исполнение слишком уж суровое.
youROCK
Обязательно всем, потому что иначе злоумышленники и всякие нечистые на руку провайдеры могут можифицировать ответы от нормальных сервисов и вставлять туда нежелательный контент, в том числе всякую вирусню. То есть если даже условному ВК нафиг не сдалось шифровать отдачу видео и картинок, делать это все равно нужно, иначе в какой-то момент можно огрести.
andreymal
Немного позанудствую: шифровать для этого необязательно, достаточно просто подписывать (у того же ВК все запросы к API таки подписывались, пока на HTTPS не перешли; криво-косо, правда, но не суть, суть в самой идее)
Но всё же картинки условного ВК шифровать надо как минимум затем, чтобы провайдер мои личные фотки не разглядывал (условному ВК я, допустим, доверяю, а провайдеру не очень)
youROCK
Да подпись решает часть проблем, но речь про подделку ответа, а не запроса. Браузер же не заставить проверять чексумму ответа, который передан в URL, или я чего-то не знаю?
andreymal
Ну, теоретически допилить браузер, чтобы проверял, думаю, ничего не мешает. На практике все ударились в HTTPS и это никому не нужно)
Хотя вообще есть проверка чексумм для сторонних ресурсов типа CDN, но она другую задачу решает
KYuri
Без шифрования трафика это не работает. Информация о том, какой должен быть хэш, передается либо в http-заголовках, либо в мета-тэге html-я.
Что мешает злоумышленнику поменять не только скрипт, но и указать в http-заголовках и мета-тэгах «правильный» хэш?
andreymal
Ничего не мешает. Я ж сказал, этот механизм другую задачу решает, вы зануда ещё больше чем я.
KYuri
Не другую. Этот механизм решает ту же самую задачу — доверия.
Он позволяет разработчику сайта/сервиса сообщить браузеру клиента «вот этому скрипту можно доверять, а вот этому — нет».
andreymal
Доверия к стороннему ресурсу (HTTPS не спасёт от банальной подмены файла админом на сервере CDN), а не к каналу передачи данных (это тоже, но лишь как побочный эффект), так что задача всё-таки немножко другая
Scondo
Это работает, если у вас html идёт по https, а подгружаемый ресурс — по http со сверкой хэша с зашифрованным html.
Типа habrahabr — https; habrastorage — http.
KYuri
Я:
Вы:
Вопрос: а когда https у нас стал нешифрованным?)
Scondo
Суть в том, что вместо того, чтобы шифровать всё мы шифруем только html, содержащий ссылки и хэши. А картинки и видео не шифруем. Таким образом сайт/поддомен отвечающий за раздачу медиаданных может работать без шифрования.
Современный подход требует шифровать вообще всё (сайт, загружающий нешифрованные картинки помечается как «не совсем безопасный»)
KYuri
Суть в том, что content security policy работает только в случае, когда csp-правила передаются по защищенному каналу.
Если это не так — ни о какой security речи быть не может.
Scondo
Ну… правила передаются по защищённому каналу, а содержимое — по незащищённому.
А сейчас веб не имеет механизмов правил для медиа и требует всё передавать по защищённому(интересно распространяется ли паника «не-https» на стили, полученные по http, но с integrity). Я пытаюсь оппонировать именно позиции «передавать всё-всё-всё по защищённому, всё что не передаётся по защищённому — потенциально скомпрометировано», которую как раз и продвигает Хром.
KYuri
Это вопрос уже не к самой CSP, а к конкретной её реализации браузерами.
Лично я, например, навскидку не вижу проблем в описанном случае (контент, полученный по небезопасному каналу, который считается «разрешенным» автором сайта/сервиса).
Если же какой-то браузер считает по-другому, то никто не мешает завести соответствующий тикет и как минимум в процессе обсуждения понять, какую угрозу безопасности это может создать.
Scondo
Ммм… не нашёл нормальных примеров хэш-валидации медиа и картинок для CSP. SRI также описывает integrity только для скриптов и стилей.
А так-то да. Если бы вопрос стоял остро — так бы и поступал.
Scondo
Да не то, чтобы другую. Если расширить механизм SRI на img/audio/video то можно было бы использовать механизмы в духе CDN или просто прозрачных проксей для публично доступных медиаданных.
KYuri
Вы неправы. Подписывать и проверять запросы/ответы API — недостаточно.
И пусть по пути произошла трансформация вПусть сервер вам отправил в корневой html
Может, вы и останетесь защищены от подделки запросов/ответов (в случае, если при каждом обращении к API в ответе кроме собственно ответа будет приходить одноразовый токен для следующего обращения к API), но от прослушки и утечки данных налево — уже нет.
А без шифрования соединения защититься от такой подмены вы не сможете. Content security policy определяется в http-заголовках и мета-тэгах, а значит, также может (и будет) подменена злоумышленником.
andreymal
Этот код, естественно, тоже должен быть подписан. И заголовки content security policy тоже должны быть подписаны. А если это всё подписано, то и трансформация в evil_app.js будет невозможна. Я прав :)
Про прослушку я и сам выше упоминал. Выкидывать шифрование и юзать только подписи я не призываю.)
KYuri
Как браузер проверит, что подпись — правильная и принадлежит example.com, а не вставлена злоумышленником?
andreymal
Да хоть с помощью тех же HTTPS-сертификатов. Насколько я знаю, технически ничего не мешает юзать их как для шифрования, так и для подписи.
KYuri
О! Теперь мы добрались до интересного.
Расскажете, в чем смысл использовать механизмы сертификатов для наложения подписей, но не для шифрования всего трафика (hint: ассиметричное шифрование используется при установке соединения, сам трафик шифруется уже симметричным ключом)?
andreymal
Я нигде не говорил и не собираюсь говорить, что в этом есть какой-то смысл. Я лишь немного позанудствовал, сказав, что для защиты от подмены данных достаточно подписи. Всё остальное вы додумали за меня.
Ещё раз, по пунктам персонально для вас:
KYuri
Этот же самый комментарии был начат с утверждения, что шифрование необязательно для защиты от подмены контента.
Я тоже зануда, и согласен с автором первого комментария — для защиты от подмены контента «по дороге» нужна TLS.
Вы же утверждаете, что без шифрования соединения можно обойтись, но при этом на ходу начинаете придумывать механизмы, удивительно похожие на имеющиеся)
andreymal
Подписи, внезапно, базируются на тех же механизмах, что и шифрование, ага :)
KYuri
Нужен механизм проверки аутентичности данной подписи.
Да, механизмы подписей и ассиметричного шифрования вообще, базируются на тех же механизмах.
А вот шифрование канала передачи включает в себя такие механизмы, как tls-handshake и certificate authority, решающие проблему проверки аутентичности сторон.
Именно эти существующие в tls механизмы Вы начали добавлять по ходу обсуждения в первоначально «достаточную» подпись.
andreymal
Это неотъемлемая часть подписи, я не знаю, с чего это вы вдруг решили, что я считал, что без них «достаточно», ничего подобного. Вы уже не зануда, вы просто выдумываете то, чего не было. Мне надоело опровергать несуществующие события, наверно я вам прекращу отвечать уже
geher
При желании можно подделать и зашифрованный трафик.
Конечно, это будет достаточно сложно, но не невозможно. Естественно, для этого надо быть посредником в передаче трафика (например, провайдером или владельцем локальной сети с выходом в интернет) и иметь достаточно ресурсов, чтобы поднять свой DNS, свой удостоверяющий центр, имитирующий работу настоящего, настроить маршрутизацию и т.п…
Можно даже сделать так, что конечный пользователь ничего не заметит, кроме дополнительных тормозов.
А многим сайтам хватило бы проверяемой подписи. Тогда и достоверность подтверждается, и закэшировать можно без лишних проблем.
andreymal
А с чего бы это браузеру пользователя доверять «своему удостоверяющему центру»? Здесь возможно только свой сертификат пользователям втюхивать, как это, например, делают в Казахстане, иначе невозможно
geher
Хотя бы потому, что он отвечает, с точки зрения браузера как настоящий.
Там, конечно, есть ряд сложностей, но при желании и наличии ресурсов они вполне преодолимы. Например, при помощи уязвимости в ОС можно подменить пользователю браузер. В этом случае свой удостоверяющий центр нужен только для того, чтобы был трафик к удостоверяющему центру.
andreymal
А, ну если так разве что… Но для этого сперва нужно найти подходящие уязвимости во всех популярных ОС всех популярных версий и каким-то образом защититься от переустановок
geher
Если мы смогли подменить браузер у клиента, то мы сможем также поймать переустановку и подменить браузер на лету.
Но это еще мелочи.
Кто сказал, что в принципе невозможно утащить с корневого удлстоверяющего центра все, потребное для имитации его работы с нужными нам поправками?
andreymal
В принципе нет ничего невозможного, но что-то я подозреваю, что всё упомянутое капец какое сложное и дорогое, уязвимости у удостоверяющего центра найти будет ещё труднее чем в ОС у пользователей
barkalov
А корневой сертификат (поддельного CA) пользователю как добавить?