company_banner

HTTP-заголовки для ответственного разработчика

Автор оригинала: Stefan Judis
  • Перевод

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

Разработчики соединяют людей.
Разработчики помогают людям.
Разработчики дают людям возможности.

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

HTTP — протокол передачи гипертекста


Давайте сначала поговорим о HTTP. HTTP — это протокол, используемый компьютерами для запроса и отправки данных по интернету.

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

Сервер отвечает запрашиваемым ресурсом, но также отправляет заголовки ответа, содержащие информацию о ресурсе или самом сервере.

Request:
GET https://the-responsible.dev/
Accept: text/html,application/xhtml+xml,application/xml
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,de;q=0.7
...

Response:
Connection: keep-alive
Content-Type: text/html; charset=utf-8
Date: Mon, 11 Mar 2019 12:59:38 GMT
...
Response Body

Сегодня HTTP является основой интернета и предлагает множество способов оптимизировать работу пользователей. Давайте посмотрим, как можно использовать заголовки HTTP для создания безопасной и доступной сети.

Сеть должна быть безопасной


Раньше я никогда не чувствовал опасности, когда искал что-то в интернете. Но чем больше я узнавал о всемирной паутине, тем больше я беспокоился. Вы можете почитать, как хакеры меняют глобальные CDN-библиотеки, случайные сайты майнят криптовалюту в браузере своих посетителей, а также о том, как с помощью социальной инженерии люди регулярно получают доступ к успешным проектам с открытым исходным кодом. Это нехорошо. Но почему вас должно это волновать?

Если вы сегодня разрабатываете для веба, то не просто пишете код. Сегодня в веб-разработке над одним сайтом работает много людей. Возможно, вы также используете много открытого исходного кода. Кроме того, для маркетинговых целей вы можете включить несколько сторонних скриптов. Сотни людей предоставляют код, запущенный на вашем сайте. И разработчикам приходится работать в подобных реалиях.

Можно ли доверять всем этим людям и всему исходному коду?

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

Если вы хотите проанализировать, сколько стороннего кода запускается на вашем сайте, можно посмотреть в панели разработчика или попробовать Request Map Generator.

HTTPS и HSTS — убедитесь, что ваше соединение безопасно


Защищённое соединение является основой безопасного интернета. Без зашифрованных запросов, проходящих через HTTPS, нельзя быть уверенным, что между вашим сайтом и посетителями больше никого нет. Человек может быстро настроить общедоступную сеть Wi-Fi и совершить атаку «человек посередине» на любого, кто подключится к этой сети. Как часто вы используете общедоступный Wi-Fi? Кроме того, как часто вы проверяете, заслуживает ли он доверия?

К счастью, сегодня сертификаты TLS бесплатны; HTTPS стал стандартом, и браузеры предоставляют передовые функции только для защищенных соединений, и даже отмечают веб-сайты, не относящиеся к HTTPS, как небезопасные, что способствует внедрению этого протокола. К сожалению, мы не всегда в безопасности, когда находимся в интернете. Когда кто-то хочет открыть сайт, он не вводит протокол в адресную строку (и почему вообще должен?). Это приводит к созданию незашифрованного HTTP-запроса. Безопасно работающие сайты перенаправляют пользователя на HTTPS. Но что если кто-то перехватит первый незащищенный запрос?

Вы можете использовать заголовки ответа HSTS (HTTP Strict Transport Security), чтобы сообщить браузерам, что ваш сайт работает только через HTTPS.

Strict-Transport-Security: max-age=1000; includeSubDomains; preload

Этот заголовок говорит браузеру, что вы не хотите использовать HTTP-запросы, и тогда он автоматически применит те же запросы к такому же источнику с защищенным соединением. Если вы попытаетесь открыть такой же URL через HTTP, браузер снова будет использовать HTTPS и перенаправит пользователя.

Вы можете настроить, как долго этот параметр должен оставаться активным (max-age в секундах), если захотите потом снова использовать HTTP. Если вы хотите включить поддомены, то можете настроить это с помощью includeSubDomains.

Если вы хотите сделать всё возможное, чтобы браузер никогда не запрашивал ваш сайт по HTTP, можете также задать указатель preload и отправить ваш сайт в глобальный список. Если конфигурация HSTS вашего сайта соответствует минимальному max-age в один год и активна для поддоменов, он может быть включен во внутренний список браузер для сайтов, работающих только через HTTPS.

Задумывались ли вы когда-нибудь, почему вы больше не можете использовать в своем браузере через HTTP локальные переменные среды, такие как my-site.dev? Причина именно в этом внутреннем списке — .dev автоматически включаются в этот список, поскольку в феврале 2019 года он стал настоящим доменом верхнего уровня.

Заголовок HSTS не только делает ваш сайт немного безопаснее, но и ускоряет его работу. Представьте себе, что кто-то заходит по медленному мобильному соединению. Если первый запрос сделан через HTTP только для получения перенаправления, то пользователь может несколько секунд ничего не видеть на экране. А с помощью HSTS вы можете сэкономить эти секунды, и браузер автоматически будет использовать HTTPS.

CSP — четко укажите, что разрешено на вашем сайте


Теперь, когда ваш сайт работает через защищенное соединение, вы можете столкнуться с проблемой, когда браузеры начинают блокировать запросы, которые выходят на незащищенный адрес из-за политик смешанного контента. Заголовок Content Security Policy (CSP) предлагает отличный способ обработки таких ситуаций. Вы можете установить свой набор правил CSP с помощью мета-элементов в предоставляемом HTML или через HTTP-заголовки.

Content-Security-Policy: upgrade-insecure-requests

Указатель upgrade-insecure-requests заставляет браузер волшебным образом переделать все HTTP-запросы в HTTPS-запросы.

Однако CSP касается не только используемого протокола. Он предлагает детальные способы определения того, какие ресурсы и действия разрешены на вашем сайте. Вы можете, например, указать, какие скрипты должны выполняться или откуда загружать изображения. Если что-то не разрешено, браузер блокирует это действие и предотвращает потенциальные атаки на ваш сайт.



На момент написания статьи для CSP существовало 24 различных варианта конфигурации. Они варьируются от скриптов через таблицы стилей вплоть до сервис-воркеров.



Вы можете найти полный обзор на MDN.

Используя CSP, вы можете указать, что должен включать ваш сайт, а что нет.

Content-Security-Policy: default-src 'self'; script-src 'self' just-comments.com www.google-analytics.com production-assets.codepen.io storage.googleapis.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: images.contentful.com images.ctfassets.net www.gravatar.com www.google-analytics.com just-comments.com; font-src 'self' data:; connect-src 'self' cdn.contentful.com images.contentful.com videos.contentful.com images.ctfassets.net videos.ctfassets.net service.just-comments.com www.google-analytics.com; media-src 'self' videos.contentful.com videos.ctfassets.net; object-src 'self'; frame-src codepen.io; frame-ancestors 'self'; worker-src 'self'; block-all-mixed-content; manifest-src 'self' 'self'; disown-opener; prefetch-src 'self'

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

Чтобы избежать взлома вашего сайта, CSP также предоставляет режим только для отчетов.

Content-Security-Policy-Report-Only: default-src 'self'; ... report-uri https://stefanjudis.report-uri.com/r/d/csp/reportOnly

Используя режим Content-Security-Policy-Reportt-Only, браузеры просто записывают ресурсы, которые были бы заблокированы, вместо их фактической блокировки. Этот механизм отчетности позволяет проверить и настроить ваш набор правил.

Оба заголовка, Content-Security-Policy и Content-Security-Policy-Report-Only, также предлагают способ определения конечной точки для отправки сообщения о нарушении и регистрации информации (report-uri). Вы можете настроить сервер регистрации и использовать отправленную информацию журнала для настройки правил CSP, пока он не будет готов к отправке.

Рекомендуемый процесс выглядит так: сначала запустите CSP в режиме отчета, проанализируйте входящие нарушения с реальным трафиком, и только тогда, когда не будет обнаружено нарушений ваших контролируемых ресурсов, включите его.

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

Общее внедрение CSP


Сегодня браузеры хорошо поддерживают CSP, но, к сожалению, не многие сайты используют её. Чтобы посмотреть, сколько сайтов отдают контент с помощью CSP, я направил запрос в HTTParchive и обнаружил, что только 6 % просмотренных сайтов используют эту политику. Я думаю, что мы можем сделать интернет более безопасным и защитить наших пользователей от невольного майнинга криптовалют.



Сеть должна быть доступной


Пока я пишу эту статью, я сижу перед относительно новым MacBook, используя быстрое домашнее Wi-Fi-подключение. Разработчики часто забывают, что такая ситуация не является стандартной для большинства наших пользователей. Люди, посещающие наши сайты, пользуются старыми телефонами и сомнительными соединениями. Тяжелые и перегруженные сайты с сотнями запросов оставляют им плохое впечатление.

И дело не только во впечатлении. Люди платят различные суммы за трафик в зависимости от места проживания. Представьте себе, вы создаете сайт для больницы. Информация на нём может иметь решающее значение и спасти жизни людей. Если страница на сайте больницы имеет размер 5 Мб, то она не только будет медленно работать, но и может оказаться слишком дорогой для тех, кто больше всего в ней нуждается. Цена пяти мегабайтов трафика в Европе или США ничтожна по сравнению с ценой в Африке. Разработчики несут ответственность за доступность веб-страниц для всех. Эта ответственность включает в себя предоставление правильных ресурсов, выбор правильных инструментов (действительно ли вам нужен JS-фреймворк для лендинга?) и недопущение запросов.

Cache-Control — избегайте запросов на неизменные ресурсы


Сегодня сайт может содержать сотни ресурсов, от CSS до скриптов и изображений. Используя заголовок Cache-Control, разработчики могут указать, как долго ресурс должен считаться «свежим» и может отдавать из кэша браузера.

Cache-Control: max-age=30, public

При правильной настройке Cache-Control передача данных сохраняется, и файлы могут использоваться из кэша браузера в течение определенного количества секунд (max-age). Браузеры должны повторно проверять кэшированные ресурсы по истечении этого периода времени.

Однако, если посетители обновляют страницу, браузеры всё равно повторно проверяют её, включая ссылки на ресурсы, чтобы убедиться, что кэшированные данные всё ещё действительны. Серверы отвечают заголовком 304, сигнализируя, что кэшированные данные пока действительны, или заголовком 200 при передаче обновленных данных. Это позволяет сохранить переданные данные, но не обязательно сделанные запросы.

Именно здесь вступает в игру функция immutable.

Immutable — никогда не запрашивать ресурс дважды


В современных frontend-приложениях файлы CSS и скриптов обычно имеют уникальные имена, например, styles.123abc.css. Имя этого файла зависит от содержимого. И при изменении содержимого файлов меняются и их имена.

Эти уникальные файлы потенциально могут храниться в кэше вечно, включая ситуацию, когда пользователь обновляет страницу. Функция immutable может запретить браузеру повторную проверку ресурса в определенный промежуток времени. Это очень важно для объектов с контрольными суммами, и помогает избежать повторных проверочных запросов.

Cache-Control: max-age=31536000, public, immutable

Реализовать оптимальное кэширование очень сложно, а особенно браузерное кэширование не слишком интуитивно понятно, поскольку имеет различные конфигурации. Я рекомендую ознакомиться со следующими материалами:


Accept-Encoding — максимальное сжатие (до минимума)


С помощью Cache control мы можем сохранять запросы и уменьшать объем данных, которые многократно передаются по сети. Мы можем не только экономить запросы, но и сокращать то, что передается.

Отдавая ресурсы, разработчики должны позаботиться о том, чтобы отправлять как можно меньше данных. Для текстовых ресурсов, таких как HTML, CSS и JavaScript, сжатие играет важную роль в экономии передаваемых данных.

Самым популярным методом сжатия сегодня является GZIP. Серверам хватает мощности для сжатия текстовых файлов на лету и предоставления сжатых данных при запросе. Но GZIP уже не самый лучший вариант.

Если вы взглянете на создаваемые браузером запросы текстовых файлов, таких как HTML, CSS и JavaScript, и проанализируете заголовки, то найдете среди них accept-encoding.

Accept-Encoding: gzip, deflate, br

Этот заголовок сообщает серверу, какие алгоритмы сжатия он понимает. Малоизвестный параметр br обозначает сжатие Brotli и используется на сайтах с высокой посещаемостью, таких как Google и Facebook. Для использования Brotli ваш сайт должен работать через HTTPS.

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



Вы, возможно, слышали, что сжатие Brotli выполняется медленнее. Причина в том, что Brotli имеет 11 режимов сжатия, и по умолчанию выбирается тот, при котором получаются файлы наименьшего размера, что удлиняет процедуру. GZIP, с другой стороны, имеет 9 режимов, и по умолчанию выбирается тот, при котором учитывается как скорость сжатия, так и размера файла. В результате режим Brotli по умолчанию непригоден для сжатия «на лету», но если изменить режим, то можно добиться сжатия небольших файлов с той же скоростью, что и у GZIP. Вы можете использовать его для сжатия на лету и рассматривать как потенциальную замену GZIP для поддерживающих браузеров.

Кроме того, если вы хотите максимально экономить файлы, то можете забыть о динамическом сжатии и предварительно сгенерировать оптимизированные GZIP-файлы с помощью файлов zopfli и Brotli для их статического обслуживания.

Если вы хотите прочитать больше о сжатии Brotli и его сравнении с GZIP, сотрудники компании Akamai провели обширное исследование на эту тему.

Accept и Accept-CH — обслуживайте индивидуальные ресурсы для пользователя


Оптимизация текстовых ресурсов очень важна для экономии килобайтов, но как насчёт более тяжелых ресурсов, таких как изображения, чтобы сэкономить ещё больше объёма данных?

Accept — обслуживание изображений правильного формата


Браузеры не только показывают нам, какие алгоритмы сжатия они понимают. Когда браузер запрашивает изображение, он также предоставляет информацию о том, какие форматы файлов он понимает.

Accept: image/webp, image/apng, image/*,*/*;q=0.8

Несколько лет велась борьба вокруг нового формата изображений, но выиграл webp. Webp — это формат изображений, изобретенный Google, и поддержка этого формата сейчас очень актуальна.

Используя этот заголовок запроса, разработчики могут передавать изображение webp, даже если браузер запросил image.jpg, в результате чего размер файла будет меньше. Дин Хьюм написал хорошее руководство о том, как это применять. Очень круто!



Accept-CH — обслуживание изображений правильного размера


Вы также можете включить клиентские подсказки для поддерживающих эту функцию браузеров. Клиентские подсказки — это способ сказать браузерам, чтобы они посылали дополнительную информацию о ширине области просмотра, ширине изображения и даже сетевых условиях, таких как RTT (время на передачу и подтверждение) и типе соединения, например 2g.

Вы можете активировать подсказки, добавив мета-элемент:

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink">
<meta http-equiv="Accept-CH-Lifetime" content="86400">

Или задав заголовки в исходном запросе HTML:

Accept-CH: Width, Viewport-Width
Accept-CH-Lifetime: 100

В последующих запросах браузеры начнут посылать дополнительную информацию за определенный промежуток времени (Accept-CH-Lifetime в секундах), что может помочь разработчикам адаптировать изображения к условиям пользователя, не меняя HTML.

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

<!-- this images is laid over the full width | 100 viewport width -->
<img class="w-100" src="/img/header.jpg" alt="" sizes="100vw">

С полученным заголовком ответа Accept-CH и изображениями с атрибутом sizes браузеры будут включать заголовки viewport-width и width в запросы изображений, показывая вам, какое изображение подойдёт лучше всего.



Имея поддерживаемый формат и размеры изображения, вы можете отправлять адаптированные данные без необходимости записывать ненадежные элементы изображений и обращать внимание только на формат и размер файлов, как показано ниже.

<picturе>
  <!-- serve WebP to Chrome, Edge, Firefox and Opera -->
  <source
    media="(min-width: 50em)"
    sizes="50vw"
    srcset="/image/thing-200.webp 200w, /image/thing-400.webp 400w,
        /image/thing-800.webp 800w, /image/thing-1200.webp 1200w,
        /image/thing-1600.webp 1600w, /image/thing-2000.webp 2000w"
    type="image/webp">
  <source
    sizes="(min-width: 30em) 100vw"
    srcset="/image/thing-crop-200.webp 200w, /image/thing-crop-400.webp 400w,
        /image/thing-crop-800.webp 800w, /image/thing-crop-1200.webp 1200w,
        /image/thing-crop-1600.webp 1600w, /image/thing-crop-2000.webp 2000w"
    type="image/webp">
 <!-- serve JPEG to others -->
  <sоurce
    media="(min-width: 50em)"
    sizes="50vw"
    srcset="/image/thing-200.jpg 200w, /image/thing-400.jpg 400w,
        /image/thing-800.jpg 800w, /image/thing-1200.jpg 1200w,
        /image/thing-1600.jpg 1600w, /image/thing-2000.jpg 2000w">
  <sоurce
    sizes="(min-width: 30em) 100vw"
    srcset="/image/thing-crop-200.jpg 200w, /image/thing-crop-400.jpg 400w,
        /image/thing-crop-800.jpg 800w, /image/thing-crop-1200.jpg 1200w,
        /image/thing-crop-1600.jpg 1600w, /image/thing-crop-2000.jpg 2000w">
  <!-- fallback for browsers that don't support picture -->
  <img src="/image/thing.jpg" width="50%">
