Сайт больше не доступен по https что это значит и что надо делать?

9 ответов на вопрос “Сайт больше не доступен по https что это значит и что надо делать?”

  1. Dezbch Ответить

    Согласно официальным заявлениям представителей Google, с начала 2017 года сайты, работающие по протоколу http, будут помечаться в браузере Chrome, как небезопасные.
    Совершенно очевидно, что это наложит свой отпечаток на продвижение веб-сайтов в поисковиках, поскольку использование (или не использование) защищенного протокола https еще с середины 2014 года является одним из факторов ранжирования поисковых выдач.
    Это является особенно важным для тех сайтов, которые каким-либо образом связаны с финансовыми операциями, а также с обработкой прочих личных данных клиента (телефон, e-mail, имя), так как с точки зрения Google они могут стать целью атаки хакеров, охотящихся за конфиденциальными данными их посетителей (в т. ч. платежными).
    Поэтому чтобы не попасть под искусственное понижение позиций за несоответствие требованиям поисковика, необходимо произвести настройку протокола https уже сейчас.

    Подготовительный этап к переходу на https протокол

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

    Исправить ссылки для вложений с медиа-контентом. Если контент находится на сторонних сайтах, то изменять в таких URL http на https следует только, если конечный веб-ресурс доступен по данному протоколу. Но если медиа-файлы расположены в пределах веб-сайта, то их адреса необходимо переделать на относительные по аналогии с обычными внутренними ссылками.
    Проверить и при необходимости исправить настройки подключения внешних скриптов. Если в скриптах используются абсолютные ссылки, в них также нужно сделать соответствующие изменения и прописать относительные пути.

    Эти три этапа являются предварительной подготовкой и в основном являются самой затратной (с точки зрения временных ресурсов) статьей расходов при переходе на https протокол.

    Основной этап настройки протокола https

    Выбрать и приобрести SSL-сертификат. Придется выбирать, учитывая Ваши потребности и возможности, среди таких видов сертификатов:
    a) Обычные. Используются для одного домена. Подходят физ. и юр. лицам. Выпускаются всего за несколько минут. Требуется лишь проверка принадлежности домена тому, кто запрашивает SSL-сертификат.
    b) Extended Validation (EV). В этой категории находятся сертификаты с расширенной проверкой: помимо подтверждения прав доступа к домену, проверяется свидетельство о госрегистрации организации, наличие имени организации в данных Whois, совершаются проверочные звонки и т. д.
    При приобретении сертификата данного вида появляется возможность получить зеленую пометку в виде «замочка» с названием компании в адресной строке, что для большинства интернет-пользователей является символом надежности веб-сайта.
    c) Wildcard-сертификаты. Используются для поддоменов.
    d) Сертификаты, поддерживающие IDN. Используются для сайтов с доменом на кириллице.
    Установить SSL-сертификат на сервере. В большинстве случаев эта процедура выполняется через панель управления, предоставленную хостером, и занимает всего несколько минут.

    В случае, если самостоятельно выполнить ее не удается, на помощью приходит техподдержка. Еще вариант – обратиться за помощью к специалисту в программировании.
    Кстати перед тем, как установить https протокол, следует поинтересоваться у хостера, поддерживает ли он эту возможность. Большинство крупных компаний, предоставляющих услуги хостинга, давно ввели поддержку SLL-сертификатов, но некоторые все еще продолжают «пасти задних».
    Поэтому может потребоваться перенос сайта на сервера более современного хостера.
    Проверить доступность веб-сайта. Убедитесь в том, что доступ к успешно настроенному сайту с протоколом https имеется по обоим вариантам: и с http, и с https в начале адреса. Теперь по умолчанию при вводе в адресную строку URL сайта с http должно происходить автоматическое перенаправление на защищенный протокол https.
    Если сайт недоступен по одному из вариантов или же не осуществляется перенаправление, значит настройка выполнена неверно или имеются проблемы со стороны хостера. В любом случае нужно искать причину этого и как можно скорее ее устранять.

    Этап настройки сайта после перехода на https протокол

    Настроить 301 редирект. Чтобы не заниматься тратой времени, внося соответствующие команды в код каждой странички сайта, следует воспользоваться возможностью прописывания редиректа 301 в файле .htaccess с помощью модуля mod_rewrite или же обратиться за соответствующей просьбой к техподдержке хостера.

    Найти и устранить ошибки. В процессе перехода сайта на https протокол невозможно уследить за всеми нюансами. Поэтому по завершению этого процесса следует убедиться в том, что доступны все страницы веб-сайта, ссылки на них работают корректно, медиа-вложения отображаются верно и находятся на своих местах.
    Уведомить поисковики о переходе на https протокол. Этот этап необходим для того, чтобы обезопасить свой веб-сайт от потери трафика из поисковиков.
    Используя Google Search Console, нужно добавить и указать в качестве главного зеркала новую версию сайта с протоколом https.

    В Яндекс.Вебмастере в разделе настроек индексирования имеется функция «Переезд сайта», воспользовавшись которой нужно указать домен и поставить галочку «Добавить HTTPS».

    На этом все. Остается только дождаться переиндексации сайта после перехода на https протокол. После этого в поисковых выдачах начнут отображаться URL его страниц с https.
    На этом этапе возможны скачки в количестве загруженных в индекс поисковика страничек и занимаемым ими позициями. Но если все вышеперечисленные рекомендации были выполнены правильно, довольно скоро все должно вернуться к изначальным показателям (с допустимыми потерями в 2-3%).
    Надеемся, после прочтения этого материала переход на https протокол перестанет Вам казаться чем-то чрезвычайно сложным.
    Также возьмите себе на заметку, что новые веб-сайты лучше сразу создавать с его использованием, ведь это новый стандарт, к которому рано или поздно придется привыкнуть всем.

  2. serwest33 Ответить

    Если вы еще не перевели свой сайт на протокол HTTPS, почитайте материал «Как перевести сайт на протокол https. Установка SSL сертификата».
    Вам так же может помочь пошаговая инструкция по получению бесплатного SSL-сертификата от доменного регистратора Reg.ru.

    После установки SSL-сертификата необходимо сделать несколько настроек, чтобы сайт корректно работал по протоколу HTTPS.

    Почему это нужно сделать?
    Во-первых, после установки сертификата ваш сайт будет доступен как по протоколу https, так и по протоколу http. Поэтому вам нужно настроить специальный редирект, чтобы все посетители сайта, даже набрав в браузере http://вашсайт.ru попадали на вариант сайта https://вашсайт.ru.  В противном случае посетитель получит предупреждение о том, что сайт небезопасен.
    Во-вторых, весь контент на страницах сайта так же должен подгружаться по протоколу https, иначе браузер снова будет выдавать предупреждение. Картинки, скрипты, таблицы стилей — все это должно быть подгружено по протоколу https.
    Пример. Когда ваш сайт работал еще по http, вы создали страницу или запись и разместили на ней изображение. В момент загрузки изображения на ваш сайт картинка получила свой адрес, который выглядит примерно так:
    http://mysite.com/wp-content/uploads/2016/03/izobrajenie.jpg
    Зеленым выделено имя файла, все остальное — это адрес его размещения на вашем сайте, включая указание на протокол загрузки — http.  Соответственно, когда вы это изображение помещали на страницу сайта, ссылка на подгрузку изображения выглядела именно так.
    После того, как вы перевели сайт на работу по протоколу https, ссылки на все изображения и прочий контент остались прежними, те в них указан протокол http. Поэтому когда посетитель откроет в браузере страницу с этим изображением, браузер будет сообщать о небезопасном контенте, несмотря на то, что сама страница открыта по безопасному протоколу. Соответственно, эту проблему нужно решить тоже.
    ВАЖНО! Прежде, чем начнете вносить изменения в свой сайт, обязательно сделайте резервную копию сайта — всех файлов и базы данных, на случай, если что-то пойдет не так и вам понадобится сделать откат к предыдущей версии.
    Так же мы рекомендуем делать резервную копию любого системного файла, в который вы будете вносить изменения. Это позволит в случае неудачного исхода просто заменить файл на старую версию.

    Нужен ли выделенный IP-адрес для установки SSL-сертификата?

    Нет, не нужен. Все будет работать и без выделенного IP. У выделенного IP-адреса, безусловно, много преимуществ, но для установки SSL его наличие не является критичным.

  3. Grave35 Ответить

    Вы могли заметить, что перед ссылкой на любой сайт есть небольшая приставка – http:// или https:// Это тип протокола. Сильно углубляться в это понятие нет необходимости, нужно лишь понимать, что HTTP — это старый протокол, а HTTPS – новый и современный. Нужно использовать HTTPS.
    Чтобы сайт работал по HTTPS нужно получить SSL сертификат. Его можно заказать на хостинге, в большинстве случаев есть возможность получить его бесплатно.
    HTTPS отличается от HTTP тем, что имеет уровень защиты данных, переданных через сайт. Если через HTTP можно легко похитить такую личную информацию, как номера карточек, телефонов, электронные почты, паспортные данные, разнообразные пароли и пин-коды (в зависимости от того, что требует сайт), то через HTTPS это сделать намного сложнее.
    Что из этого следует? Во-первых, естественно безопасные сайты ранжируются в поисковиках намного лучше, чем потенциально опасные. Поэтому сайт на HTTPS будет лучше продвигаться.
    Во-вторых, большинство современных браузеров так или иначе предупреждает посетителя о небезопасности визита, если сайт работает по HTTP.
    И, в-третьих, никогда сами не оставляйте личные данные на сайте, который работает по HTTP.
    Отсюда становится понятно, что переход на HTTPS совершить нужно, как можно раньше. Давайте рассмотрим ниже, с какими проблемами сталкиваются новички в этом деле.

    Как переходят на HTTPS

    Вся процедура состоит из нескольких простых этапов. Однако даже в них бывают ошибки на практике.
    Приобретение и установка SSL сертификата.
    Настройка редиректа (перенаправления).
    Проверка всего контента на корректную работу по HTTPS.
    Настройка главного зеркала в поисковиках.

    Ошибки при переходе на HTTPS

    Смешанный контент

    Симптомы проблемы таковы: вроде всё работает нормально, и сертификат установился, и перенаправление с HTTP на HTTPS работает корректно, а всё равно в браузере написано, что сайт не защищён, хоть и адрес его начинается с HTTPS.
    Причина этому одна – некоторый контент на сайте всё ещё работает по HTTP. То есть, несмотря на то, что весь сайт перешёл на HTTPS, некоторые его элементы так и или иначе подгружаются по HTTP. Какие это могут быть элементы:
    Например, какая-либо графика или скрипты, которые загружается из темы. Для диагностики нужно попробовать активировать другую тему. Для лечения, нужно попробовать загрузить заново проблемные элементы заново, а если не получится, то отказаться от этой темы, она устарела.
    Аналогично, как и с темами обстоят дела и с плагинами. Но это реже.
    Если на сайте работают скрипты от сторонних сервисов (кнопки социальных сетей, обратный звонок, реклама), то нужно проверить, если ли в возможность в этом сервисе переключиться на HTTPS. Если нет, то также надо отказаться от сервиса, он уже устарел.
    Возможно на сайте есть вручную установлены какие-либо ссылки, которые остались по HTTP.

    Неправильно сделанный редирект

    Редирект — это перенаправление. Если всё сделано верно, то старый адрес с HTTP должен отдавать при обращении код ответа 301 (вечное перенаправление), и перенаправлять на новый адрес с HTTPS.
    Редирект можно реализовать тремя способами:
    На хостинге, как правило в разделе “Сайты” можно создать перенаправление.
    В файле .htaccess, который находится в корневой папке сайта. Для перенаправления в него нужно внедрить специальный код.
    С помощью плагина для WordPress.
    Симптомами не правильного редиректа могут быть такие признаки:
    При посещении сайта браузер выдаёт сообщение о выполнении слишком большого количества перенаправлений.
    При посещении главной страницы сайта с адресом по HTTP не происходит перенаправление на HTTPS.
    При посещении главной по HTTP перенаправление на HTTPS происходит, а при такой же операции с другими страницами, перенаправление не работает.
    При обнаружении этих признаков, их нужно устранить. Если вы сделали перенаправление, а оно не работает, то обратитесь в поддержку вашего хостинга.

    Файл robots.txt

    В файле robots.txt всё просто. Как правило, в нём есть раздел для поисковика Яндекс, в котором содержатся две директивы – host и sitemap. В них нужно не забывать исправить адрес на HTTPS. Если в этом файле указываются URL сайта и в других директивах, то их тоже надо исправить.

    Настройка главного зеркала в поисковиках

    После осуществления перехода на HTTPS, чтобы уменьшить вероятность падения посещаемости, нужно настроить в поисковиках главное зеркало сайта, которым будет, несомненно, адрес с HTTPS.
    В Яндекс Вебмастере это можно сделать в разделе “Индексирование”, подразделе “Переезд сайта”. А в Google всё намного проще и быстрее – нужно лишь добавить заново сайт Search Console с новым адресом.
    Если этого не сделать, то посещаемость может сильно пострадать, и восстановится она не скоро.

  4. sergik100 Ответить


    Всё время существования интернета открытость была одной из его определяющих характеристик, и большая часть сегодняшнего трафика всё ещё передаётся без какого бы то ни было шифрования. Большая часть запросов HTML-страниц и связанного с этим контента делается в простом текстовом виде [plain text], и ответы возвращаются тем же способом, несмотря на то, что протокол HTTPS существует с 1994 года.
    Однако иногда возникает необходимость в безопасности и/или конфиденциальности. Хотя шифрование интернет-трафика получило широкое распространение в таких областях, как онлайн-банки и покупки, вопрос сохранения конфиденциальности во многих интернет-протоколах решался не так быстро. В частности, при запросе IP-адреса сайта по хосту DNS-запрос почти всегда передаётся открытым текстом, что позволяет всем компьютерам и провайдерам по пути запроса определить, на какой сайт вы заходите, даже если вы используете HTTPS после установления связи.
    Идея о необходимости шифрования также и DNS-запросов не нова, и первые попытки этого делались ещё в 2000-х — DNSCrypt, DNS over TLS (DoT), и т.п. Mozilla, Google и другие крупные интернет-компании продвигают новый метод шифрования DNS-запросов: DNS over HTTPS (DoH).
    DoH не только шифрует DNS-запрос, но и передаёт его «обычному» веб-серверу, а не DNS-серверу, благодаря чему DNS-трафик невозможно отличить от обычного HTTPS. У этой монеты есть две стороны. Эта процедура защищает сам DNS-запрос, как DNSCrypt или DoT, а также делает невозможным ребятам из служб безопасности крупных фирм отслеживать DNS-спуфинг, и переносит ответственность за критически важные функции сети с ОС в приложение. И также это никак не помогает скрыть IP-адрес веб-сайта, который вы только что запросили – ведь вы всё равно на него переходите.
    По сравнению с DoT, DoH централизует информацию о посещённых вами сайтах в нескольких компаниях: на сегодня это Cloudflare, обещающая избавляться от ваших данных через 24 часа, и Google, которая намерена сохранить и монетизировать все подробности всего, что вы когда-либо планировали сделать.
    DNS и конфиденциальность – важные темы, поэтому давайте углубимся в детали.

    DNS-сервера и доверие

    Концепция системы доменных имён восходит ещё к ARPANET, когда в единственном текстовом файле на каждом узле ARPANET – под названием HOSTS.TXT – содержалось всё соответствие названий систем, подключённых к ARPANET и их цифровых адресов. Когда вы самостоятельно пополняли этот файл, легко было убедиться в его правильности. С ростом сети стало нереально поддерживать центральную и локальные копии этих файлов. К началу 1980-х уже начались попытки создания системы автоматизации этого процесса.
    Первый сервер имён (Berkeley Internet Name Domain Server или BIND) был написан в 1984 году группой студентов Калифорнийского университета в Беркли на основе RFC 882 и RFC 883. К 1987 году стандарт DNS был несколько раз пересмотрен, что привело к появлению RFC 1034 и RFC 1035, которые с тех пор по большому счёту не менялись.

    Основа структуры DNS состоит в её древовидной схеме, где узлы и листья делятся на зоны. Корневая зона DNS – это верхний уровень, состоящий из тринадцати кластеров корневых серверов, формирующих официальные корневые DNS-сервера. Любой новый DNS-сервер (поднятый провайдером или компанией) получает DNS-записи по меньшей мере от одного из этих главных серверов.
    Каждая последующая DNS-зона добавляет ещё один домен к системе имён. Обычно каждая страна обслуживает собственные домены, а домены типа .org или .com, не привязанные к странам, обслуживаются отдельно. Запрос имени хоста через DNS начинается с имени домена (к примеру, .com), затем с названия (например, google), за которым следуют возможные поддомены. Если данные ещё не попадали в кэш, для разрешения запроса может потребоваться совершить несколько переходов по DNS-зонам.

    DNSSEC: добавляем доверие в систему DNS

    Перед тем, как перейти к шифровке DNS-запросов, нужно убедиться, что мы можем доверять DNS-серверу. Эта необходимость стала очевидной в 1990-х, и привела к появлению первых рабочих расширений стандарта безопасности DNS (DNSSEC), RFC 2353 и пересмотренного RFC 4033 (DNSSEC-bis).

    Карта интернета 2006 года
    DNSSEC работает, подписывая записи запросов DNS публичным ключом. Подлинность DNS-записи можно подтвердить публичными ключами корневой зоны DNS, являющейся доверенным третьим лицом в этом сценарии. Владельцы доменов генерируют свои ключи, подписываемые операторами зоны и добавляемые в DNS.
    Хотя DNSSEC позволяют быть относительно уверенным в том, что ответы от DNS-сервера настоящие, этот протокол нужно включить в ОС. К сожалению, мало какие ОС реализуют сервис DNS, способный на нечто большее, чем просто «знать о наличии DNSSEC» – то есть, они на самом деле не подтверждают ответы DNS. А значит, сегодня нельзя быть уверенным в том, что получаемые вами ответы от DNS настоящие.

    Проблема с DoH

    Представим, что вы используете DNSSEC. Вы готовы зашифровать сообщения, чтобы добавить вашей передаче данных конфиденциальности. Причин для того, чтобы сохранить DNS-запросы в секрете от любопытных глаз, может быть много. Среди самых невинных — обход фильтров корпорации и провайдеров, запрет отслеживания интернет-привычек, и прочее. Среди более серьёзных — попытки избежать преследования со стороны правительства за выражение политических взглядов в интернете. Естественно, что шифрование DNS-запросов не даёт людям подсматривать эти запросы, однако в результате игнорируются более крупные проблемы с безопасностью DNS, и, естественно, всех остальных протоколов связи.
    Основными конкурентами здесь являются DoT с использованием TLS и DoH с использованием HTTPS. Самая очевидная разница между ними – это порт: DoT работает на выделенном порту TCP 853, а DoH смешивается с другим HTTPS-трафиком на порту 443. Это даёт спорное преимущество неотличимости DNS-запросов от остального трафика, что лишает возможности операторам сети (частным и корпоративным) обезопасить собственную сеть, как в прошлом году заявил в своём твиттере один из архитекторов DNS Пол Викси.
    Второе из главных отличий состоит в том, что если DoT просто отправляет DNS-запросы по TLS, то DoH по сути представляет собой DNS-over-HTTP-over-TLS, требует своего Media Type application/dns-message, и значительно всё усложняет. Смешение DoH с существующими протоколами приводит к тому, что каждый DNS-запрос и ответ проходят через стек HTTPS. Это кошмар для встроенных приложений, а также несовместимо практически со всеми существующими типами оборудования.
    У DoT есть ещё одно преимущество – этот протокол уже реализован, и гораздо дольше, чем существует DoH, используется такими компаниями, как Cloudflare, Google, а также местными интернет-провайдерами; такое стандартное серверное ПО, как BIND, использует DoT прямо «из коробки». На ОС Android Pie (9-я версия) DNS через TLS будет использоваться по умолчанию, если выбранный сервер DNS поддерживает DoT.
    Зачем переключаться на DoH, если DoT уже раскручивается? Если такие нестандартные приложения, как Firefox, будут обходить системную DNS на базе DoT, и использовать собственную систему получения доменных имён через DoH, то с точки зрения безопасности эта ситуация станет весьма сложной. Передача DNS на откуп отдельным приложениям, происходящая сейчас, кажется шагом назад. Известно ли вам, какой метод DNS использует каждое из приложений? Узнаете ли вы о том, что оно смешивает этот процесс с TCP-трафиком на 443-м порту?

    Шифрование не препятствует слежке

    За DNS over HTTPS ратуют две крупные компании, Cloudflare и Mozilla, причём последняя даже выпустила миленький комикс, где пытается объяснить схему DoH. Неудивительно, что они совершенно не упоминают DNSSEC (несмотря на то, что её называют «критически важной» в RFC 8484), и вместо этого предлагают нечто под названием Trusted Recursive Resolver (TRR), что, по сути, представляет собой совет «использовать доверенный DNS-сервер», под которым Mozilla подразумевает Cloudflare.
    Кроме DoH, они упоминают стандарт QNAME minimization (RFC 7816), который должен уменьшить количество некритичной информации, отправляемой DNS-сервером. При этом этот стандарт никак не зависит от DoH и будет работать без всякого шифрования DNS. Как в случае с DNSSEC, безопасность и конфиденциальность улучшаются через эволюцию стандарта DNS.
    Самое же интересное содержится в разделе «Чего не исправляет TRR + DoH»? Как уже говорили многие эксперты, шифрование DNS не препятствует отслеживанию. Любой последующий запрос к IP-адресу, который был получен ужасно секретным способом, всё равно будет ясно виден. Все всё равно будут знать, что вы зашли на Facebook.com, или на сайт для диссидентов. Никакое шифрование DNS или интернет-трафика не скроет информацию, жизненно необходимую для работы такой сети, как интернет.

    Станет ли будущий интернет единой точкой отказа?

    Mozilla предлагает справляться с проблемой отслеживания IP просто заявляя, что это не проблема благодаря использованию Облака. Чем больше веб-сайтов и сетей распространения контента (CDN) навесят на небольшое количество сервисов (Cloudflare, Azure, AWS, и т.п.), тем меньше будет значить этот единственный IP-адрес – нужно будет просто верить в то, что выбранный вами облачный сервис не будет воровать ваши данные и не упадёт на сутки.
    В этом году 24 июня было массивное падение сервисов, когда ошибка в настройках, сделанная провайдером Verizon, привела к тому, что Cloudflare, Amazon, Linode и многие другие большую часть дня были недоступны. 2 июля этого года примерно на полчаса упал Cloudflare, а вместе с ним и многие веб-сайты, полагающиеся на его услуги.
    По совпадению, облачный сервис Office365 от Microsoft тоже лежал в тот день несколько часов, из-за чего многие пользователи не смогли воспользоваться его услугами. В выходные перед днём труда [национальный праздник в США, отмечаемый в первый понедельник сентября / прим. перев.] отключение напряжения в дата-центре AWS US-East-1 привело к тому, что терабайт хранившихся там данных клиентов накрылся медным тазом. Очевидно, в идее о благе централизации интернета есть ещё какие-то недостатки.

    Старые песни по-новому

    Потрясающе, что во всей этой дискуссии по поводу конфиденциальности и отслеживания нет никаких упоминаний виртуальных частных сетей (VPN). Они решают проблемы с шифрованием данных и DNS-запросами, с сокрытием IP-адреса и прочим, просто перемещая точку, в которой ваш ПК или другое выходящее в интернет устройство соединяется с интернетом. Диссиденты внутри авторитарных режимов десятилетиями использовали VPN для обхода интернет-цензуры; VPN, включая такие его специальные виды, как Tor, являются критически важным элементом свободы в интернете.

    Как работает Tor
    Если вы доверяете большой коммерческой компании вроде Cloudflare в такой схеме, как DoH, то найти доверенного VPN-провайдера, не хранящего и не продающего ваши данные, будет легко. А в браузере Opera вообще есть бесплатная встроенная поддержка proxy, предлагающая множество преимуществ VPN.
    В итоге можно сказать, что DoH подтверждает свой акроним, плохо делая то, что уже хорошо удаётся DoT [«Doh!» – восклицание, указывающее на глупость совершённого действия, особенно собственного / прим. перев.]. Нужно больше концентрироваться на повсеместном внедрении DNSSEC, совместно с DoT и минимизацией QNAME. А если вас заботит реальная конфиденциальность, то вам нужно обратиться к VPN.

  5. NeitFord Ответить

    Шифрование. Мы все его любим и хотим использовать везде. Но почему оно до сих пор не применяется повсеместно?

    Проблема в сертификатах?

    Первый и наиболее распространённый барьер к переходу на HTTPS это цена получения, настройки и поддержки валидного сертификата. Вы должны найти поставщика сертификатов, подтвердить свою личность, заплатить за него и настроить сервер, а также своевременно продлевать.
    Большинство предложений перехода на повсеместное шифрование звучат примерно так: «NSA записывает весь наш трафик, почему бы не шифровать его?». Целью подобных предложений является повышение стоимости пассивного слежения за всем трафиком, а не более сложные и целевые атаки, которые применяются злоумышленниками.
    Ребята из Let’s Encrypt уже догадались, что проблема с сертификатами почти полностью поддаётся автоматизации, и что её реализация для выпуска, установки, конфигурации и продления на нескольких наиболее распространённых платформах может покрыть подавляющее большинство Интернета. Замечательная работа, и, хоть и осталось сделать многое, я думаю, что мы можем считать проблему сертификатов решённой.

    Теперь у нас есть сертификат, мы можем включить HTTPS, правильно?

    Ну, может быть. Но возможно и нет. Если все HTML ресурсы, которые вы предоставляете, имеют ссылки (картинки, скрипты…) на тот же хост и вы используете только относительные URL, то всё отлично. В противном случае скорее всего HTTPS не будет работать правильно.
    Что? HTTPS — это же хорошо, почему всё сломалось?
    Всё сломалось потому что почти наверняка у вас на странице есть смешанный контент.

    Что такое смешанный контент и почему он должен меня волновать?

    Рассмотрим следующий случай, когда вы — оператор «OriginA». Зелёные круги означают ресурсы, доступные по http и https? красные — только по http. Пунктирные линии это подгрузка контента через http. Обычные линии — https. Допустим, что все ссылки абсолютные. Красный крест означает, что загрузка завершится ошибкой.

    Теперь допустим, что вы настроили сертификат и включили https на OriginA. Как теперь будет выглядеть диаграмма?

    Если вы не обновите абсолютные ссылки в HTML, браузер всё равно будет пытаться получить ресурсы по http. Большинство запрещают такие загрузки и показывают предупреждения в таких случаях, и со временем становятся только строже.

    Почему браузеры блокируют смешанный контент? Почему я не могу повлиять на это как владелец сайта?

    В большинстве моделей Web безопасности(web security model) Источники ответственны за собственную информацию. Контент, загруженный через HTTPS может перенаправить пользователя на небезопасный сайт, может отправить POST запрос или postMessage() на небезопасный источник, и https сайт может получить GET, POST или onMessage() от документов, загруженных через http. При всём этом, почему разрешён POST, но запрещён XHR?
    Есть формальное правило безопасности, которые браузеры пытаются применять к сайтам. Впервые это правило было сформулировано как «Tranquility». Простыми словами это означает, что безопасный документ не станет небезопасным во время взаимодействия.
    Из всех сложностей и ловушек Web безопасности, браузеры пришли к выводу, что есть только один более-менее надёжный и полезный индикатор безопасности: адресная строка и замочек, означающий использование HTTPS. Если вы печатаете «https://» в адресной строке или видите иконку замка документа с которым взаимодействуете, браузер обещает вам, что контент защищён от угроз извне.
    Если бы https сайт загрузил скрипт или картинку через http, это обещание было бы нарушено. Конкретные последствия такого действия могут сильно разниться, но браузер не в праве разбираться с этим, так что он просто пресекает подобное поведение. Это сделано не только для защиты пользователей, которые не могут сами разобраться, например открывая в браузере почтовый клиент, запрашивающий скрипт через http, в кофейне, но и как индикатор для авторов контента, которые могли что-то упустить.
    Это хорошее решение для пользователей, но оно доставляет операторам сайтов некоторые сложности при переводе сайтов на https. Все их HTML ресурсы, ссылающиеся на небезопасный контент, ломаются или пугают пользователей предупреждениями. Эта проблема с зависимостями, я полагаю, настоящее препятствие, которое нужно преодолеть для перевода 100% ресурсов на HTTPS.

    Чиним смешанный контент

    Если вам необходимо исправлять проблему со смешанным контентом, то стоимость перехода на https несколько повышается. Это чуть сложнее, чем конфигурация сервера или получение сертификата, удаление смешанного контента затратно и не всегда поддаётся автоматизации.
    Для сложного сайта нельзя просто запустить s/http/https/g на всех страницах, или написать правило в mod_rewrite. Вы можете столкнуться с http ресурсами во многих местах: статический контент, динамический, клиентский, хранящийся в БД, получение данных со сторонних ресурсов, и так далее.
    Новые спецификации, находящиеся в разработке, нацелены на облегчение этого процесса; они помогают автоматически заменять http ресурсы на https.
    До:

    После:

    Upgrade-Insecure-Resources помогли с доступом OriginA в данном примере. Один из HTML ресурсов теперь не содержит смешанного контента потому, что протоколы были незаметно подменены и удалённые зависимости стали доступны через https. Этот пример показывает почему множество сайтов неохотно предоставляют собственный контент через https, во избежание пугающих сообщений об ошибках и дефектов функциональности.
    Это ведёт к печальному обстоятельству, что наименее ответственные участники на конце цепочки зависимостей могут тормозить прогресс. Циклические зависимости(так как они точно существуют в огромной структуре веба) могут создавать взаимные блокировки, которые не разрешить без координации действий.

    Ни один из этих сайтов не может включить https

    Устранение циклических зависимостей

    Не хватает промежуточного состояния между http и https. Было бы идеально, если бы данное состояние имело следующие свойства:
    1. Разрешало бы безопасным источникам, которые зависят от ваших ресурсов, получать их не нарушая принцип tranquility.
    2. Не заставляло бы другие ресурсы делать поспешные выводы о безопасности или отсутствии смешанного контента.
    3. Было бы крайне дешёвым и не создающим никаких рисков для внедрения. Идеально — добавление http заголовка.
    4. Позволяло бы определять зависимости, нарушающие принцип tranquility или создающие ошибки смешанного контента.

    OriginB переходит в режим «https-transitional». Это означает, что ресурс всё ещё не доступен по https://, но будет в будущем доступен через TLS с полными гарантиями, включая валидный сертификат. Это не должно ничего стоить OriginB, так как браузеру и пользователям ничего не известно про состояние безопасности этого ресурса.
    Теперь ресурсы OriginB доступны через «https-transitional». OriginA включает HTTPS. Браузер знает, что он может инициировать TLS соединение к OriginB и запросить ресурсы через традиционный http протокол. Если эта смена протокола не удастся, ресурс будет помечен как небезопасный и появится предупреждение о смешанном контенте. Если всё закончится успешно, все гарантии о безопасности OriginA заявляемые браузером будут истинны, не появятся предупреждения о смешанном контенте, несмотря на то, что файл был передан через http.
    После обновления OriginA OriginC также может обновиться. OriginB всё ещё зависим от OriginD, так что он ещё не может перейти на https, но включая «транзитный» режим он разрешает ресурсам A и B доступ к ресурсам через https.

    Как мы можем создать это состояние?

    Для разрешения циклической зависимости без создания документов со смешанным контентом нужно настроить фильтр, который возвращал бы 404 на все запросы, кроме тех, на которые можно вернуть Content-Type text/html. Довольно хорошее решение, исключая некоторые случаи, связанные с CORS. Из четырёх свойств нужных нам этот подход реализует три.
    Четвёртое свойство — возможность определить состояния своих зависимостей чтобы знать момент, когда можно включить полноценный HTTPS. Что если бы браузеры могли применять Content-Security-Policy-Report-Only с «upgrade-insecure-requests» для http документов?
    Пробуем подменить протокол
    В случае неудачи: Откат на http, сообщение администратору
    Возможно, что не понадобится делать ничего, кроме вышеуказанных шагов. Эта конфигурация, с «upgrade-insecure-requests», реализованная для A, B и C:

    iframe

    К сожалению простого перехода к отдаче html ресурсов через https недостаточно, это не работает с зависимостями HTML к HTML через iframe. Это довольно часто используется.

    Нужно реализовать возможность загрузки HTML ресурса подменяя протокол на TLS, но только на безопасной странице. Это не нарушит безопасность потому, что без подмены протокола контент уже был бы небезопасным, так что мы не создаём смешанный контент для пользователей OriginB.

    https-transitional при помощи ALPN и HTTP Alt-Svc

    ALPN позволяет клиенту общаться с сервером через TLS указывая другой протокол, который клиент хотел бы использовать.
    Давайте представим новый тип ALPN протокола: «https-transitional». Сервер, у которого клиент запрашивает данные таким образом понимает это как: «соедини меня с сервером через http, но через TLS, не через https». Как и описано в черновике HTTP Alt-Svc, должно произойти TLS соединение, сервер должен представить сертификат, подходящий к домену.
    Ресурс, открытый через «https-transitional», будет иметь следующие свойства:
    Ресурс не должен быть заблокирован как смешанный контент.
    Настройки документа, переданного через «https-transitional», не должны запрещать смешанный контент.
    Предыдущие свойства выполняются до тех пор, пока родительский фрейм документа не запрещает; в таком случае автоматически должен произойти upgrade-insecure-requests
    Upgrade-Insecure-Requests будет модифицирован следующим образом:
    В случае подмены протокола для зависимого ресурса подключаемся к https, добавляем новый «https-transitional» ALPN протокол как предпочтительный, в добавок к http/spdy/h2.
    Если сервер понимает «https-transitional», ответить по этому протоколу и доставить http ресурс через TLS.
    Если сервер не понимает «https-transitional» — ответить по https.
    Блокировка смешанного контента также должна быть модифицирована. Браузеры в данный момент не пытаются автоматически заменить http на https, так как нет гарантии, что обе схемы предоставляют одинаковый контент. Схема с «https-transitional» такую гарантию предоставляет. Сервет также может сообщать о доступности транзитного режима с помощью HTTP Alt-Svc заголовка.
    После загрузки документа в транзитном режиме браузер должен попытаться заменить все соединения, заблокированные как смешанный контент, как если бы upgrade-insecure-requests был включен, но также должен незаметно загрузить контент через https если предыдущая попытка закончится неудачно. Он также должен вывести ошибку в консоль.

    Диаграмма выше демонстрирует реализацию вышеописанных правил. Ресурсы, загруженные с OriginA, iframe которого указывает на OriginB никогда не будут содержать смешанного контента, так как OriginB поддерживает транзитный режим. Однако если ресурсы OriginB загружаются из документа, который блокирует смешанный контент и зависят от ресурсов, для которых замена протокола невозможна(например JS файл на OriginD), то такие запросы будут тихо заблокированы. Частичная поломка предпочтительнее полной. Ресурсы, загруженный напрямую от OriginB, которые зависят от тех же на OriginD не будут заблокированы, так как не требуется соблюдение принципа tranquility.

    Влияние на производительность

    Для https ресурсов данное предложение не должно создать никаких новых задержек по сравнению с использованием Upgrade-Insecure-Requests. Браузеры будут предпочитать TLS, так что не потребуется новых запросов для определения поддержки https-transitional.
    Единственное место, которое может потерять в производительности, это замена соединения из-за Alt-Svc заголовка. Браузер будет пытаться рекурсивно обновить все зависимые ресурсы, некоторые из которых могут быть недоступны через https, что может создать большие задержки. Также они могут это исправить помня, что TLS был недоступен для определённого источника определённое количество времени, либо же распараллелить запросы. Возможно, нужны некоторые эксперименты для определения лучшей стратегии.
    В какой-то момент все сайты захотят уйти от http. Загрузка через https никогда не откатывается до http, но вышепредложенного сценария недостаточно для защиты от хакеров, использующих атаки для снятия шифрования. Как мы можем перейти от транзитного веба к полностью безопасному, особенно если существование первого означает избегание необходимости изменения схемы запроса для каждой ссылки на сайте?
    Мы можем начать разрабатывать паттерны основываясь на HTTP Strict Transport Security, который был создан для решения проблем сайтов, желающих полностью отказаться от http и Alt-Svc заголовка.
    Первое, что администратор может сделать — установить Alt-Svc в infinite, что будет сигналом для браузеров не пытаться подключиться по http, использовать только https-transitional и https, всегда. После этого сайт может оставить поддержку http для устаревших клиентов, или совсем её отключить.
    Следующим шагом будет применение принципа tranquility для транзитного контента. Возможно, лучший способ сделать это — HTTP заголовок. Установка бита «tranquil» будет означать запрет смешанного контента. Это возможно также позволит данному ресурсу получить иконку замка, или вызвать подобные изменения в интерфейсе.
    Однажды, если распространение транзитного режима будет достаточным, браузеры смогут начать отказ от http. Возможно началом будет появление пункта в настройках, затем показ большого предупреждения. Множество сайтов скорее всего останутся в транзитном режиме на неограниченное время, но пользователи всё же будут получать преимущества от использования сайтом TLS.

Добавить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *