Https сайты: Как перевести сайт с HTTP на HTTPS | Дропшиппинг

Содержание

Как перевести сайт с HTTP на HTTPS

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

HTTPS — Что это такое ?
Почему стоит перейти на HTTPS ?
Как исправить все ссылки с http на https ?
Заменить абсолютные ссылки на относительные
Проверить ссылки скриптов и сторонних библиотек
Поправить ссылки в атрибутах rel=«canonical» и rel=«alternate»
Обновить ссылки на внешние ресурсы
Проверить страницы на ошибки Mixed Content
Перепроверить sitemap.xml и robots.txt
Поправить ссылки на сайт в социальных сетях и других внешних источниках
Добавить сайт в поисковые системы по HTTPS

HTTPS — Что это такое ?

HTTP (HyperText Transfer Protocol) — «протокол передачи гипертекста». В наше время повсеместно используется для получения информации с веб-сайтов. Все сайты сразу работают на HTTP. Когда пользователь вводит личную информацию на сайте, браузер в открытом виде передает ее на сервер. Этим и пользуются мошенники, перехватывая личные данные.

HTTPS (HyperText Transfer Protocol Secure) — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. В этом случае личная информация передается уже не в открытом виде, а в зашифрованном. Принципом работы этого протокола является обмен ключами шифрования. Но для этого нужно, чтобы владелец сайта получил и установил SSL-сертификат на сайт.

Купить SSL сертификат

SSL-сертификат — сертификат электронной подписи, содержащий открытый ключ и информацию о владельце, подписанный выдавшим его Центром сертификации и подтверждающий принадлежность владельцу.

Сервер, прежде чем ответить на запрос от браузера, предъявляет ключ шифрования — SSL-сертификат, браузер проверяет его подлинность в Центре сертификации, и если все в порядке, то браузер и сервер «доверяют» друг другу и «договариваются» о разовом шифре для защиты передаваемых данных. Так происходит при каждой сессии.

Почему стоит перейти на HTTPS ?

Преимущества использования SSL сертификата:

Повышение безопасности при обмене данными с пользователем. Использование HTTPS позволяет защитить данные от перехвата злоумышленниками и третьими лицами.
Повышение уровня доверия у пользователей (посетителей) вашего сайта. Пользователи обращают внимание на наличие HTTPS при оплате заказов в интернете и передаче персональной информации.
Сохранение / повышение конверсии. Учитывая, что сейчас в сети интернет лидирующий браузер Google Chrome, он напрямую помечает страницы, которые собирают персональную информацию (пароли, данные оплаты, формы обратной связи или формы авторизации и другие поля где вводится информация) как небезопасные — конверсия таких страниц неизбежно падает.
Наличие HTTPS как фактор ранжирования. Google — напрямую заявляет, что они учитывают наличие SSL-сертификата у сайта, как один из факторов ранжирования. В Яндексе наличие HTTPS-версии также учитывается с 2011 года в составе группы коммерческих факторов ранжирования, которые используются для упорядочивания выдачи по коммерческим запросам.

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

Как исправить все ссылки с http на https ?

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

Заменить абсолютные ссылки на относительные

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

Перейдите в замена участков кода в поле «Что» пропишите:

http://ваш-сайт.ру/

в поле «На» вставьте ссылку:

https://ваш-сайт. ру/

В блоке «Заменять» вам нужно отметить пункты:

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

Ниже в блоке «В каких модулях», ничего не отключать, должны быть отмечены все модули и нажмите кнопку «Сохранить«.

Так же можно заменить и по другому, можно по всему шаблону заменить ссылки на главную сайта с абсолютной:

http://ваш-сайт.ру/

на относительную:

Все верно, ссылку на главную заменяем лишь на слэш.

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

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

Важно! Если вы в материалах сайта (новостях, блоге, статьях или других модулях) использовали ссылки на изображения с протоколом http, вам придется такие материалы по отдельности редактировать вручную и обновлять ссылки прописывая протокол https или делая относительный адрес к фото.

Подробнее о том, что такое абсолютные и относительные ссылки: http://htmlbook.ru/samhtml/ssylki/absolyutnye-i-otnositelnye-ssylki

Важно! Вместо примера сайта ваш-сайт.ру вы должны указать ваш адрес сайта, не наш пример.

Проверить ссылки скриптов и сторонних библиотек

Это также лучше было бы сделать еще на этапе подготовки. Что в данной ситуации требуется от вас, вам нужно проверить в Панели управления сайтом с раздела Дизайн — Управление дизайном /panel/?a=tmpl все активные модули и глобальные блоки (их код).

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

Проверить напрямую таблицу стилей CSS в которой могут быть прописаны ссылки на изображения с протоколом http, нужно заменить на https или прописать относительные ссылки на файлы изображений.

Примечание! Заменять ли в шаблонах ссылки на скрипты, файлы стилей и изображения с протоколом http на https, решение принимать исключительно вам, стоит так же помнить, что вы можете указать относительные адреса.

Поправить ссылки в атрибутах rel=«canonical» и rel=«alternate»

Эти данные прописываются в коде страницы, и ведут соответственно на канонические и альтернативные страницы (на языковые версии страницы, например).

Проверьте шаблоны страниц:

Страницы сайта;
Страница материалов категории;
Страница материалов раздела;
Cтраницы материала и комментариев;
Страница товара.

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

Примечание! Если вы на сайте оплачиваете тариф Оптимальный либо выше и у вас в Seo-модуле в «Премиум настройках» активен пункт «Использовать атрибут rel=»canonical» для материалов«, вам ссылки вручную исправлять не придется, система автоматически сформирует корректную ссылку при переходе на HTTPS.

Обновить ссылки на внешние ресурсы

Уже очень много сайтов перешли на https, так что перепроверьте, чтобы с вашего сайта не было устаревших исходящих ссылок на сайты с http.

Проверить страницы на ошибки смешанного содержания

Если где-то на страницах (в перелинковке, контенте, кнопках и т.п.) будет указана ссылка на http, то будет выдаваться ошибка «Смешанное содержание».

Чтобы найти такие ошибки, вам достаточно на странице где некорректно работает SSL после подключения, зайти в просмотр кода страницы (кликнуть правой кнопкой мышки на странице → посмотреть код → открыть вкладку Безопасность) и посмотреть, нет ли там сообщения об ошибке Mixed Content где вы найдете ссылку на изображение или скрипт с протоколом http, далее проверяем что это за файл и исправляем.

Примечание! Так же, после подключения сертификата вам нужно будет выполнить дополнительную настройку, а именно перейти в Панель управления → Настройки → Основные → URL адрес вашего сайта.

Проверьте в данном поле, чтобы адрес сайта был с https, если будет с http, оператор $HOME_PAGE_LINK$ будет неправильно формировать ссылку на главную сайта из-за чего могут быть ошибки Mixed Content.

Перепроверить sitemap.xml и robots.txt

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

То есть, после перехода на SSL ваш сайт работает по HTTPS протоколу, вам нужно в файловом менеджере найти файл robots.txt напротив которого нажмите иконку карандашика, найдите прямые ссылки на карту сайта подобно:

Sitemap: http://site.ucoz.ru/sitemap.xml
Sitemap: http://site.ucoz.ru/sitemap-forum.xml
Sitemap: http://site.ucoz.ru/sitemap-shop.xml

вам нужно в этих ссылках исправить протокол http на https.

Важно! После подключения SSL сертификата, чтобы в картах сайта обновились ссылки на материалы с http на https, нам нужно в файловом менеджере удалить старые файлы на карты сайта, которые были на фтп до подключения сертификата. После удаления и повторного перехода по прямой ссылке на карту сайта, файл автоматически сгенерируется новый.

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

Поправить ссылки на сайт в социальных сетях и других внешних источниках.

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

Добавить сайта в поисковые системы по HTTPS

После того как вы выполнили переход на HTTPS, для сайт куплен SSL сертификат и сайт стабильно работает по https, вам нужно добавить сайт как в Google так и Яндекс по протоколу https.

Добавляем сайт в Яндекс Вебмастер
Добавляем сайт в Google Вебмастер

Что важно при переходе на HTTPS в поисковых системах, так это то, что вам нельзя удалять старый сайт с вебмастера который вы ранее добавляли еще до перехода на SSL.

После того как вы добавите дополнительно сайт по HTTPS в вебмастера Google и Яндекс, вам нужно перейти в Яндекс Вебмастер, найти старый сайт без протокола HTTPS, перейти в раздел «Индексирование» — «Переезд сайта«, далее нужно отметить пункт «Добавить HTTPS» и нажмите кнопку «Сохранить«.

Вот так вы сообщите Яндекс Вебмастеру, что нужно выполнить смену зеркала для сайта с HTTP на HTTPS. На новое зеркало будет передан ИКС и все внешние ссылки. Обычно процесс смены зеркала для сайта занимает не меньше 2-х недель, нужно набраться терпения и ожидать.

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

Стоит отметить дополнительно, что для Google Webmaster такого инструмента по смене зеркала как у Яндекса нет, Google все выполняет автоматически и вам ничего дополнительно выполнять в гугл вебмастере не придется.

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

Если за этим не следить и пропустить дату окончания срока регистрации сертификата, зеркала в Яндекс вебмастере расклеятся и сайт снова начнет индексироваться по протоколу HTTP и соответственно будут потери по посещаемости.

Переход на HTTPS-протокол: суть, инструкции и советы

Содержание статьи

1 Нужно ли переходить на https?
2 В чем разница между http и https: ssl-сертификат
3 Как перенести сайт с http на https?
4 Push-уведомления и https-протокол

О важности перехода на https-протокол говорят давно. Но если раньше этот вопрос был критичным для отдельных сфер бизнеса (например, платежных сервисов), то сегодня он распространяется на все большее количество веб-ресурсов. Связано это с ужесточением требований к безопасности в сети, о которых мы сегодня поговорим детально. Также в этой статье мы разберемся, как сделать переход с http на https безболезненным и быстрым, рассмотрим все нюансы и детали этой процедуры.

Содержание:

Почему нужно переходить на https-соединение?
Что такое ssl-сертификат: отличия между http и https
Как перейти с http на https-протокол?
Перенос базы подписчиков

Нужно ли переходить на https?

С 25 мая 2018 года в силу вступает регламент GDPR, который регулирует сбор и обработку данных пользователей из Евросоюза (читайте о новых правилах обработки персональных данных GDPR). Один из основных принципов регламента – конфиденциальность и целостность данных, которые пользователь передает веб-сайту. А это означает, что ресурс, который предоставляет услуги любого характера гражданам ЕС, обязан приложить должные усилия для соблюдения повышенных мер безопасности на своей площадке. В частности, такие веб-сайты должны использовать защищенное соединение для передачи данных. Поскольку сфера применения новых правил достаточно широкая, наверняка каждый пользователь, даже не из стран ЕС, получил уведомления от разных сайтов об изменении политики конфиденциальности. Если учитывать, что любой сайт, который предлагает подписку на новости с помощью, например, email или web push-уведомлений, уже гипотетически может подпадать под действие новых правил, становится понятно, что масштабы реноваций в области защиты данных очень существенные.

Что такое web push уведомления

Но даже если веб-ресурс рассчитан исключительно на внутренний рынок Украины, переход на https – это только вопрос времени. В Google не единожды обращали внимание на важность безопасности сайта.

TIP

С 2014 года наличие или отсутствие https-протокола стало одним из факторов ранжирования. Постепенно количество запросов, для которых был применен данный фактор, увеличивалось. Сегодня, согласно статистическим данным, подавляющее число сайтов в ТОП-5 выдачи Google по разным категориям запросов – это https-сайты. К тому же, с июля 2018 в новой версии Chrome-браузера для сайтов без ssl-сертификата будет установлен маркер «не безопасно» (“not secure”) в адресной строке. Эта мера вводится для того, чтобы пользователи избегали незащищенных сайтов, а веб-мастера переходили на https-соединение.

Почему же до сих пор существует большое количество http-сайтов? Связано это либо с качеством веб-ресурса (к примеру, сайты, не рассчитанные на развитие), либо с опаской владельцев приступить к изменениям.

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

В чем разница между http и https: ssl-сертификат

Http, или HyperText Transfer Protocol – это протокол передачи данных в сети Интернет между веб-ресурсом и сервером. С его помощью пользовательские запросы (через браузер) передаются на сервер, а сервер формирует ответы, которые снова возвращает браузеру (клиенту). Однако обмен данными здесь происходит в незашифрованном виде, что может привести к перехвату информации третьей стороной. Так, к примеру, платежные данные, которые введены на сайте с http-протоколом, во время их передачи серверу могут попасть к злоумышленникам.

Для того, чтобы этого не произошло было создано расширение http-протокола под названием HTTPS (HyperText Transfer Protocol Secure), или «безопасный протокол передачи гипертекста». Расширенный протокол HTTPS позволяет передавать информацию в зашифрованном виде так, чтобы предотвратить считывание данных и некоторые виды атак.

Как можно расширить базовый http-протокол до https? В этом поможет ssl-сертификат.

SSL-сертификат – это технология защиты данных, которая работает на основе ключей шифрования. Это своеобразный фильтр, который помещается между протоколом клиента (браузера) и сервером. Так информация, которая передается от пользователя при посещении веб-ресурса (просмотренные страницы, логины, пароли) шифруется и не может быть прочитана посторонними. При каждом новом посещении https-сайта формируется защищенное соединение между клиентом и сервером.

Рассмотрим, как перейти на https-протокол и настроить его.

Как перенести сайт с http на https?

Перед тем, как начинать переход на https, важно проделать подготовительные процедуры на сайте, ведь, по сути, это смена его адреса (url). Соответственно, потребуется изменить адреса внутренних ссылок на сайте с абсолютных (например, http://site.com/articles) на относительные (//site.com/articles). Когда вы убедитесь в том, что контент вашего веб-ресурса (внутренние ссылки, картинки) открываются и отображаются корректно вне зависимости от его протокола, можно приступать к покупке ssl-сертификата.

Мы задали несколько важных вопросов специалистам компании ssl.com.ua, которая занимается продажей ssl-сертификатов в Украине и странах СНГ.

Какие предварительные настройки нужно провести на сайте перед установкой ssl-сертификата?

После установки сертификата сайт начнет работать по протоколу https, потому перед установкой нужно проверить ссылки:

поменять все ссылки внутри сайта на ссылки без http. Ссылку http://docs.google.com нужно поменять на //docs.google.com;
убедиться, что весь контент загружается не по http-протоколу. Ссылку на изображения вида http://domain.com/image.png нужно поменять на //com/image.png;
проверить, чтобы все сторонние модули подгружались не по http, а по https.

Как выбрать ssl-сертификат? Кто их предоставляет? В чем отличие компаний?

TIP

Выбор сертификата зависит от двух вещей:

от того, какие данные вы собираете: только имена и электронную почту, или принимаете оплату;
чем занимается компания: блог с формой подписки, интернет-магазин или банк.

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

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

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

Если на сайте много поддоменов, лучше взять Wildcard сертификат, он защищает все поддомены первого уровня: blog.domain.com и mail.domain.com. Для защиты сразу нескольких доменов можно приобрести Multi-Domain SSL-сертификат. Часто это выгоднее, чем покупать по одному сертификату для каждого домена.

Все сертификаты выдают специальные компании — центры сертификации.

Основное различие между центрами сертификации – в цене и количестве браузеров, которое поддерживает их корневой сертификат. Если в браузере пользователя нет сертификата этого центра, то посетитель получит предупреждение при входе на сайт. Большие центры выдают сертификаты, которые официально признаны во всем мире и всегда распознаются веб-браузерами пользователей. Среди больших центров: Comodo, GeoTrust, Thawte, Symantec, VeriSign. Их корневые сертификаты знают все популярные браузеры.

Есть ли бесплатные сертификаты и можно ли их использовать?

Бесплатные сертификаты существуют и их можно использовать, но у них есть свои минусы:

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

4. Как установить сертификат на сайте: основные этапы

Сначала сертификат нужно выпустить. Условия выпуска отличаются в зависимости от типа сертификата. Например, при выпуске сертификата с проверкой домена нужно:

выполнить CSR-запрос;
пройти проверку владения доменным именем;
для OV и EV сертификатов нужно пройти проверку компании: отправить центру документы для выпуска такого сертификата.

После выпуска сертификат нужно установить на сайт. Установка зависит от хостинга, на котором размещается сайт.

TIP

Для установки сертификата нужны:

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

Как настроить правильную работу сайта после перехода на https-протокол?

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

Чтобы быстрее пережить переход сайта на новый протокол, нужно заново добавить сайт в панели вебмастеров Google и обновить все настройки: перенаправление, геотаргетинг, карту сайта.

Push-уведомления и https-протокол

Кроме всех вышеописанных преимуществ https-протокола, есть еще один важный плюс: новые технологии и разработки, которые поддерживаются такими гигантами, как Google, доступны именно для защищенных сайтов. Так, например, обстоят дела с push-уведомлениями. Эта технология поддерживается только для https-сайтов. Потому, чтобы установить push-сервис на сайте с http-протоколом, требуются дополнительные манипуляции, и фактически подписка пользователей на уведомления происходит через субдомен на https. То есть, первое предложение о подписке посетитель видит на странице сайта (в сервисном нативном или дизайнерском окне подписке), а второе – во всплывающем окне субдомена. Такой алгоритм подписки снижает конверсию в 2-3 раза по сравнению с интенсивностью подписки на https-сайтах.

Как же быть, если вы использовали пуш-уведомления на http-сайте, но решили перейти на безопасное соединение? После перехода с http на новый url (с https) базу подписчиков на «пуши» придется собирать заново. Но специалисты Gravitec.net продумали варианты выхода из этой ситуации. Читайте подробнее о том, как перенести базу подписчиков при смене протокола сайта.

Зарегистрироваться и сделать рассылку

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

Предыдущая записьСледующая запись

Стандарт только для HTTPS — Стандарт только для HTTPS

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

Этот сайт содержит веб-версию меморандума Административно-бюджетного управления Белого дома M-15-13, «Политика, требующая безопасных соединений через федеральные веб-сайты и веб-службы» , а также технические рекомендации и передовой опыт. для оказания помощи в его реализации.

Цель

Настоящий Меморандум требует, чтобы все общедоступные федеральные веб-сайты и веб-службы [1] предоставляли услуги только через безопасное соединение. Самая надежная защита конфиденциальности и целостности, доступная в настоящее время для общедоступных веб-соединений, — это безопасный протокол передачи гипертекста (HTTPS).

Этот Меморандум расширяет материал предыдущего руководства Управления управления и бюджета (OMB), содержащийся в M-05-04, и относится к материалу в M-08-23. В нем содержится руководство для агентств по переходу на HTTPS и крайний срок, к которому агентства должны выполнить требования.

Справочная информация

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

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

Все действия в Интернете должны считаться частными и конфиденциальными.

Стандарт HTTPS-Only устранит непоследовательные, субъективные определения между агентствами относительно того, какой контент или действия в Интернете являются конфиденциальными по своей природе, и создаст более строгий стандарт конфиденциальности для всего правительства.

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

Что делает HTTPS

HTTPS проверяет подлинность веб-сайта или веб-службы для подключающегося клиента и шифрует почти всю информацию, передаваемую между веб-сайтом или службой и пользователем. Защищенная информация включает файлы cookie, сведения об агенте пользователя, URL-адреса, отправку форм и параметры строки запроса. HTTPS предназначен для предотвращения чтения или изменения этой информации во время передачи.

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

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

Чего не делает HTTPS

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

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

Проблемы и соображения

Производительность сайта: Несмотря на то, что шифрование увеличивает вычислительную нагрузку, современное программное и аппаратное обеспечение может справляться с этой нагрузкой без существенного вредного воздействия на производительность или задержку сервера. Веб-сайты с сетями доставки контента или серверным программным обеспечением, поддерживающим протоколы SPDY или HTTP/2, для которых требуется HTTPS в некоторых основных браузерах, могут значительно улучшить производительность своих сайтов в результате перехода на HTTPS.

Server Name Indication: Расширение Server Name Indication для TLS позволяет более эффективно использовать IP-адреса при обслуживании нескольких доменов. Однако эти технологии не поддерживаются некоторыми устаревшими клиентами. Владельцы веб-сервисов должны оценить возможность использования этой технологии для повышения производительности и эффективности.

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

API и службы: Веб-службы, которые в основном обслуживают небраузерные клиенты, такие как веб-API, могут потребовать более постепенной и практической стратегии миграции, поскольку не все клиенты могут быть настроены для соединений HTTPS или для успешно следовать редиректам.

Планирование изменений: Протоколы и веб-стандарты регулярно совершенствуются, и могут появляться уязвимости в системе безопасности, которые требуют немедленного внимания. Федеральные веб-сайты и службы должны развертывать HTTPS таким образом, чтобы можно было быстро обновлять сертификаты, варианты шифрования (включая прямую секретность), версии протокола и другие элементы конфигурации. Агентства должны следить за https.cio.gov и другими общедоступными ресурсами, чтобы быть в курсе последних передовых практик.

Строгая транспортная безопасность: Веб-сайты и службы, доступные через HTTPS, должны включить HTTP Strict Transport Security (HSTS), чтобы браузеры, соответствующие требованиям, предполагали использование HTTPS в будущем. Это уменьшает количество небезопасных перенаправлений и защищает пользователей от атак, которые пытаются перевести соединения на обычный HTTP. После того, как HSTS будет установлен, домены могут быть отправлены в «список предварительной загрузки», используемый всеми основными браузерами, чтобы обеспечить постоянное действие политики HSTS.

Безопасность системы доменных имен (DNSSEC): Новая политика, изложенная в этом Меморандуме, не отменяет и не противоречит M-08-23 «Защита инфраструктуры системы доменных имен федерального правительства». После завершения разрешения DNS DNSSEC не гарантирует конфиденциальность или целостность связи между клиентом и IP-адресом назначения. HTTPS обеспечивает эту дополнительную безопасность.

Экономически эффективное внедрение

Внедрение стандарта только для HTTPS не обходится без затрат. Значительное количество федеральных веб-сайтов уже внедрили HTTPS. Целью этой политики является увеличение этого принятия.

Административное и финансовое бремя универсального внедрения HTTPS на всех федеральных веб-сайтах включает время разработки, финансовые затраты на приобретение сертификата и административное бремя обслуживания с течением времени. Бремя разработки будет существенно различаться в зависимости от размера и технической инфраструктуры сайта. Сроки соблюдения, изложенные в этом Меморандуме, обеспечивают достаточную гибкость для планирования проекта и распределения ресурсов.

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

Техническая помощь по телефону https.cio.gov поможет в рентабельной реализации этой политики.

Руководящие указания

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

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

Недавно разработанные веб-сайты и службы во всех доменах или поддоменах федеральных агентств должны придерживаться этой политики при запуске.
Для существующих веб-сайтов и служб агентства должны определить приоритет развертывания с помощью анализа рисков. Веб-службы, включающие обмен информацией, позволяющей установить личность (PII), содержимое которых однозначно носит конфиденциальный характер или содержимое которых получает высокий уровень трафика, должны получить приоритет и мигрировать как можно скорее.
Агентства должны обеспечить доступ ко всем существующим веб-сайтам и службам через безопасное соединение [3] (только HTTPS, с HSTS) до 31 декабря 2016 г.
Использование HTTPS рекомендуется во внутренних сетях [4], но не является обязательным.

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

Сноски

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

⬑ 2. В контексте HTTPS в Интернете центр сертификации — это сторонняя организация или компания, которым браузеры и операционные системы доверяют выпуск цифровых сертификатов от имени владельцев доменов.

⬑ 3. Разрешение HTTP-соединений с единственной целью перенаправления клиентов на HTTPS-соединения допустимо и рекомендуется. Заголовки HSTS должны указывать максимальный возраст не менее 1 года.

⬑ 4. «Интранет» здесь определяется как компьютерная сеть, недоступная напрямую через общедоступный Интернет.

Стандарт только для HTTPS — Руководство по соответствию ), чтобы убедиться в этом.

Это относится ко всем общедоступным доменам и поддоменам, управляемым федеральным правительством, независимо от суффикса домена, если они доступны через HTTP/HTTPS в общедоступном Интернете.

На этой странице представлены рекомендации Административно-бюджетного управления Белого дома по внедрению для агентств, поскольку агентства управляют своим переходом на HTTPS.

Контрольный список соответствия и передовой практики
Опции для соответствия требованиям HSTS
Часто задаваемые вопросы о соответствии
- На какие протоколы распространяется M-15-13?
- Нужно ли отключать порт 80?
- Если на моем сервере полностью отключен обычный HTTP, нужен ли мне HSTS?
- Что насчет сетевых служб, которые на самом деле не обслуживают веб-контент?
- Что включает в себя «все домены или поддомены федеральных агентств»?
- Как насчет доменов, которые используются только для перенаправления посетителей на другие веб-сайты?
- Должны ли домены, которые перенаправляют на другие внешние домены, выполнять внутреннее перенаправление на HTTPS перед внешним перенаправлением?
- Как насчет доменов, которые технически являются общедоступными, но на практике используются только для внутренних целей?
- Что происходит с посетителями, использующими браузеры, не поддерживающие HSTS, например старые версии Internet Explorer?
- Этот сайт перенаправляет пользователей на HTTPS. Почему Pulse говорит, что не использует HTTPS?
- Требуются ли федеральные службы отзыва сертификатов (CRL, OCSP) для перехода на HTTPS?
- Что делать, если я использую сертификат, выданный на федеральном уровне, например, федеральной PKI или министерства обороны, для своей веб-службы?

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

Каждый общедоступный веб-сайт или веб-служба, управляемая агентством , должен :

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

Каждый общедоступный веб-сайт или веб-служба, которыми управляет агентство, следует :

Следуйте передовым техническим методам в отношении качества TLS, как показано на https.cio.gov и измерено с помощью pulse.cio.gov.
Устраните все проблемы со смешанным содержимым, возникающие в процессе миграции.
Оцените целесообразность отказа от поддержки устаревших клиентов и использования современных стандартов, таких как индикация имени сервера.

Опции для соответствия требованиям HSTS

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

Предварительная загрузка помечает целые домены как HTTPS-только и позволяет браузерам строго и автоматически применять это правило для каждого поддомена. Во многих доменах .gov уже реализована предварительная загрузка HSTS, как и в большом количестве веб-сервисов частного сектора.

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

При любом подходе веб-службы, используемые небраузерными клиентами (например, API), должны по отдельности применять HTTPS, поскольку HSTS не поддерживается небраузерными клиентами.

1. Полная предварительная загрузка HSTS родительского домена (предпочтительно)

Родительский домен (например, https://agency.gov ) имеет политику HSTS, которая включает поддомены и имеет максимальный возраст не менее 1 год, как этот:

 Строгая транспортная безопасность: max-age=31536000; включать поддомены; предварительная загрузка

Домен успешно отправлен и добавлен в список предварительной загрузки HSTS.
Для отдельных поддоменов веб-сайтов по-прежнему рекомендуется устанавливать собственные политики HSTS.

Предварительная загрузка родительского домена HSTS позволяет агентствам избежать инвентаризации и настройки политики HSTS для каждого отдельного поддомена. Однако этот подход также автоматически включает всех 9В этом домене присутствует 0006 поддоменов, включая поддомены интрасети. Все поддомены должны будут поддерживать HTTPS, чтобы оставаться доступными для использования в основных браузерах.

2. Соответствие для каждого отдельного поддомена

Родительский домен и каждый из его общедоступных поддоменов должны установить политику HSTS с максимальным возрастом не менее 1 года, например:

 Строгая транспортная безопасность: max-age=31536000

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

Часто задаваемые вопросы о соответствии

Ответы на другие распространенные вопросы о соответствии приведены ниже.

На какие протоколы распространяется M-15-13?

M-15-13 требует безопасных соединений для веб-сайтов и веб-сервисов , что означает только HTTP-протоколы . Сюда входят все федеральные веб-сайты, а также федеральные API на основе HTTP.

M-15-13 не касается использования DNS или DNSSEC, FTP или SFTP или любого другого сетевого протокола, отличного от HTTP.

Нужно ли отключать порт 80?

№ М-15-13 состояния:

Разрешение HTTP-соединений с единственной целью перенаправления клиентов на HTTPS-соединения допустимо и рекомендуется.

Агентства могут использовать порт 80 исключительно для перенаправления клиентов на безопасное соединение.

HTTP-перенаправления должны использовать код ответа из числа 300, который может надежно заставить HTTP-клиенты выполнять перенаправления на HTTPS URI, например 301 или 302.

Использование кодов ошибок 400 или 500 не удовлетворяет этому требованию.

Обратите внимание, что несмотря на то, что подключения к порту 80 небезопасны даже для перенаправления, использование HSTS заставит поддерживающих HTTP-клиентов автоматически перенаправлять себя с порта 80 на порт 443, не пытаясь подключиться к порту 80 по сети.

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

Если простой HTTP полностью отключен на моем сервере, нужен ли мне HSTS?

Да. Отключение поддержки HTTP недостаточно для предотвращения атак, которые понижают веб-браузеры до простого HTTP.

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

HSTS специально предписывает веб-браузерам никогда не инициировать обычные HTTP-соединения. Если пользователь щелкает ссылку http:// или вводит URL-адрес http:// , HSTS заставляет браузер сначала переписать URL-адрес, чтобы использовать https:// , прежде чем инициировать соединение.

По этой причине HSTS необходим для эффективного предотвращения атак на более ранние версии, даже если обычные HTTP-соединения не поддерживаются на сервере.

Как насчет сетевых служб, которые на самом деле не обслуживают веб-контент?

M-15-13 охватывает любую общедоступную сетевую службу, которая отвечает на запросы HTTPS или HTTP. Сюда входят сетевые службы, которые не обслуживают контент, а возвращают только заголовки HTTP или пустой или несущественный контент.

Сюда также входят службы, отвечающие на запросы HTTPS или HTTP на нестандартных портах (порты, отличные от 80 или 443), независимо от того, включены ли эти службы во внешние проверки, предоставляемые агентствам.

Сетевые службы, которые не отвечают на HTTPS- или HTTP-запросы, не входят в сферу действия M-15-13.

Что включает в себя «все домены или поддомены федеральных агентств»?

Домены и поддомены, в контексте M-15-13, относятся к именам хостов, которые общедоступны через HTTP или HTTPS.

Домен относится к именам хостов, которые могут быть зарегистрированы напрямую. Некоторые примеры включают gsa. gov , whitehouse.gov , dodig.mil или fs.fed.us .

Субдомен относится к любому имени хоста, являющемуся дочерним элементом регистрируемого домена, и может иметь любую длину. Некоторые примеры включают www.gsa.gov , planthardiness.ars.usda.gov , www.fia.fs.fed.us или www.usar.army.mil .

Федеральные домены не все заканчиваются на .gov , .mil или .fed.us . Некоторые могут заканчиваться на .com , .org , .us или другими суффиксами. Любой федеральный домен покрывается M-15-13.

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

Эти домены должны включать порт 443 и использовать правильно настроенный HTTPS.

Они должны соответствовать всем тем же требованиям и рекомендациям, что и домены, используемые для размещения веб-сайтов и API, включая HSTS и предварительную загрузку.

Должны ли домены, перенаправляющие на другие внешние домены, выполнять внутреннее перенаправление на HTTPS перед внешним перенаправлением?

Обычно нет, но практически требуется для предзагрузки домена второго уровня.

Например, М-15-13 не требует перенаправления с http://example.gov:80 на https://example.gov:443 перед перенаправлением на https://another-example.gov:443 . Однако это позволяет подключающемуся клиенту видеть и кэшировать заголовок HSTS на example.gov , который иначе он может не увидеть.

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

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

M-15-13 включает все домены и поддомены, которые общедоступны через HTTP/HTTPS, независимо от операционной практики агентства.

Что происходит с посетителями, использующими браузеры, не поддерживающие HSTS, например старые версии Internet Explorer?

Браузеры, которые не поддерживают HSTS, просто не подвержены влиянию HSTS, поэтому его включение не повредит.

Этот сайт перенаправляет пользователей на HTTPS. Почему Pulse говорит, что не использует HTTPS?

Pulse ищет перенаправления на стороне сервера, используя соответствующий код ответа HTTP. Сайты, использующие перенаправления на стороне клиента, такие как тег или JavaScript, не будут рассматриваться как перенаправления. Чтобы выполнить требование M-15-13 по принудительному использованию HTTPS, агентства должны использовать перенаправления на стороне сервера (или, в качестве альтернативы, вообще отключить доступ по HTTP).

Сайты, которые доступны как на корневом домене ( http://agency.gov ), так и на их поддоменах www ( http://www.agency.gov ), должны выполнять перенаправление на HTTPS в обоих случаях. Перенаправление одного, но не другого, также может привести к тому, что Pulse укажет, что домен не использует HTTPS.

Требуются ли федеральные службы отзыва сертификатов (CRL, OCSP) для перехода на HTTPS?

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

Для CRL в RFC 5280 сказано:

 ЦС НЕ ДОЛЖНЫ включать в расширения URI, указывающие https, ldaps или аналогичные схемы. Центры сертификации, которые включают https URI в одно из этих расширений, ДОЛЖНЫ гарантировать, что сертификат сервера может быть проверен без использования информации, на которую указывает URI. Доверяющие стороны, которые выбирают проверку сертификата сервера при получении информации, на которую указывает URI https в расширениях cRLDistributionPoints, authorInfoAccess или subjectInfoAccess, ДОЛЖНЫ быть готовы к тому, что это может привести к неограниченной рекурсии.

Для OCSP в RFC 6960 сказано:

 Если конфиденциальность является требованием, транзакции OCSP, которыми обмениваются с использованием HTTP, МОГУТ быть защищены с использованием либо безопасности транспортного уровня/уровня защищенных сокетов (TLS/SSL), либо какого-либо другого протокола более низкого уровня.

Агентствам рекомендуется использовать службы OCSP и CRL через имена хостов, специально зарезервированные для этих служб, чтобы другая связанная информация и функции могли предоставляться безопасно и конфиденциально.

Что делать, если я использую сертификат, выданный на федеральном уровне, например, федеральной PKI или министерства обороны, для своей веб-службы?

Нет никаких ограничений на приемлемые органы сертификации, которые могут использовать агентства для выполнения требований M-15-13.

Однако M-15-13 требует от агентств не только перенаправления HTTP-трафика на HTTPS. Также требуется, чтобы агентства включили HTTP Strict Transport Security (HSTS), как описано выше. HSTS обеспечивает постоянное использование HTTPS и защищает пользователей от нескольких распространенных уязвимостей.

Одним из важных эффектов HSTS является то, что он отключает возможность для пользователей просматривать предупреждения о сертификатах в поддерживаемых браузерах. Это означает, что агентства не могут указывать пользователям щелкать предупреждения о сертификатах , чтобы использовать их веб-службу, а также соблюдать M-15-13.

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

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

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