</picturе>

Если у вас есть доступ к ширине области просмотра (viewport) и размеру изображений, вы можете на своих серверах поставить логику изменения размера ресурсов во главу угла.

Однако нужно учитывать, что не следует создавать изображения для любой ширины просто потому, что у вас есть точная ширина изображения. Отправка изображений для определенного диапазона размеров (image-200, image-300, ...) помогает использовать CDN-кэширование и экономит время вычислений.

Кроме того, с такими современными технологиями, как service worker’ы, вы даже можете перехватывать и изменять запросы прямо в клиенте, чтобы обслуживать лучшие файлы изображений. С включенными клиентскими подсказками service worker’ы получают доступ к информации о макетах, и в сочетании с API изображений, как, например, Cloudinary, вы можете настроить url изображения прямо в браузере для получения картинок надлежащего размера.

Если вы ищете более подробную информацию о клиентских подсказках, можете ознакомиться со статьями Джереми Вагнера или Ильи Григорика на эту тему.

Сеть должна быть бережной


Поскольку каждый из нас проводит в сети много часов в день, есть последний аспект, который я считаю очень важным — сеть должна быть бережной.

Preload — сокращение времени ожидания


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

Приведу пример: если вы добавите на сайт таблицу стилей, браузеры не будут ничего показывать, пока она не загрузится. Пока на экране ничего не отображается, браузер продолжает анализировать HTML в поисках других ресурсов для запрашивания. После загрузки и парсинга таблицы стилей в ней могут оказаться ссылки на другие важные ресурсы, такие как шрифты, которые тоже могут быть запрошены. Этот процесс может увеличить время загрузки страницы для ваших посетителей.

Используя Rel=preload вы можете дать браузеру информацию о том, какие ресурсы будут запрошены в ближайшее время.

Можете предварительно загрузить ресурсы через HTML-элементы:

<link rel="preload" href="/font.woff2" as="font" type="font/woff2" crossorigin="anonymous">

Или заголовки:

Link: </font.woff2>; rel=preload; as=font; no-push

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

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


Feature-Policy — не раздражайте других


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

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

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

Именно здесь в игру вступает заголовок Feature-Policy. С его помощью вы можете указать, какие функции разрешены, и ограничить всплывающие диалоговые окна с разрешениями, которые могут быть вызваны сторонним кодом, исполняемым на вашем сайте.

Feature-Policy: vibrate 'none'; geolocation 'none'

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

<iframe allow="camera 'none'; microphone 'none'">

На момент написания статьи заголовок Feature-Policy был, скорее, экспериментальным, но интересно посмотреть на его будущие возможности. В недалеком будущем разработчики смогут не только ограничивать себя и не допускать появления раздражающих диалоговых окон, но также блокировать неоптимизированные данные. Эти функции существенно улучшат работу пользователей.



Вы можете найти полный обзор на MDN.

Глядя на список выше, вы можете вспомнить о самом раздражающем моменте — push-уведомлениях. Оказалось, что применение Feature-Policy для push-уведомлений сложнее, чем ожидалось. Если вы хотите узнать больше, можете подписаться на соответствующую тему на GitHub.

Благодаря feature policy можете быть уверены, что вы и сторонние ресурсы не превратите ваш сайт в гонку за разрешениями, которая, к сожалению, уже стала привычной для многих сайтов.

Сеть должна быть для всех


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

Я знаю, что создание отличного сайта сегодня — очень сложная задача. Разработчики должны учитывать дизайн, устройства, фреймворки, и да… заголовки тоже играют определённую роль. Надеюсь, эта статья даст вам некоторые идеи, и вы будете учитывать безопасность, доступность и уважительность в ваших следующих веб-проектах, потому что это именно те факторы, которые делают сеть по-настоящему отличным местом для всех.
Mail.ru Group
1118,00
Строим Интернет
Поделиться публикацией

Комментарии 62

    0
    Спасибо большое за статью! Пойду проведу ревизии;) своих сервисов
      +8

      Отправлять экран тэгов вместо одного img и создавать 25 разных картинок вместо одной?
      Сливать данные о размере окна браузера (которые нередко довольно уникальны и сильно упрощают идентификацию пользователя) и сетевом подключении уже не только через JS, не только через CSS, но и прям добровольно заголовками?


      Так себе прогресс, как на мой взгляд… это скорее демонстрация того, что мы где-то по дороге свернули не туда, куда надо было.

        0

        Всё для удобства пользователя. А слежка за ним неотъемлемая часть веба с первого его дня, наверное. Ну как логи стали писать. Проблема не в слежке как таковой, а в людях, которые её результаты используют, а использовать их можно по разному.

          +3
          Всё для удобства пользователя.

          Ой ли? Если б было «для удобства пользователя», то почему бы, не обнаружив у пользователя хоть сколько-нибудь приличную систему (не смартфончик 15-летней давности) просто отгрузить ему клиентского JS, который будет работать у него максимально автономно, снижая нагрузку на сеть?

          Но почему-то любители создать 25 разных картинок и подгонять их под экранчик пользователя, размер которого они только что узнали и запомнили — никогда так не делают. И видится мне, не делают именно потому, что девиз «для удобства пользователя» никогда не имеет никакого отношения к реальности. Для удобства разработки? Вероятно. Для удобства конторы? Очень возможно. Для удобства пользователя? Вы о чем вообще?
            0

            Для удобства разработки и конторы была бы одна картинка с разрешением любимого девайса гендира или собственника :)

        0
        и HSTS

        А можно внятно ответить чем это лучше редиректа с http на https?

        Из минусов HSTS на своей шкуре почувствовал — сайт не будет доступен для тех кто его открывал, пока не наладишь SSL, «если что то пошло не так»
        Т.е. тупо нет «запасного варианта» И пофиг, что SSL по факту нужен на одной страничке.
          +1
          чем это лучше редиректа с http на https?

          MitM перехватит запрос и порежет редирект — клиент так и останется сидеть на http. Именно поэтому нужен не просто HSTS, а именно preload, чтобы даже самый первый запрос от клиента пошёл по https и MitM не смог ничего порезать

            0
            Каюсь, был не прав. Смотрел со своей колокольни.
            С другой стороны все эти всплывашки в браузере на полях ввода. Хотя кто то может не обновляться, да. (секта мля)

            PS. И кстати меня удивило, что HSTS это запоминание ЕСЛИ УЖЕ был по https. Т.е. редирект все равно нужен. А если нужен редирект и делает тоже самое, то зачем нужен HSTS.
            Это собственно логическая цепочка которая привела к изначальному вопросу.

            PSS. а именно preload не очень понял при чем тут это. Ты первый раз заходишь по http… Тут надо типа плага addons.mozilla.org/ru/firefox/addon/https-everywhere который НАВЕРНОЕ тычет в 443 порт если пытаешься по 80 войти.
            +2
            И пофиг, что SSL по факту нужен на одной страничке.

            SSL обязан быть на ВСЁМ сайте, иначе защиты никакой не получится, MitM без проблем порежет редирект для этой одной странички. Кроме того, сертификаты сейчас бесплатные — какой вообще смысл не использовать https в 2019 году?


            пока не наладишь SSL

            Дык надо в первую очередь наладить SSL, несколько недель/месяцев попроверять, что всё нормально работает, и только потом включать HSTS. Если вы делали наоборот, то ССЗБ

              0
              > Дык надо в первую очередь наладить SSL, несколько недель/месяцев попроверять, что всё нормально работает, и только потом включать HSTS. Если вы делали наоборот, то ССЗБ

              А потом выясняется (через 3 месяца или сколько там сейчас) что забыл прописать PATH в кроне для certbot или еще что нибудь. Но ведь «всё нормально работает», да?
                0

                certbot в норме запускается два раза в день, и «No renewals were attempted» в логах потрудится прочитать любой ответственный админ. Если не прочитал — что ж, опять ССЗБ.


                Я себе вообще уведомления на почту прикрутил. Так и флудит, что ни один сертификат не обновлён

                  0
                  > Если не прочитал — что ж, опять ССЗБ

                  А если прочитал, но при обнове конфликты доменов и прочая ересь (с многозначительным digest does not match от LE)?
                  Сейчас то уже знаю что пуляй --dry-run если есть сомнения, но изначально где об этом сказано?

                  > Так и флудит, что ни один сертификат не обновлён

                  И какой смысл от таких уведомлений? В один прекрасный момент Вы удалите реальную проблему )
                    0

                    Опция --dry-run выдаётся первой ссылкой по запросу в гугле "how to test letsencrypt config". Так что если админ захочет проверить работоспособность — он найдёт, как это сделать, и проверит. А если его нужно постоянно тыкать носиком в "сделай то" и "проверь это" — что ж это за админ такой?

                      0
                      Ты админил хоть что нибудь (кроме лично ТЕБЕ дорого проекта) что бы такие заявы делать? )
                      А как поисковиком пользоваться я знаю, сам учу.
                        0

                        Ну вот и отлично, гуглить — очень полезный навык не только для админа, но и вообще для любого человека!


                        У меня сейчас под котролем certbot'ы на четырёх разных серверах на несколько десятков доменов в течение трёх лет, с самого выхода Let's Encrypt из беты — и ни один из них никогда не сбоил.

                          0
                          > на четырёх
                          > на несколько десятков

                          Ну ваще крут. А бывало такое что у тебя центос и поддомены в одном файле? )
                          И сертбот корёжит ssl составляющую?

                          PS. «Как» гуглить не наука. Важно «ЧТО» гуглить.
                            0

                            У меня как бы тоже поддомены в одном файле. Если у всех не корёжит, а у вас корёжит — подозреваю, дело вовсе не в сертботе.

                              –1
                              > подозреваю, дело вовсе не в сертботе.

                              Как это не в нем если он корежит? Т.е. если ты сейчас пизданешь в какой нибудь америке что черный это нигер — это преступление, а если мой конфиг «не правильный», то виноват не тот кто ударил чтоли? )

                              Баг явно в нем, но я свой конфиг поправил.

                              ЗЫ. И да, проблемы выявились не сразу.
                                0

                                Но вы так и продолжите играть в секретики и не расскажете, что за баг? И почему у меня его нет?


                                Возвращаясь к теме ошибок — опять же, крон шлёт на почту сообщения об ошибках. Если спустя три месяца админ забивает болт на почту и таким образом не узнаёт, что сертификаты не обновились — увольнять его незамедлительно.

                                  0
                                  > Но вы так и продолжите играть в секретики и не расскажете, что за баг?

                                  Да не помню я подробности. Давно уже центос не обслуживаю. Замшелое г… пахнущее нафталином.

                                  Там фишка в том что сертбот создает временный конфиг и включает его в текущий для проверки LE.
                                  И там замут с регекспами (nginx конфиги), в итоге включался не туда и с вырезанными поддоменами. Хз может починили давно, но запомнилось (потому что пришлось разбираться).

                                  В итоге переделал на webroot просто

                                  > Если спустя три месяца админ забивает болт

                                  Если настраивать уведомления как Вы — он так и сделает.
                                    0
                                    (nginx конфиги)

                                    А, ну так nginx-конфиги в certbot всегда были нестабильными. Как ответственный админ (несмотря на то, что я вообще не админ) я следую принципу KISS, не доверяю всем этим «умным» конфигураторам (и вообще не переношу, когда что-то не под моим контролем), использую только certonly и пишу/генерирую плейбуком конфиги сам. Как я уже говорил выше, три года — полёт нормальный.


                                    давно

                                    Ну так «давно» nginx-конфиги были в бете. Если вы потащили бету на продакшен — вы опять ССЗБ.


                                    Увы, пока по вашим комментам получается, что вы забили болт на все best practices ¯\_(ツ)_/¯

                                      0
                                      Да не было никакого продакшена, с чего это вообще было взято. Был опыт работы с certbot )

                                      Раньше «подозреваю, дело вовсе не в сертботе», сейчас «А, ну так nginx-конфиги в certbot всегда были нестабильными.» — прогресс на лицо )
                                        0
                                        Да не было никакого продакшена

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


                                        В конце концов, никто не запрещает подождать, пока certbot успешно обновит сертификаты хотя бы один раз, и только после этого включать HSTS. Если админ не забьёт болт, конечно.

                                          0
                                          А потом они изменят протокол/условия для получения серта и привет.
                                          И они даже могут уведомить. Но админ не прочитает.

                                          Да, я тоже «верю» что этого не произойдет, но на всякий случай HSTS не включаю иногда…

                                          PS. А как мы выяснили ранее, HSTS абсолютно бесполезен, если траффик изначально прослушивается/подменяется.
                                            0

                                            Кажется, в комментах выше я уже писал про админа, не читающего почту? Вы правда думаете, что изменения обязательно произойдут ВНЕЗАПНО, без нескольких предупреждений лично каждому админу за несколько месяцев/лет до поломки совместимости?

                                              0
                                              > Вы правда думаете, что изменения обязательно произойдут ВНЕЗАПНО

                                              Да что далеко ходить.
                                              habr.com/ru/post/451220
                                                0

                                                Дык это у Mozilla те самые безответственные админы, которых нужно незамедлительно уволить. Во-первых, подобные баги лечатся своевременными обновлениями и адекватным мониторингом, а во-вторых, это вообще никак не относится к Let's Encrypt. Ходите чуть дальше.

                                                  0
                                                  Дык это у Mozilla те самые безответственные админы


                                                  Ты в каком то идеальном мире живешь. Если ДАЖЕ у мозиллы есть такие админы, почему ты думаешь что не те же самые админы админять letsencrypt?

                                                  PS. Мозиловский реестр сертификатов считается самым доверенным BTW
                                                    0

                                                    Если бы мы жили в идеальном мире, то не существовало бы ни бэкапов, ни мониторинга.


                                                    И вновь мы возвращаемся к тому, что уже обсудили выше:


                                                    крон шлёт на почту сообщения об ошибках. Если спустя три месяца админ забивает болт на почту и таким образом не узнаёт, что сертификаты не обновились — увольнять его незамедлительно.

                                                    Если админ Let's Encrypt накосячит — вы об этом обязательно узнаете, потому что ваш мониторинг вас об этом уведомит. Если не уведомит — вас надо уволить.


                                                    Если вы хотите поиграть в конченого параноика и боитесь, что крон тоже ни о чём не уведомит, никто не мешает накатать какой-нибудь Python-скрипт, который раз в сутки будет проверять сроки годности сертификатов и уведомлять хоть на почту, хоть в телеграм, хоть в корпоративный Slack/Mattermost-чат. Было бы желание.


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




                                                    PS. А как мы выяснили ранее, HSTS абсолютно бесполезен, если траффик изначально прослушивается/подменяется.

                                                    Перечитайте пост ещё раз, особенно в тех местах, где упоминается слово «preload».

                                                      0
                                                      Пока вы лишь продолжаете строить из себя такого же безответственного админа, как админы мозиллы.

                                                      Всего лишь пытаюсь вернуть вас к реальности ;)

                                                      Перечитайте пост ещё раз, особенно в тех местах, где упоминается слово «preload».

                                                      preload нихрена не даст. Запрос уже ушел на 80 порт и ответ уже подменен )
                                                        0
                                                        Всего лишь пытаюсь вернуть вас к реальности ;)

                                                        Пока вы лишь строите из себя админа в манямирке без мониторинга.


                                                        preload нихрена не даст.

                                                        Перечитайте ещё раз.


                                                        Я даже процитирую ту часть, которую нужно перечитать:


                                                        Если вы хотите сделать всё возможное, чтобы браузер никогда не запрашивал ваш сайт по HTTP, можете также задать указатель preload и отправить ваш сайт в глобальный список. Если конфигурация HSTS вашего сайта соответствует минимальному max-age в один год и активна для поддоменов, он может быть включен во внутренний список браузер для сайтов, работающих только через HTTPS.
                                                          0
                                                          Пока вы лишь строите из себя админа в манямирке без мониторинга.

                                                          А на мой взгляд, Вы строите из себя НЕВЪЕБЕННОГО ОДМИНА. Который НИКОГДА НЕ ОШИБАЕТСЯ.

                                                          Я всего лишь пытаюсь доказать что ВСЕ ошибаются. Наверное Вы молоды, чтобы это осознать.

                                                          Я даже процитирую ту часть, которую нужно перечитать:

                                                          А мою часть прочитать про плаг для мозилы?

                                                          Что билять такое ваш «preload» (возможно я не понял и воспринял как одноименный аттрибут для script)?
                                                          Мое предложение хоть пример имеет :)
                                                            0
                                                            Который НИКОГДА НЕ ОШИБАЕТСЯ.

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


                                                            Что билять такое ваш «preload»

                                                            Раз вы за время нашей переписки так и не научились ни читать пост, ни википедией пользоваться, ни гуглить, то объясняю. В современных браузерах встроен оффлайновый список доменов, которые нужно открывать только по https, и для них первый запрос НИКОГДА не пойдёт по http.


                                                            Картинко
                                                              0
                                                              > внутренний список браузер для сайтов
                                                              Т.е. еще одна зависимость от каких то внешних сервисов.

                                                              > оффлайновый список доменов
                                                              Кто их будет обновлять? Гугл? Захочет гугл и писец?
                                                              Ты не правильный админ )

                                                              PS. Лучше распиздяй, чем кто то завязывающийся на чужих сервисах и продвигающий это.
                                                                0

                                                                Тогда уж надо мыслить ещё шире: центры сертификации продажные, и один известный кгбшник просто купит у них левый сертификат для вашего домена. А один известный владелец американских казино и без левых сертификатов всё прочитает благодаря закладкам в RSA и AES.


                                                                К сожалению, я пока не придумал, как жить так, чтобы не доверять прям вообще никому.

                                                                  0
                                                                  Но ведь долбить по 443 порту вместо 80го все решает ;)
                                                                  0
                                                                  кто то завязывающийся на чужих сервисах

                                                                  Я так понимаю, вы уже сделали свой центр сертификации, свой браузер, свой корневой DNS, свой интернет-провайдер, свою точку обмена трафиком в своём дата-центре со своим серверным железом и своими прошивками с полным аудитом всего этого кода и прилагающейся своей электростанцией с самостоятельной добычей ресурсов для неё?

                                                                    0
                                                                    Но ведь все это не нужно если тупо запросы с 80 на 443 направлять? )

                                                                    Понятно что на 443 может быть обычный 80, но кто этим будет «заморачиваться»?
                                                                    И это надежней чем какие то «списки».
                                                                      0

                                                                      Но ведь они не направятся, потому что чужой сервис в виде гугла в обязательном порядке захочет напакостить лично вам и не добавлять ваш сайт в свой список доменов. Нужно срочно делать свой собственный браузер со своим собственным списком, чтобы не завязываться на гугл! Почему я не вижу у вас хабрапост с описанием вашего собственного браузера с правильным импортозамещённым списком доменов?

                                                                        0
                                                                        У вас «список головного мозга».
                                                                        Еще раз.
                                                                        1. Делается запрос на http (80 порт)
                                                                        2. Браузер «тыкает» тот же домен по https (443 порт)
                                                                        3. Ответ получен, мы в шоколаде. Сертификаты и вот это вот все
                                                                        4. Ответ НЕ получен. Продолжаем по лоховскому http

                                                                        Зачем какой то свой браузер и т.п. если что то подобное уже реализовано?
                                                                          0
                                                                          1. Делается запрос на http (80 порт)

                                                                          Не делается, потому сайт находится в списке, который встроен в браузер, который запрещает делать запрос по http. Всё.


                                                                          Вы не доверяете этому списку? Делайте свой браузер и не завязывайтесь на чужие сервисы.


                                                                          Вы доверяете этому списку? Тогда в чём проблема?

                                                                            0
                                                                            Я злобный хакер работающий в гугл.
                                                                            Дальше продолжать?

                                                                            Мой вариант не зависит от всяких «списков».

                                                                            > Вы доверяете этому списку?

                                                                            Не доверяю никому. А +1 кандидат в доверие не нравится.
                                                                              0
                                                                              Мой вариант

                                                                              Какой вариант? Перечитал все ваши комментарии в этом посте — не увидел ничего похожего на рабочий вариант.

                                                                                0
                                                                                PSS. а именно preload не очень понял при чем тут это. Ты первый раз заходишь по http… Тут надо типа плага addons.mozilla.org/ru/firefox/addon/https-everywhere который НАВЕРНОЕ тычет в 443 порт если пытаешься по 80 войти.


                                                                                Ну и
                                                                                Еще раз.
                                                                                1. Делается запрос на http (80 порт)
                                                                                2. Браузер «тыкает» тот же домен по https (443 порт)
                                                                                3. Ответ получен, мы в шоколаде. Сертификаты и вот это вот все
                                                                                4. Ответ НЕ получен. Продолжаем по лоховскому http


                                                                                А мы дальше думаем про «списки»…
                                                                                  0
                                                                                  https-everywhere

                                                                                  То есть вы доверяете стороннему плагину, но не доверяете браузеру? Ай-ай-ай, двоемыслие во все поля.


                                                                                  Ответ [по 443] НЕ получен. Продолжаем по лоховскому http

                                                                                  И злобный mitm-хакер, порезав доступ к 443 порту, радостно перехватывает все пароли. Вы сами-то осознаёте, что пишете?

                                                                                    0
                                                                                    И злобный mitm-хакер, порезав доступ к 443 порту, радостно перехватывает все пароли. Вы сами-то осознаёте, что пишете?


                                                                                    И чем в этом помогут списки? Вы хотя бы понимаете что «bla.com» есть «альяс» «bla.com:443»?

                                                                                    Вы сами-то осознаёте, что пишете?

                                                                                    То есть вы доверяете стороннему плагину, но не доверяете браузеру? Ай-ай-ай, двоемыслие во все поля.

                                                                                    Кто сказал, что я ему доверяю? Я объяснил как в «в идеале».
                                                                                      0
                                                                                      И чем в этом помогут списки?

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


                                                                                      Кто сказал, что я ему доверяю?

                                                                                      Тогда не нужно его вообще упоминать. «В идеале» у нас и злобных хакеров не существует и шифровать ничего не надо.

                                                                                        0
                                                                                        Тем, что запрос по порту 80 не пойдёт

                                                                                        Даже если хозяин сервера захотел? Да бля тут списки никакие не нужны. Тупо на всех роутерах заблочить и все…

                                                                                        ЗЫ. Хорошо что тебя нет во всяких комиссиях принимающих решения.
                                                                                          0
                                                                                          Тупо на всех роутерах заблочить и все…

                                                                                          Было бы отлично, «в идеале». К сожалению, у нас существуют ленивые админы, которые не хотят переходить на https (и настраивать мониторинг для слежения за работой certbot). Приходится жить в реальном мире и костылять со списками.


                                                                                          Даже если хозяин сервера захотел?

                                                                                          Если хозяин сервера захотел — он просто не будет включать HSTS. И злобные хакеры неизбежно будут слушать пользователей сайта, ага. Если принцип Неуловимого Джо не сработает.

                                                                                            0
                                                                                            «В идеале» у нас и злобных хакеров не существует и шифровать ничего не надо.

                                                                                            Хакеры трафик не слушают (ресурсов нет, если не наняты государством). Это делают правительства. Для начала.

                                                                                            у нас существуют ленивые админы, которые не хотят переходить на https

                                                                                            Нет, не только. Есть еще кровавый Ынтерпрайз. Циски/оракл/HP и прочее. Пересадишь все инфраструктуры на https?

                                                                                            Если хозяин сервера захотел — он просто не будет включать HSTS

                                                                                            Дык я об этом с самого начала )
                                                                                              0
                                                                                              Хакеры трафик не слушают

                                                                                              И я слушал, и меня слушали. Вайфай — отличное место для мамкиных хакеров, чтобы слушать. Не обязательно слушать весь интернет сразу.


                                                                                              Это делают правительства.

                                                                                              Правительства подкупают центры сертификации и делают ослабленные алгоритмы шифрования, так что говорить тут вообще не о чем.


                                                                                              Есть еще кровавый Ынтерпрайз.

                                                                                              Его тоже нужно иногда обновлять. Сидеть по полвека на одном и том же оборудовании и ПО не выйдет, ибо решето. Если только это не полностью изолированная от интернета инфраструктура, но тогда и об https разговаривать вообще нет смысла.


                                                                                              Дык я об этом с самого начала )

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

                                                                                                0
                                                                                                Вайфай — отличное место для мамкиных хакеров, чтобы слушать.

                                                                                                Построивший инфраструктуру предприятия на вайфае который можно прослушать разве не должен гореть в аду? )

                                                                                                Я-то с точки зрения обеспечения безопасности рассуждаю

                                                                                                А если за это не платят, а за простои «штрафуют» (а за дыры не штрафуют)?

                                                                                                Не все чернобелое )
                                                                                                  0
                                                                                                  Построивший инфраструктуру предприятия на вайфае который можно прослушать разве не должен гореть в аду? )

                                                                                                  Обязательно должен. Но далеко не все верят в ад, и открытые вайфаи встречаются на каждом квадратном метре любого крупного города. А телефоны прохожих к ним автоматически подключаются.


                                                                                                  А если за это не платят, а за простои «штрафуют» (а за дыры не штрафуют)?

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

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

                                                                                                    Мы про гипотетический «завод по обработке перс данных». Если «завод» не удосужился нанять админа который хотя бы знает про ВЛАНЫ, это проблема завода или админа?

                                                                                                    Всё чёрно-белое, и все ваши примеры — чёрные.

                                                                                                    И виноваты всегда админы, да? )
                                                                                                    Не «нормативы» и прочая ересь?
                                                                                                      0

                                                                                                      Когда вы на "заводы" успели перейти? Я говорю про всё сразу: и про циски, и про блоги васей пупкиных.


                                                                                                      "Нормативы" — это и есть чёрное. Не зацикливайтесь на админах, гореть в аду могут не только они.

                                                                                                        0
                                                                                                        Тогда больше спорить не о чем. Мне почему то казалось что у вас админы во всем виноваты.

                                                                                                        «Нормативы» — это и есть чёрное

                                                                                                        А админы, которые следуют только им, а не здравому смыслу — «серое» )
                                                                                                        Админы-распиздяи — черное.

                                                                                                        Так что градации есть )
              0

              Прекрасная статья, спасибо! Как говорится, век живи — век учись.


              Вот только я что-то не догнал, в чем плюс Immutable, не могли бы вы пояснить на примере, как поведет себя браузер с этим параметром и без него

              0
              Читаю я, значит, вот это:

              Чтобы избежать взлома вашего сайта, CSP также предоставляет режим только для отчетов.

              И чешу репу… Что же это получается, есть шанс сделать сайт уязвимым при неправильной настройке CSP??? И тут я осознаю, это же перевод. Лезу в оригинал:

              To avoid breaking your site, CSP also provides a report-only option.

              Болд в обоих местах мой. Речь не о взломе, а нарушении функционирования.
                0
                Если первый запрос сделан через HTTP только для получения перенаправления, то пользователь может несколько секунд ничего не видеть на экране. А с помощью HSTS вы можете сэкономить эти секунды, и браузер автоматически будет использовать HTTPS.

                Не совсем понятно. Первый http запрос для получения редиректа заменили на первый http запрос для получения заголовка HSTS. Так а где экономия по времени тогда?
                  0

                  Заголовки HSTS лучше кешируются, и обычная очистка кеша их не удаляет. Кроме того, для известных сайтов HSTS правила уже вшиты в исходники браузера, так что даже установленный с нуля браузер сразу пойдет на https версии этих сайтов. Вот пример такого файла в исходниках Chromium, осторожно, весит 76 Мб и может открываться долго.

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

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