Chrome 68 будет помечать все сайты HTTP как «небезопасные»



    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 68 в июле 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?



    АКЦИЯ GLOBALSIGN: Wildcard SSL + 1 ГОД В ПОДАРОК
    Защитите все субдомены одним сертификатом!

    Экономьте до 30 тысяч рублей при покупке сертификата Wildcard SSL на 2 года!
    Промо-код: WC001HRFR

    Акция действует для подписчиков блога GlobalSign до 15 июня 2018 г.

    Дополнительную информацию вы можете получить у менеджеров GlobalSign по телефону: +7 (499) 678 2210 либо заполнив форму на сайте с указанием промо-кода.

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Вы согласны, что все сайты должны шифровать трафик по HTTPS?
    GlobalSign 212,13
    Компания
    Поделиться публикацией
    Комментарии 78
    • 0
      Обязательно всем, потому что иначе злоумышленники и всякие нечистые на руку провайдеры могут можифицировать ответы от нормальных сервисов и вставлять туда нежелательный контент, в том числе всякую вирусню. То есть если даже условному ВК нафиг не сдалось шифровать отдачу видео и картинок, делать это все равно нужно, иначе в какой-то момент можно огрести.
      • +3

        Немного позанудствую: шифровать для этого необязательно, достаточно просто подписывать (у того же ВК все запросы к API таки подписывались, пока на HTTPS не перешли; криво-косо, правда, но не суть, суть в самой идее)


        Но всё же картинки условного ВК шифровать надо как минимум затем, чтобы провайдер мои личные фотки не разглядывал (условному ВК я, допустим, доверяю, а провайдеру не очень)

        • –1
          Да подпись решает часть проблем, но речь про подделку ответа, а не запроса. Браузер же не заставить проверять чексумму ответа, который передан в URL, или я чего-то не знаю?
          • +2

            Ну, теоретически допилить браузер, чтобы проверял, думаю, ничего не мешает. На практике все ударились в HTTPS и это никому не нужно)


            Хотя вообще есть проверка чексумм для сторонних ресурсов типа CDN, но она другую задачу решает

            • 0
              Хотя вообще есть проверка чексумм для сторонних ресурсов типа CDN

              Без шифрования трафика это не работает. Информация о том, какой должен быть хэш, передается либо в http-заголовках, либо в мета-тэге html-я.
              Что мешает злоумышленнику поменять не только скрипт, но и указать в http-заголовках и мета-тэгах «правильный» хэш?
              • +1

                Ничего не мешает. Я ж сказал, этот механизм другую задачу решает, вы зануда ещё больше чем я.

                • –1
                  Не другую. Этот механизм решает ту же самую задачу — доверия.
                  Он позволяет разработчику сайта/сервиса сообщить браузеру клиента «вот этому скрипту можно доверять, а вот этому — нет».
                  • +1
                    Доверия к стороннему ресурсу (HTTPS не спасёт от банальной подмены файла админом на сервере CDN), а не к каналу передачи данных (это тоже, но лишь как побочный эффект), так что задача всё-таки немножко другая
                • +1
                  Это работает, если у вас html идёт по https, а подгружаемый ресурс — по http со сверкой хэша с зашифрованным html.

                  Типа habrahabr — https; habrastorage — http.
                  • 0
                    Я:
                    Без шифрования трафика это не работает.

                    Вы:
                    Это работает, если у вас html идёт по https

                    Вопрос: а когда https у нас стал нешифрованным?)
                    • +2
                      Суть в том, что вместо того, чтобы шифровать всё мы шифруем только html, содержащий ссылки и хэши. А картинки и видео не шифруем. Таким образом сайт/поддомен отвечающий за раздачу медиаданных может работать без шифрования.

                      Современный подход требует шифровать вообще всё (сайт, загружающий нешифрованные картинки помечается как «не совсем безопасный»)
                      • 0
                        Суть в том, что content security policy работает только в случае, когда csp-правила передаются по защищенному каналу.
                        Если это не так — ни о какой security речи быть не может.
                        • +1
                          Ну… правила передаются по защищённому каналу, а содержимое — по незащищённому.
                          А сейчас веб не имеет механизмов правил для медиа и требует всё передавать по защищённому(интересно распространяется ли паника «не-https» на стили, полученные по http, но с integrity). Я пытаюсь оппонировать именно позиции «передавать всё-всё-всё по защищённому, всё что не передаётся по защищённому — потенциально скомпрометировано», которую как раз и продвигает Хром.
                          • 0
                            сейчас веб не имеет механизмов правил для медиа и требует всё передавать по защищённому
                            Насколько я понимаю, непосредственно веб вполне позволяет задавать правила применительно к различным типам контента.

                            интересно распространяется ли паника «не-https» на стили, полученные по http, но с integrity
                            Это вопрос уже не к самой CSP, а к конкретной её реализации браузерами.
                            Лично я, например, навскидку не вижу проблем в описанном случае (контент, полученный по небезопасному каналу, который считается «разрешенным» автором сайта/сервиса).
                            Если же какой-то браузер считает по-другому, то никто не мешает завести соответствующий тикет и как минимум в процессе обсуждения понять, какую угрозу безопасности это может создать.
                            • 0
                              Ммм… не нашёл нормальных примеров хэш-валидации медиа и картинок для CSP. SRI также описывает integrity только для скриптов и стилей.

                              А так-то да. Если бы вопрос стоял остро — так бы и поступал.
                • 0
                  Да не то, чтобы другую. Если расширить механизм SRI на img/audio/video то можно было бы использовать механизмы в духе CDN или просто прозрачных проксей для публично доступных медиаданных.
              • 0
                Вы неправы. Подписывать и проверять запросы/ответы API — недостаточно.

                Пусть сервер вам отправил в корневой html
                <script src="http://example.com/app.js"></script>
                И пусть по пути произошла трансформация в
                <script src="http://evil.com/evil_app.js"></script>


                Может, вы и останетесь защищены от подделки запросов/ответов (в случае, если при каждом обращении к API в ответе кроме собственно ответа будет приходить одноразовый токен для следующего обращения к API), но от прослушки и утечки данных налево — уже нет.

                А без шифрования соединения защититься от такой подмены вы не сможете. Content security policy определяется в http-заголовках и мета-тэгах, а значит, также может (и будет) подменена злоумышленником.
                • 0
                  Пусть сервер вам отправил в корневой html

                  Этот код, естественно, тоже должен быть подписан. И заголовки content security policy тоже должны быть подписаны. А если это всё подписано, то и трансформация в evil_app.js будет невозможна. Я прав :)


                  Про прослушку я и сам выше упоминал. Выкидывать шифрование и юзать только подписи я не призываю.)

                  • 0
                    Этот код, естественно, тоже должен быть подписан. И заголовки content security policy тоже должны быть подписаны. А если это всё подписано, то и трансформация в evil_app.js будет невозможна. Я прав :)

                    Как браузер проверит, что подпись — правильная и принадлежит example.com, а не вставлена злоумышленником?
                    • 0

                      Да хоть с помощью тех же HTTPS-сертификатов. Насколько я знаю, технически ничего не мешает юзать их как для шифрования, так и для подписи.

                      • 0
                        О! Теперь мы добрались до интересного.
                        Расскажете, в чем смысл использовать механизмы сертификатов для наложения подписей, но не для шифрования всего трафика (hint: ассиметричное шифрование используется при установке соединения, сам трафик шифруется уже симметричным ключом)?
                        • 0

                          Я нигде не говорил и не собираюсь говорить, что в этом есть какой-то смысл. Я лишь немного позанудствовал, сказав, что для защиты от подмены данных достаточно подписи. Всё остальное вы додумали за меня.


                          Ещё раз, по пунктам персонально для вас:


                          • я НЕ утверждаю, что подпись лучше шифрования;
                          • я НЕ утверждаю, что браузеры должны реализовать создание и проверку подписей в протоколе HTTP;
                          • я НЕ утверждаю, что нужно бросать шифрование и переходить на подписи;
                          • я в первом же своём комментарии сказал, что всё равно всё нужно шифровать для скрытия данных. Чего вы до меня докопались — я не понимаю.
                          • 0
                            я в первом же своём комментарии сказал, что всё равно всё нужно шифровать для скрытия данных. Чего вы до меня докопались — я не понимаю.

                            Этот же самый комментарии был начат с утверждения, что шифрование необязательно для защиты от подмены контента.

                            Я тоже зануда, и согласен с автором первого комментария — для защиты от подмены контента «по дороге» нужна TLS.

                            Вы же утверждаете, что без шифрования соединения можно обойтись, но при этом на ходу начинаете придумывать механизмы, удивительно похожие на имеющиеся)
                            • 0
                              механизмы, удивительно похожие на имеющиеся)

                              Подписи, внезапно, базируются на тех же механизмах, что и шифрование, ага :)

                              • 0
                                Я лишь немного позанудствовал, сказав, что для защиты от подмены данных достаточно подписи.
                                Нет, недостаточно.
                                Нужен механизм проверки аутентичности данной подписи.

                                Подписи, внезапно, базируются на тех же механизмах, что и шифрование
                                Да, механизмы подписей и ассиметричного шифрования вообще, базируются на тех же механизмах.

                                А вот шифрование канала передачи включает в себя такие механизмы, как tls-handshake и certificate authority, решающие проблему проверки аутентичности сторон.

                                Именно эти существующие в tls механизмы Вы начали добавлять по ходу обсуждения в первоначально «достаточную» подпись.
                                • 0
                                  Именно эти существующие в tls механизмы Вы начали добавлять по ходу обсуждения в первоначально «достаточную» подпись.

                                  Это неотъемлемая часть подписи, я не знаю, с чего это вы вдруг решили, что я считал, что без них «достаточно», ничего подобного. Вы уже не зануда, вы просто выдумываете то, чего не было. Мне надоело опровергать несуществующие события, наверно я вам прекращу отвечать уже

              • –1

                При желании можно подделать и зашифрованный трафик.
                Конечно, это будет достаточно сложно, но не невозможно. Естественно, для этого надо быть посредником в передаче трафика (например, провайдером или владельцем локальной сети с выходом в интернет) и иметь достаточно ресурсов, чтобы поднять свой DNS, свой удостоверяющий центр, имитирующий работу настоящего, настроить маршрутизацию и т.п…
                Можно даже сделать так, что конечный пользователь ничего не заметит, кроме дополнительных тормозов.


                А многим сайтам хватило бы проверяемой подписи. Тогда и достоверность подтверждается, и закэшировать можно без лишних проблем.

                • +1

                  А с чего бы это браузеру пользователя доверять «своему удостоверяющему центру»? Здесь возможно только свой сертификат пользователям втюхивать, как это, например, делают в Казахстане, иначе невозможно

                  • –1

                    Хотя бы потому, что он отвечает, с точки зрения браузера как настоящий.
                    Там, конечно, есть ряд сложностей, но при желании и наличии ресурсов они вполне преодолимы. Например, при помощи уязвимости в ОС можно подменить пользователю браузер. В этом случае свой удостоверяющий центр нужен только для того, чтобы был трафик к удостоверяющему центру.

                    • +1
                      при помощи уязвимости в ОС

                      А, ну если так разве что… Но для этого сперва нужно найти подходящие уязвимости во всех популярных ОС всех популярных версий и каким-то образом защититься от переустановок

                      • 0

                        Если мы смогли подменить браузер у клиента, то мы сможем также поймать переустановку и подменить браузер на лету.
                        Но это еще мелочи.
                        Кто сказал, что в принципе невозможно утащить с корневого удлстоверяющего центра все, потребное для имитации его работы с нужными нам поправками?

                        • 0
                          В принципе нет ничего невозможного, но что-то я подозреваю, что всё упомянутое капец какое сложное и дорогое, уязвимости у удостоверяющего центра найти будет ещё труднее чем в ОС у пользователей
                  • +3
                    При желании можно подделать и зашифрованный трафик.
                    Смелое заявление!
                    свой удостоверяющий центр
                    А корневой сертификат (поддельного CA) пользователю как добавить?
                • 0
                  Ну и нахрена мне пихать HTTPS в мой роутерный 192.168.1.1, доступ к которому есть только по непосредственно подключенному к нему кабелю?
                  • 0
                    Не обязательно, но вы просто будете видеть плашку «Небезопасно». Вроде не так плохо, нет?
                    • 0

                      Не совсем: мой фаерфокс уже давно забыл пароль от роутера, потому что HTTPS отсутствует, приходится каждый раз руками набирать. Хром пока вроде бы запоминает, но нет уверенности, что так останется и в будущем или что в будущем не добавится каких-нибудь новых ограничений

                  • –2
                    Сегодня гугл решает что с людей надо больше денег брать за ssl, завтра он начнет контролировать какие центры сертификации ему выгодны. Монополия, мать ее… А ведь еще недавно все так радовались концу моноплии IE…
                    • –1
                      Гугл ничего не запрещает и не навязывает.
                      Он просто начинает помечать небезопасные сайты (сайты, содержимое которых может быть перехвачено и/или подменено третьими лицами) как небезопасные.
                      • +3
                        Сегодня просто помечает, завтра не открывает без добавления в исключения, послезавтра не открывает вообще, послепослезавтра Let's Encrypt закрывается и оставшиеся сертификаты резко дорожают… [/параноик_mode]
                        • +4
                          Это запрет и навязывание. Прямое использование своей монополии для навязывания технологии. Завтра он решит вообще не заходить на сайты без https и все, половина шаредов глубоко в ..., тогда как многим он вообще не нужен.
                          • +1
                            половина шаредов глубоко в ...,

                            Они уже там, туда им и дорога, как и хостингам, которые за установку сертификата требуют отдельной платы. Я понимаю, что так делали 10 лет назад, когда SNI не так хорошо поддерживался, но в 2018 это свинство, которое должно быть наказано.
                            • +1
                              А что вам не нравится в шареде? Или вы предпочтете криво настроенный VPS, который может стать частью ботнета, после его настройки по первой инструкции с интернета? Разница для простого смертного большая — найти и поставить бложик на шареде, и найти и поставить бложик на VPS'е. Это уровень вообще разный.
                              • 0
                                Мне всё нравится, в нормальных хостерах, которые имеют актуальный софт, возможность настройки всего и вся, выбор версии из всех актуальных и парочки устаревших, нормальную панель, возможность настроить nginx + php-fpm и прочее. С такими я с удовольствием работаю. А вот говношареды с выбором между PHP 5.2 и PHP 5.3, без сертификатов и прочего, должны умереть в конкурентной борьбе, и требование сертификатов лишь приблизит их смерть.
                        • +1
                          Сегодня гугл решает что с людей надо больше денег брать за ssl

                          При помощи поддержки LE, который выдаёт сертификаты всем и бесплатно? Странные решения.
                          А монополия да, всё близится. FF умер в моих глазах, браузеры от МС имеют свои приколы, остальные перешли на движок хрома. Печально.
                          • +2
                            А простите за чей счет пир с LE? Я как-то не доверяю продуктам которым я не плачу деньги, ибо иначе я становлюсь их продуктом. И почему я должен доверять их центру? Совсем недавно symantec был доверенным и надежным. И где гарантии что они не введут платную подписку, когда хром станет весь простой трафик помечать как небезопасный?

                            + косвенные деньги — процессорное время для работы с шифрованием вроде как не бесплатное.

                            Я не против самого SSL, но я против его повсеместного применения. Моим сайтам, нужным десятку человек в день, вполне себе хватает бесплатного шареда от провайдера и введение шифрования для меня будет дополнительной финансовой нагрузкой (смена тарифа как минимум), которые лично я нести не очень хочу, т.к. все проекты на энтуазизме.
                            • 0
                              А простите за чей счет пир с LE?

                              Я же отметил- за счёт гугла как минимум. А на сайте LE указаны остальные 49 спонсоров.
                              + косвенные деньги — процессорное время для работы с шифрованием вроде как не бесплатное.

                              Сейчас большинство процессоров, включая серверные, имеют блоки ускорения AES.
                              Моим сайтам, нужным десятку человек в день, вполне себе хватает бесплатного шареда от провайдера и введение шифрования для меня будет дополнительной финансовой нагрузкой (смена тарифа как минимум),

                              Проблемы вашего шареда, который не может ввести поддержку бесплатных сертификатов. Пишите в поддержку, пускай поправляют.
                              • +2
                                Я же отметил- за счёт гугла как минимум. А на сайте LE указаны остальные 49 спонсоров.

                                Коммерческие компании вводят SSL чтоб их рекламу не резали провайдеры местечковые, а весь мир радуется защите… Заманчиво…


                                Сейчас большинство процессоров, включая серверные, имеют блоки ускорения AES.

                                А они не потребляют энергии? Оо


                                Проблемы вашего шареда, который не может ввести поддержку бесплатных сертификатов. Пишите в поддержку, пускай поправляют.

                                Даже не подумаю. Для моих нужд не нужен https, у меня там и авторизации нет, и пользовательских данных ноль.

                                • –1
                                  А они не потребляют энергии? Оо

                                  В счетах за электричество этого не найти.
                                  Для моих нужд не нужен https, у меня там и авторизации нет, и пользовательских данных ноль.

                                  Вы тут уже написали больше символов, чем нужно для открытия тикета с названием «Прикрутите бесплатные сертификаты от LE».
                                  • +2
                                    В счетах за электричество этого не найти.

                                    Ну да, только вот в масштабе датацетра я думаю это будет заметно.


                                    Вы тут уже написали больше символов, чем нужно для открытия тикета с названием «Прикрутите бесплатные сертификаты от LE».

                                    Еще раз: Мне НЕ НУЖЕН сертификат на мой го*сайт. Мне не нужен не платный, не бесплатный, со скидкой или без, от LE или нортона. Меня устраивает работа по обычному протоколу http, в одностороннем порядке — я показываю людям котиков, они радуются и закрывают картинку.

                                    • –1
                                      Ну да, только вот в масштабе датацетра я думаю это будет заметно.

                                      Может быть.
                                      Еще раз: Мне НЕ НУЖЕН сертификат на мой го*сайт.

                                      Да вам в общем-то ни HTTP не нужен, ни TCP, ни даже кабель с интернетом. Вам нужно показывать котиков. И я вас прекрасно понимаю.
                                      Просто раньше котики прекрасно показывались по небезопасным протоколам, а с нынешними реалиями это не желательно. И проще написать тикет хостеру, чем доказывать всем подряд, что вам не нужен сертификат. Потому что всем всё равно не докажете, а хостер один, и он, если адекватным, внемлет вашей просьбе.
                                      • +2
                                        Подождите, а кто сказал что это нежелательно? Какая-то корпорация? Вам не кажется что это абсурд? 10 лет показывается без ssl и все ок, теперь надо обязательно ssl потому что… захотела корпорация.
                                        Я не буду писать провайдеру или доказывать вам и другим. Я лишь высказываю свою мысль, недовольство, собственно как и все остальные комментаторы на хабре.
                                        • 0
                                          Мне кажется вы не совсем корректно формулируете претензии: человек же по сути обсуждает не своего провайдера, а будущее интернета в котором каждый котик должен передаваться в зашифрованном виде.

                                          Вопрос не в том, как ему быть с провайдером, а насколько (и почему) котики требуют шифрования.
                                          Что случится если этот комментарий не будет зашифрован?
                                          Что случится если график в посте не будет зашифрован?
                                          Что случится если лого Яндекса не будет зашифровано?
                                          • +2
                                            Что случится если этот комментарий не будет зашифрован?

                                            Туда будет встроена реклама от провайдера.


                                            Что случится если график в посте не будет зашифрован?

                                            Туда будет встроена реклама от провайдера.


                                            Что случится если лого Яндекса не будет зашифровано?

                                            Туда будет встроена реклама от провайдера.


                                            Это если из относительно безобидного и не вспоминать про майнеры биткоинов и про RCE в png-файлах :)

                                            • –1
                                              Вообще-то это означает, что мы используем шифрование не по назначению. Шифрование должно использоваться, чтобы защитить данные от перехвата. Для того, чтобы защитить данные от подмены надо использовать механизмы подписей и хэшей, отличающиеся тем, что данные могут быть доступны и вне шифровки.
                                              • 0
                                                Выше уже была начатая мной ветка про подписи. Ну а вообще — во-первых, зачем делать одновременно подписи и шифрование, когда можно сделать сразу шифрование всем? Во-вторых, для подписи тоже нужны те же сертификаты для проверки подлинности, и снова привет, Let's Encrypt
                                                • +1
                                                  Для проверки целостности не обязательно требуются подписи, можно обойтись хэшами, если они пришли из подписанного/зашифрованного документа.

                                                  В данном случае первая претензия моя в первую очередь эстетическая: инструмент (шифрование) используется ненадлежащим образом. При этом происходит определённое навязывание шифрования как вещи столь фундаментальной, как будто ничего вообще без него работать не может (включая запрос аптайма с роутера).

                                                  С практической точки зрения… ну я не имел бы ничего против, если бы мой провайдер кешировал у себя популярные ролики с ютуба, чтобы сэкономить на трафике и дать мне более высокую скорость. При этом ему бы не потребовалось получать у Гугла защищённое оборудование, могущее шифровать каждый ролик от имени Гугла. Подпись при этом может браться у Гугла, а вот данные уже локально.
                                                  • 0

                                                    В принципе я бы тоже был не против описанного вами, если предоставить выбор. Например, я не хочу, чтобы мой провайдер знал, что я смотрю, кхм, «овальные» ролики на ютубе, или что я любуюсь на котиков, которые выкладывает daggert на своём сайте — я хочу, чтобы это всё шифровалось (про всякие косвенные каналы, позволяющие даже при шифровании узнать, что я смотрю, пока молчу). Если отказываться от шифрования и ограничиваться подписью, то я буду лишён права выбора, и мне придётся подключать какой-нибудь VPN (но тогда уже владелец VPN будет знать, что я смотрю овального и котиков, мда).

                                                    • +1
                                                      Вот в этом ключевой момент: во-первых, шифрование факта просмотра. Мне не кажется, что мир в котором настолько всё шифруется — это нормально. ВЫ хотите — вы используете VPN/TOR/что вам угодно. А сейчас мы говорим, что все разработчики должны исходить из того, что дать возможность оператору узнать о факте доступа к публично доступной информации — это плохо.

                                                      То есть глубина паранойи определяется не потребителем, не источником, а интернетом как таковым. При этом тенденция в том, что даже источник не должен определять необходимо ли что либо шифровать или нет. Ну… мне не нравится, когда кто бы то ни было диктует что бы то ни было. Даже если это благожелательное сообщество беспокоится о моей безопасности.
                                                  • 0

                                                    Есть такая полезная штука — кэш между поставщиком контента и компьютером получателя. Внезапно, эта простая мера позволяет неплохо оптимизировать трафик.
                                                    Конечно, есть методы кэширования и для зашифрованного трафика, но это дополнительные сложности.
                                                    Можно поставщику контента, если он богатый, ставить локальные сервера в сети провайдера (как у гугла).
                                                    Можно применять методы, вынуждающие браузер ругаться на сертификат.
                                                    Но проще кэшировать незашифрованный контент.
                                                    Так что подписывание (теми же сертификатами, что и в HTTPS, на другом подобном механизме) вполне может пригодиться.
                                                    И это совсем не означает отказа от шифрования там, где оно действительно нужно.

                                                  • 0
                                                    Хорошо бы еще брать в расчет энергитическую стоимость — как я знаю подпись значительно дороже, чем симетричное шифрование. Я говорю о полностью динамическом варианте. Если у вас данные не меняются, то можно подписать один раз, теоретически. Практически это не реально, потому что надо подписывать чанки — никто не передает данные одним куском. Ну вобщем практически проше шифровать :)
                                                    • 0
                                                      >Практически это не реально, потому что надо подписывать чанки — никто не передает данные одним куском.
                                                      Поясните пожалуйста…
                                                      Ну, понятно, что подписывать надо, например, каждое загружаемое через AJAX сообщение. Но эти сообщения всё ещё могут совпадать в части публичных данных.

                                                      Но в большей части я имел ввиду такие штуки как картинки или встраиваемые видео. В общем то, что описывается не как «сообщение» а как «данные».
                                                      • 0
                                                        Грубо говоря сейчас шифрование идёт на уровне транспорта — на этом уровне есть наборы байтов — каждый набор придётся подписывать заново потому что нет никакой гарантии, что при передаче одного и того же файла он будет разбит на тот же набор пакетов. Если подняться выше на уровень HTTP протокола, то он уже оперирует ресурсами, но все равно может их бить на произвольные куски (partial content) при передаче — из-за этого на этом уровне мы всё равно должны пере-подписывать каждый запрос/ответ. И только перейдя на уровень приложения мы можем не пере-подписывать статические ресурсы. Но только браузер этот уровень не контролирует — то есть доверие только на уровне приложения, что серьёзно ниже доверия браузеру (в среднем).

                                                        Кстати видео — очень яркий пример абсурдности подписи на уровне приложения — вы должны скачать его целиком, чтобы проверить подпись :) Ну или подписывать динамически каждый переданный набор байт, что дороже, чем симметричное шифрование того же набора байтов.
                                                        • 0
                                                          >может их бить на произвольные куски (partial content) при передаче
                                                          Ну вот в целом вопрос сводится к а)может не значит будет; б)произвольности кусков.

                                                          То есть например если посмотреть на этот пост, то ни текст поста, ни картинки разбивать на части смысла нет.

                                                          Собственно и видео можно подписать некоторые куски размерами от GOP/Scene до эпизода.

                                                          Но в целом меня напрягает не то, что в большинстве случаев шифрование оказывается востребованным, а то, что, как следует из поста, «большинство» начинают экстраполировать на «всегда».
                                                          То, что данные могут биться на произвольные куски(или даже если данные часто бьются на произвольные куски) не означает, что никто не передаёт данные одним куском.
                                                          • 0
                                                            Что-то мы с вами не туда углубились, коллега :) Речь в моём комментарии шла не о том – надо или нет подписывать/шифровать данные, а о сравнении эффективности этих процессов. При том, что я согласен, что подпись достаточна в большинстве случаев, на практике эффективней применить шифрование, как менее трудоемкий процесс.
                                                            • 0
                                                              >шифрование, как менее трудоемкий процесс.
                                                              Разница в трудоёмкости зависит от сценариев использования: если вы постоянно отдаёте данные, которые не предполагается интерпретировать фрагментарно, при этом одни и те же (хостинг картинок), то подпись будет и энергетически/вычислительно эффективнее шифрования, поскольку вместо тысячи согласований сессии будет одно подписание.
                                                              • 0
                                                                Давайте так. У нас есть единичный набор байт, и мы его передаём один раз – его подпись будет дороже, чем его симметричное шифрование. Это всё что я утверждаю.
                                                                >сценариев использования
                                                                Вообще не спорю – флаг в руки, барабан на шею и вперёд с песней. Но я пасс.
                                  • 0
                                    А что не так с Firefox?
                                    • 0
                                      Отвалились все человеческие дополнения, остались одни вебэксты, то есть по сути браузер превратился в хром, только без хрома внутри.
                                      • 0
                                        Не буду спорить, из того, чем пользовался я, насовсем отвалился только DownThemAll, но по мне сам браузер стал работать значительно лучше.
                                        Они, вроде, обещали вернуть часть функционала в дальнейшем?
                                        • 0
                                          Вам повезло. А у меня 4/5 в утиль ушло. Прироста в скорости не заметил, только глупых анимаций больше стало.
                                          Обещать они много чего обещали, ждём реализации.
                                          • 0
                                            Обновился. Ужаснулся, грязно выругался, откатился на старую версию.
                                    • 0
                                      Слишком много всякой дряни включено по умолчанию. Но возможность для её отключения все же есть.
                                • 0
                                  Но в случае использования стандартного сертификата TLS от доверенного Центра Сертификации, например GlobalSign «предоставить ключи» фактически невозможно, потому что для шифрования соединения каждый раз генерируется новый сеансовый ключ на базе сертификата сервера, открытого ключа клиента и сгенерированных случайных чисел.

                                  Perfect forward secrecy, что тут описывается, не зависит от самого сертификата, это комбинация настроек веб-сервера и новых браузеров, поддерживающих эти протоколы.
                                  • –1
                                    Ура! Кто-то таки задумался о том, о чем я писал в 2015-ом году!
                                    habrahabr.ru/post/272253/#comment_8679103
                                    • +2
                                      Чем дальше в лес… Если полностью абстрагироваться — это шантаж и рэкет 90х: «либо ты оплатишь крышу, либо будет ой-ой».

                                      Есть целые направления, где сертификаты не нужны чуть более чем полностью (локальные ресурсы, локальные сети, например). Есть более обширные направления, где должно хватать самоподписанных сертификатов (закрытые сети организаций, например). Но нет — или «плати за то, что мы поддерживаем» или полируй эбонитовую палочку шерстяной тряпочкой вприсядку подстраивая под себя каждый второй браузер и рассказывай каждому первому пользователю, что это не страшно и так и задумано.

                                      То есть замысел как-бы хороший и правильный, но исполнение слишком уж суровое.
                                      • 0
                                        Безопаснее всего — отказаться от Хрома.
                                      • 0
                                        Например, в Казахстане для этого сертификаты сайтов подменяются национальным сертификатом безопасности

                                        Это не соответствует действительности. Да, статья по ссылке компрометирующая, однако дальше инициатив дело не пошло и никаких нац. сертификатов не используется, кроме сайтов госуслуг.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое