Как перевести http в https
Как перевести сайт целиком на постоянный HTTPS для всех
Шифруем всё подряд
Эра незашифрованного веба проходит, и это хорошо. В этой инструкции мы предполагаем, что на вашем сервере работает веб-сервер Nginx. И теперь мы сделаем так, чтобы все посетители сайта пользовались исключительно протоколом HTTPS. Кроме этого мы включим HSTS – это «HTTP Strict Transport Security», когда сайт не только поддерживает HTTPS, но и настаивает на его использовании.
Для этого есть множество способов, но я опишу метод под названием «HTTPS termination». Иначе говоря, мы поставим перед веб-сервером обратный прокси, который и будет обеспечивать HTTPS. Это получается проще и гибче, чем настраивать HTTPS только при помощи возможностей веб-сервера. Возможно, вам покажется контринтуитивным, что добавление ещё одного приложения в стек упростит вашу жизнь – но это действительно так.
Уточним, что данный рецепт подходит для серверов на базе Linux, на которых установлен Nginx.
То, что будет работать прежде всех остальных приложений в стопке – это HAProxy. Это в первую очередь приложение для балансировки – он умеет распределять приходящие запросы между разными физическими серверами. Много высоконагруженных сайтов используют его в этом качестве (тот же reddit), но в последней версии у него появилась возможность выполнять SSL termination. Он умеет устанавливать HTTPS-соединения от имени сервера.
Поэтому мы поставим HAProxy, скормим ему наши сертификаты SSL/TLS, поручим перенапрявлять все HTTP запросы на HTTPS, и покажем ему уже сам веб-сервер в качестве бэкенда.
Установка HAProxy
Порты 80 и 443 будут смотреть в интернет и получать HTTP и HTTPS трафик. Все HTTP запросы получат редирект 301 на тот же URL, но по HTTPS, и затем перенаправятся на бэкендовый веб-сервер (nginx) по чистому HTTP.
HAProxy package, включённый в поставку Ubuntu 14.04 LTS довольно старый, поэтому добавим репозиторий:
Затем обновим исходники и установим приложение:
Основные настройки лежат в /etc/haproxy/haproxy.cfg. Вот мои настройки:
Кстати, если вам понадобится подсветка синтаксиса конфига HAProxy для vim, её можно взять здесь. Разберём настройки подробнее.
Global
Оставляем первый кусок нетронутым. Это настройки логов, директория и права доступа.
Следующие части нужно поправить – там указано, где находится CA root и лежат сертификаты SSL/TLS. Возможно, нужно будет поменять ca-base и crt-base.
Строка ssl-default-bind-ciphers определяет, какие коды SSL/TLS будут применяться HAProxy при соединении с клиентом. Я использую рекомендованный список от Qualys/SSL Labs. Я также отредактировал строчку ssl-default-bind-options и запретил SSLv3 и TLS1.0, т.к. они дырявые. Последняя строка, tune.ssl.default-dh-param, сообщает программе о необходимости использовать не более 4096 бит в параметре Diffie-Hellman при обмене ключами DHE.
Defaults
Добавляем пару вещей — forwardfor и http-server-close. Поскольку мы используем приложение в качестве прокси, оно должно сообщать серверу IP-адреса, с которых идут запросы. Иначе это будет выглядеть, будто весь трафик идёт с HAProxy. Поэтому forwardfor сообщает, что программа работает как обратный прокси, и необходимо добавлять заголовок X-Forwarded For для сервера.
Настройка http-server-close нужна для быстродействия — HAProxy будет решать, закрывать ли соединение или использовать его повторно, при этом поддерживая более продвинутые вещи вроде WebSockets.
Certificates
Первая часть секции сообщает, какой трафик HAproxy должна обрабатывать и куда его отправлять.
Мы привязываем HAproxy к портам 80 и 443, она слушает HTTP на порту 80 и HTTPS на порту 443. Для HTTP мы скармливаем ей два разных сертификата. HAproxy использует Server Name Identification (SNI) чтобы привести хост входящего запроса в соответствие с нужным SSL/TLS сертификатом. У меня на сервере есть три сайта, они используют разные групповые сертификаты (*.bigdinosaur.org, *.chroniclesofgeorge.com и *.bigsaur.us) и HAProxy правильно выбирает нужный из них.
Убедитесь, что владельцем файла будет root:root, и права у него должны быть только на чтение:
От HTTP к HTTPS, и HSTS в качестве бонуса
Теперь определим ACL, список контроля доступа. В HAProxy это список вещей, удовлетворяющих определённому критерию:
Мы создали ACL по имени secure, который совпадает со всем, что идёт на TCP порт 443. Он нам скоро понадобится.
Следующая строка – та самая, где происходит перенаправление трафика с HTTP на HTTPS.
Это значит, что если входящий запрос не HTTPS, то надо отправить перенаправление 301 к тому же ресурсу, но по схеме HTTPS.
Это именно то HTTP Strict Transport Security – всем браузерам предписывается использование HTTPS:
Настройка добавляет нужную строку в заголовки. Браузер, распознающий этот заголовок, понимает, что сайт предпочитает работать по HTTPS, и это указание действительно в течение года (31,536,000 seconds). Директива preload сообщает Google-боту, что ваш сайт можно добавить в их список сайтов, поддерживающих HSTS.
HSTS – штука правильная. Шифрование должно быть всегда, и администраторам надо стремиться распространять его везде.
Кстати – необходимо учесть, чтобы все куки также включали атрибут secure, поскольку с точки зрения вашего веб-сервера всё происходит по обычному протоколу HTTP. Для этого используем директиву rsprep:
1
Обратите внимание на «if secure». Это значит, что меняются только куки, идущие по HTTPS (secure – это переменная, которую мы несколько линий назад определили). Вообще, всё должно работать через HTTPS, поэтому это в принципе необязательно – но можно и подстраховаться.
Последняя строка определяет, куда отправлять трафик. Это default_backend. Тут можно определять несколько серверов для распределения нагрузки и т.п. Но, поскольку у нас есть один бэкенд-сервер, то всё довольно просто.
back end
Поскольку у нас один бэкенд-сервер, эта секция коротка. HAProxy необходимо лишь добавить пару заголовков, чтобы сервер понял, что реальное общение происходит через HTTPS, даже если он видит только лишь HTTP:
Первая директива устанавливает заголовок, объясняющий, что клиент изначально пришёл на порт 443. Вторая усиливает первую, устанавливая X-Forwarded-Proto в HTTPS, если запрос шёл через HTTPS, чтобы веб-сервер понимал, что происходит и не создавал неправильных ответов.
Затем мы объясняем HAProxy, куда слать запросы – имя, IP и порт веб-сервера. У меня веб-сервер работал на отдельной машине, поэтому я пишу сюда другой IP и 80-й порт. Если у вас всё работает на одном компьютере, то пишите localhost и порт.
Статистика, если нужно
Последняя секция диктует HAProxy выдавать статусную страницу по заданному порту. Тут можно добавить basic auth, добавив stats auth username:password, или определить отличающийся URL.
Если вы используете директиву HSTS «includesubdomains», у вас может не получиться запросить статусную страницу по имени, поскольку веб-браузер попытается загрузить её HTTPS-версию, а HAProxy отдаёт только HTTP-версию. Это можно обойти, запрашивая страницу по IP вместе с портом (http://192.168.x.x:9999).
Подчищаем
Сохраните настройки, но пока не перезапускайте сервис HAProxy. Если у вас всё работает на одной машине, и nginx также слушает события на портах 80 и 443, нужно кое-что подправить.
Поскольку nginx больше не будет отдавать HTTPS-запросы, нужно убрать все упоминания HTTPS из всех файлов виртуальных хостов.
Вот и всё. Нужно только добавить в главный файл nginx.conf две строчки, чтобы убедиться, что nginx будет заменять ip-адреса согласно заголовку X-Forwarded-For, если запросы приходят от 127.0.0.1:
Это будет работать, если вы скомпилили nginx с опцией ngx_http_realip_module.
Перезапустите HAProxy (service haproxy restart) и она начнёт слушать запросы.
Проверка работы
Сделайте запрос к сайту через http. Если URL меняется на https и вы видите сайт – всё работает. Можно убедиться, что заголовок HSTS отправляется корректно:
Как правильно перейти на HTTPS
В 2014 году корпорация Google внесла изменения, благодаря которым у сайтов с протоколом HTTPS появился приоритет в поисковых запросах. Спустя три года алгоритмы ужесточились – без надлежащего сертификата веб-страницы вовсе стали отображаться с надписью «ненадежный». Вместе с этим Google выпустила ряд рекомендаций и правил, которые должны были помочь пользователям перейти на защищенный сертификат, однако у многих все равно возникли некоторые проблемы после переезда: посещаемость сайта заметно упала, страницы стали исчезать из топа и т.п.
В сегодняшней статье мы разберемся, что такое HTTPS-протокол, какие существуют SSL-сертификаты и как с их помощью правильно перевести сайт в защищенный режим.
HTTPS: что это такое и зачем на него переходить
По умолчанию все сайты начинают свой путь с HTTP-протокола передачи данных в интернете. Он использует технологию «клиент-сервер», работающую следующим образом: клиент инициирует соединение и отправляет запрос серверу, который в свою очередь ожидает соединения для получения запроса, выполняет определенные действия и отправляет обратно сообщение с результатом.
Во время передачи данных по HTTP устанавливается незащищенное соединение, поэтому злоумышленник может легко перехватить запросы: получить пароль пользователя, увидеть данные банковской карты и многое другое.
На смену HTTP пришел HTTPS — особое расширение протокола, включающее в себя настройки шифрования. Благодаря этому все платежи, покупки, пароли и прочие данные защищены, и добраться до них злоумышленнику практически невозможно. Также этот интернет-протокол позволяет повысить доверие пользователей, разместить рекламные баннеры в Google AdWords, получить приоритетное ранжирование в поисковых системах и многое другое.
Использование HTTPS сопровождается получением специального SSL-сертификата. Сертификаты разделяются на три вида:
Каждый из вышеупомянутых сертификатов обеспечивает шифрование трафика между сайтом и браузером.
Резюмируя, стоит сказать, что переадресация с HTTP на HTTPS — надежный способ обезопасить свой сайт от злоумышленников и обеспечить пользователям конфиденциальность. О том, как правильно перейти на защищенное соединение, поговорим далее.
Переходим на HTTPS
Перенос сайта на другой протокол выполняется в несколько этапов. Сперва нужно приобрести SSL-сертификат у хостинга (достаточно открыть нужный раздел в личном кабинете и заказать сертификат). Также нужно изменить все внутренние ссылки на относительные и установить автоматическую переадресацию сайта на защищенный протокол. Подробнее о том, как это быстро и правильно организовать, поговорим в нижеуказанной инструкции.
Шаг 1: Подготовка сайта
Перед выполнением редиректа с HTTP на HTTPS рекомендуется исправить некоторые моменты в строчках кода, чтобы избежать возможных ошибок. Первый — внутренние ссылки.
Чтобы избежать предупреждения, указанного выше, необходимо изменить все внутренние ссылки с абсолютных на относительные. Например, ссылку http://ssl.ru/testpage/ потребуется заменить на /testpage/. Также стоит внимательно проверить все ссылки на скрипты в коде страниц.
Второй момент — проверка медиаконтента, в который входят изображения, видеоклипы, презентации и прочее. Необходимо посмотреть, какой на страницах сайта используется контент и по какому протоколу он запрашивается. Если используется HTTP, то рекомендуется загрузить все файлы на сервер и установить относительные ссылки. В противном случае указывайте только проверенные сайты: YouTube, Facebook, VK и так далее.
Теперь можно переходить к подключению SSL.
Шаг 2: Установка SSL-сертификата
Как мы уже выяснили, чтобы перейти на HTTPS, требуется установка специального сертификата. Для начала его нужно заказать — сделать это проще всего в личном кабинете хостинга, обычно такие услуги предоставляются всем пользователям. Алгоритм везде одинаковый, поэтому рассмотрим, как эта процедура выполняется на Timeweb.
После установки также рекомендуется убедиться, что сайт работает на обоих протоколах. Затем нужно сделать переадресацию с HTTP на HTTPS. Зачем это нужно, расскажем уже в следующем разделе.
Шаг 3: Настройка редиректа на HTTPS
Также мы можем сделать редирект с HTTP через административную панель CMS системы. В OpenCart для этого нужно открыть файл config.php и прописать в него следующее:
В WordPress изменить wp-config.php:
Для получения подробной информации о редиректах на других CMS обратитесь к их документации.
Ш аг 4: Настройка для поисковых систем
Если ваш сайт индексируется Google, Яндекс или другими поисковиками, то после перехода на HTTPS необходимо им об этом сообщить. В частности, нужно:
Готово! На этом переход с HTTP на HTTPS завершен. Надеюсь, что у вас не возникло сложностей. Спасибо за внимание!
Правильный переезд сайта с http на https без потери позиций и трафика
Вчера решил, что хватит это терпеть и пора перевести свой сайт с http на https. По случаю решил описать весь процесс, как я его делаю. Честно говоря преследую этим еще одну цель — когда меня в очередной раз попросят помочь переехать на https, я просто дам ссылку на подробное руководство.
HTTP, HTTP/2, HTTPS, SSL — о чем речь?
Hypertext Transfer Protocol (HTTP) — это основном протокол связи, который используется на любом сайте для установки соединения.
HTTP/2 — более современный протокол, в котором добавлены увеличивающие производительность и безопасность.
HTTPS — расширение протокола HTTP, которое поддерживает шифрование.
Secure Sockets Layer (SSL) — криптографический протокол для безопасной связи.
Переход на https — зачем мне это?
Я бы выделил 4 причины:
Ну а теперь перейдем к пошаговому плану по переходу с http на защищенный протокол https.
Шаг 1: Подготовка сайта
Многих сложностей может не быть вообще, если изначально за сайтом следили и делали все чисто и без костылей.
Бэкап
Любое вмешательство в жизнь сайта (если это не простые действия с контентом или вы не самоуверенный программист) начинается с бэкапа, т.к. в случае появления проблем — вы быстро восстанавливаете данные и программист уходит все делать на своем серваке.
Относительные ссылки
Когда на сайте абсолютные ссылки вида http://romanus.ru/page-name — это может быть проблемой, т.к. их нужно:
Я бы выбирал 1 вариант, т.к. он более гибкий и пригодится не только в решении текущей задачи. Однако и там есть свои минусы, но это не тема данной статьи.
Уверен, на любом сайте вы найдете волшебную таблетку (пример замены домена в статьях):
Пример замены домена через SQL-запрос: кто-то его проверял?
Почему люди везде это пишут — хз, видимо никто не проверял работоспособность т.к. этот вариант просто не работает. SQL запрос не может заменить домен в ячейке, содержащей целый текст, т.к. это просто замена в лоб (как в Excel). Т.е. вы не можете заменить ячейку, если она не равняется вашему тексту (читай, ячейка = текст и ничего более).
Но у нас же в ячейках текст статей в html формате.
Даю 2 рабочих вариант:
Все пути к файлам и изображениям также должны быть изменены.
Адрес сайта
В CMS нужно изменить адрес вашего сайта на корректный, в WordPress это делается так:
Замена домена в админке WordPress
Внешние скрипты
Все внешние скрипты должны подключаться строго через https, т.к. в противном случае у вас будет смешанный протокол.
Чтобы убедиться — смотрите страницы через режим исходного кода и проходитесь поиском или любой краулер аля Screaming Frog, Netpeak и т.д.
Robots.txt и Sitemap.xml
В robots.txt чаще всего не нужно никаких изменений вносить (раньше нужно было добавить директиву для Яндекса: host: https://romanus.ru — но теперь это уже не нужно), кроме замены пути для sitemap.xml.
В самой карте сайта нужно изменить все ссылки. Если она у вас выводится автоматом + все ссылки в базе данных вы изменили — чаще всего никаких доработок не понадобится. Но лучше перепроверить:
В sitemap.xml не должно быть ссылок на незащищенный протокол
Шаг 2: Покупка SSL сертификата
Прежде чем приобретать SSL нам нужно определиться с нашими потребностями.
Типы ssl
Все сертификаты выдаются для 1 домена:
Если у вас много поддоменов и вы хотите их перевести на https — стоит обратить внимание на сертификаты с пометкой Wildcard (количество поддоменов неограниченно).
Активация https для домена
После того, как вы решили какой тип сертификата вам нужен, купили его (свои сертификаты я покупал на gogetssl.com, а для блога решил потестить бесплатный Let’s Encrypt) и не забыли сохранить все ключи, которые вам были даны — самое время привязать все к вашему домену.
После активации домена он должен пройти валидацию:
Валидация домена пройдена
Все, теперь можно переходить к следующему шагу.
Бесплатный SSL от Let’s Encrypt
Let’s Ecnrypt — это некоммерческий центр сертификации. Вы можете без проблем взять их бесплатный сертификат, если вам важно само наличие https.
Яндекс и Google (а также браузеры) нормально относятся к нему, т.е. никаких трудностей у вас не будет.
У хостеров бесплатный сертификат подключается за 1 минуту
На многих хостингах можно буквально за минуту подключить бесплатный SSL.
Установка SSL на примере FastVPS
У вас есть ключи и все что вам нужно сделать — это добавить их в панели своего хостинга.
Просто вставить в поля свои ключи от центра сертификации
Шаг 3: Оповещаем поисковые системы
После покупки и установки сертификата на подготовленный сайт мы можем оповестить о наших действиях поисковые системы Яндекс и Google в их кабинетах.
Яндекс.Вебмастер
По сути в Яндексе переезд на https осуществляется 1 галочкой + перенести свежие данные.
Google Search Console
Самое страшное, что может произойти во время переезда сайта на https в Гугл — забыть перенести Disavow файл, потому краткий чек-лист:
Шаг 4: 301-редирект с http на https
Здесь все сложно и просто одновременно. Подробная статья о 301 редиректах с примерами, рекомендую изучить.
Скорее всего вам подойдет один из вариантов:
Если варианты не подошли — дергаем программиста с просьбой “склеить 301 редиректом все страницы на http со страницами на https” соответственно.
Шаг 5: Ожидание переиндексации
Если вы нигде не накосячили то склейка происходит довольно быстро: 1-2 недели в Google и 2-4 недели в Яндексе.
Вроде все страхи описал.
Поздравляю, теперь у вас рабочий сайт на https, проверить можно на https://www.ssllabs.com/ssltest/:
Проверка корректности SSL
13 популярных ошибок при переходе сайта на https
Пишу самые популярные моменты, которые знаю из своего опыта или опыта коллег:
А с какими косяками вы сталкивались?
Ответы на несколько вопросов
Напоследок несколько популярных вопросов, которые могут всплыть:
Почему сам тянул с переездом на https?
Я все никак не могу взяться за свои проекты (это видно по дате последних постов и съемки видео на канале), ну и решающим моментом стало оповещение Яндекса о том, что уже пора бы.
Могу ли я потерять посещаемость?
Да. Любые действия с сайтом в теории могут негативно повлиять на трафик. Но чаще проблем не бывает, если нигде не напортачил.
После перехода на https упали позиции, что делать?
Это тоже нормально. От момента переезда я обычно засекаю 3-4 недели (примерно) и не обращаю внимания на колебания. По истечении этого срока уже должна произойти склейка (в вебмастере зеркала будут слеплены вместе) и тогда можно делать какие-то выводы. Чаще всего все восстанавливается и иногда даже с плюсом.
Я хочу ЧПУ и SSL — в какой последовательности делать
Очень скользкий вопрос, сродни «Какой рукой открывать дверь: правой или левой?». Я опасный и потому делаю все сразу за 1 раз :). Проблем вроде не было, но склейка была дольше.
Понравился пост? Сделай репост и подпишись!
Рекомендую к прочтению
Биржа ссылок Sape. Как работать с Sape новичку
Яндекс острова. Что это и что нас ждет? Польза или вред?
Как перевести сайт на HTTPS
В этой статье мы расскажем, как перевести сайт на HTTPS.
Cайт без HTTPS ранжируется намного ниже в поисковых системах, в отличие от сайтов, которые используют защищённое соединение. Пользователи больше доверяют сайтам с HTTPS, что может увеличить посещаемость веб-ресурса. Подробнее о преимуществах HTTPS читайте в статье.
Шаг 1. Выбор и покупка SSL-сертификата
Перед переездом сайта на новый протокол HTTPS выберите SSL-сертификат в зависимости от ваших целей. Сертификаты различаются по уровню защиты сайта. Существует три типа сертификатов, которые вы можете заказать в REG.RU перед тем, как установить HTTPS на сайт:
SSL-сертификат с проверкой домена (Domain Validation) — например, DomainSSL (в REG.RU его можно заказать бесплатно) или AlphaSSL. Сертификаты этого типа подойдут физическим и юридическим лицам. Они подтверждают принадлежность домена заказчику. При этом пользователь сайта понимает, что оказался на безопасном сайте. Такой сертификат не содержит информации о владельце, поэтому сайт не считается безопасным для оказания коммерческих услуг.
SSL-сертификат с проверкой организации (Organization Validation) — например, OrganizationSSL. Этот сертификат подходит только юридическим лицам и ИП. Он подтверждает, что домен принадлежит проверенной организации. Центр авторизации проверяет юридическое и физическое существование компании. Такой сертификат подойдёт, если у вас, например, интернет-магазин.
SSL-сертификат с расширенной проверкой организации (Extended Validation) — например, ExtendedSSL. Это самый надёжный SSL-certificate для крупных организаций. При выдаче Центр авторизации проводит расширенную проверку юридического лица. Если у вас установлен такой сертификат, в адресной строке браузера рядом с значком замочка будет выделено зелёным цветом название вашей организации.
Прочитать подробнее о каждом сертификате вы можете в статье: Виды SSL-сертификатов.
Также для SSL-сертификата при заказе можно выбрать поддержку Wildcard — это позволит вам защитить не только домен, но и поддомены. Дополнительно с сертификатом можно установить печать доверия SiteSeal, кликнув на которую пользователь может посмотреть данные об организации.
После выбора сертификата закажите его по инструкции:
Защита данных c SSL
Установите SSL-сертификат, и ваш сайт будет работать по безопасному соединению HTTPS
Мигрируем на HTTPS
В переводе этого документа описываются шаги, которые необходимо предпринять для перевода вашего сайта с HTTP на HTTPS. Шаги можно выполнять с любой скоростью – либо всё за день, либо один шаг за месяц. Главное, делать это последовательно.
Каждый шаг улучшает ваш сервер и важен сам по себе. Однако, сделать их все – обязательно для того, чтобы гарантировать безопасность вашим посетителям.
Для кого предназначена эта инструкция?
Администраторы, разработчики и их менеджеры – те, кто обслуживает сайты, в данный момент использующие только HTTP-соединение. При этом они желают мигрировать, или хотя бы поддерживать, HTTPS.
1: Получение и установка сертификатов
Если вы ещё не получили сертификаты – необходимо выбрать поставщика, и купить сертификат. Сейчас есть пара возможностей даже получить сертификаты бесплатно – например, их выдаёт контора RapidSSL. Кроме того, в 2015 году Mozilla обещают сделать бесплатную выдачу сертификатов.
Скопируйте полученные сертификаты на ваши фронтенд-сервера куда-нибудь в /etc/ssl (Linux / Unix) или в приемлемое место для IIS (Windows).
2: Включение HTTPS на сервере
Здесь надо определиться:
— либо использовать хостинг по IP, когда у каждого хоста свой IP
— либо отказаться от поддержки пользователей, которые используют IE на Windows XP или Android с версией менее 2.3
На большинстве сайтов настроен виртуальный хостинг, который работает с доменными именами (name-based) – это экономит IP-адреса и вообще более удобно. Проблема в том, что IE и древний Android не понимают Server Name Indication (SNI), а это критично для работы HTTPS при name-based хостинге.
Когда-нибудь все эти клиенты вымрут. Вы можете отслеживать количество таких клиентов и решить, нужно их поддерживать или нет.
Далее настройте поддержку сертификатов, которые вы получили, в вашем веб-сервере. Конфигурацию сервера можно создать через Mozilla configuration generator или SSLMate.
Если у вас много хостов и поддоменов – кажды из них потребует установки подходящего сертификата. Для поддоменов лучше использовать сертификаты с маской типа *.domain.ru
В идеале, вам необходимо переадресовывать все запросы к HTTP на HTTPS и использовать Strict Transport Security (см. шаги 4 и 5)
После этого проверьте работу сайта с новыми настройками при помощи инструмента Qualys SSL Server Test. Добейтесь того, чтобы сайт заслуживал оценки A или A+.
3: Сделайте все внутренние ссылки относительными
Теперь, когда ваш сайт работает и на HTTP и на HTTPS, вам нужно добиться его работы вне зависимости от протокола. Может возникнуть проблема смешанных протоколов – когда на странице, которую грузят через HTTPS, указаны ресурсы, доступные по HTTP. В этом случае браузер предупредит пользователя, что защита, предоставляемая HTTPS, перестала работать на 100%.
По умолчанию многие браузеры вообще не будут загружать смешанный контент. Если это будут скрипты или стили, страница перестанет работать. К слову, включать в страницу, загруженную по HTTP, контент, доступный через HTTPS, можно без проблем.
Проблема эта решается заменой полных линков на относительные. Вместо такого:
надо сделать такое:
Все линки должны быть относительными, и чем относительнее, тем лучше. По возможности надо убрать протокол (//example.com) или домен (/jquery.js).
Лучше делать это при помощи скриптов, и не забыть про контент, который может находиться в базах данных, скриптах, стилях, правилах редиректа, тегах link. Проверить сайт на наличие смешанного контента можно скриптом от Bram van Damme.
Естественно, в ссылках на другие сайты протоколы менять не нужно.
Если в вашем сайте используются скрипты и другие ресурсы от третьих лиц, например CDN, jquery.com, у вас есть 2 варианта:
— также использовать URL без указания протокола
— скопируйте эти ресурсы к себе на сервер. Это в любом случае надёжнее
4: Переадресация с HTTP на HTTPS
на ваших страницах. Это поможет поисковым системам лучше ориентироваться у вас.
Большинство веб-серверов предлагают простые решения для редиректа. Инструкции для Apache и для nginx. Используйте код 301 (Moved Permanently).
5: Включите Strict Transport Security и Secure Cookies
Убедитесь, что ваши TLS-настройки реально работают – например, сертификат не просрочен. На этом шаге любая ошибка будет блокировать доступ к сайту.
Включите HTTP Strict Transport Security посредством заголовка Strict-Transport-Security. На этой странице есть ссылки на инструкции для разных серверов.
Примечание: max-age измеряется в секундах. Начните с небольших величин и по мере роста уверенности в работе сайта увеличивайте их.
Для того, чтобы клиенты всегда отправляли куки по защищённому каналу, включите флаг Secure для куков. На этой странице есть инструкция для этого.
Проблемы с миграцией
Позиция в поисковой выдаче
Google ставит наличие HTTPS в плюс сайтам. У Google также есть инструкция по тому как переходить на безопасный режим, не теряя позиций в поиске. Также такие инструкции есть у Bing.
Когда сервер работает нормально, траты на TLS обычно малы. По поводу их оптимизации читайте High Performance Browser Networking by Ilya Grigorik и Ivan Ristic’s OpenSSL Cookbook и Bulletproof SSL And TLS.
В некоторых случаях TLS может увеличить быстродействие – это справедливо в случае использования HTTP/2.
Клиентские программы не отправляют Referer, когда пользователи переходят по ссылкам с вашего HTTPS-сайта на другие HTTP-сайты. Если вам это не нравится:
— другие сайты тоже должны мигрировать на HTTPS. Предложите им эту инструкцию. Если они дойдут хотя бы до 2 шага, то ситуация выправится
— вы можете использовать новый стандарт Referrer Policy, решающий проблемы с этими заголовками
Так как поисковики мигрируют на HTTPS, то вы скорее всего получите больше заголовков Referer, когда сами перейдёте на HTTPS.
Клиент НЕ ДОЛЖЕН включать заголовок Referer в небезопасный HTTP-запрос, если ссылающаяся страница получена по безопасному протоколу.
Если на вашем сайте крутятся объявления рекламной сети, может возникнуть проблема –iframe с HTTP не будут работать на странице с HTTPS. Пока все рекламодатели не перейдут на HTTPS, операторы не могут перейти на HTTPS, не теряя рекламных доходов. Но пока операторы не мигрируют на HTTPS, у рекламодателей нет мотивации для миграции.
Рекламодатели должны хотя бы предлагать вариант своих сервисов с поддержкой HTTPS (достаточно дойти до 2 шага этой инструкции). Многие так и делают. Вам, возможно, придётся отложить 4-й шаг до тех пор, пока большинство из них не станут нормально поддерживать этот протокол.