Сайты http

HTTP — это протокол передачи гипертекста между распределёнными системами. По сути, http является фундаментальным элементом современного Web-а. Как уважающие себя веб разработчики, мы должны знать о нём как можно больше.

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

Также в этой статье я буду, в основном, ссылаться на стандарт RFC 2616: Hypertext Transfer Protocol — HTTP/1.1.

Основы HTTP

HTTP обеспечивает общение между множеством хостов и клиентов, а также поддерживает целый ряд сетевых настроек.

В основном, для общения используется TCP/IP, но это не единственный возможный вариант. По умолчанию, TCP/IP использует порт 80, но можно заюзать и другие.

Общение между хостом и клиентом происходит в два этапа: запрос и ответ. Клиент формирует HTTP запрос, в ответ на который сервер даёт ответ (сообщение). Чуть позже, мы более подробно рассмотрим эту схему работы.

Текущая версия протокола HTTP — 1.1, в которой были введены некоторые новые фишки. На мой взгляд, самые важные из них это: поддержка постоянно открытого соединения, новый механизм передачи данных chunked transfer encoding, новые заголовки для кэширования. Что-то из этого мы рассмотрим во второй части данной статьи.

URL

Сердцевиной веб-общения является запрос, который отправляется через Единый указатель ресурсов (URL). Я уверен, что вы уже знаете, что такое URL адрес, однако для полноты картины, решил всё-таки сказать пару слов. Структура URL очень проста и состоит из следующих компонентов:

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

Методы

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

Существующие методы:

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

POST: используется для создания нового ресурса. POST запрос обычно содержит в себе всю нужную информацию для создания нового ресурса.

PUT: обновить текущий ресурс. PUT запрос содержит обновляемые данные.

DELETE: служит для удаления существующего ресурса.

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

Также HTTP поддерживает и другие методы:

HEAD: аналогичен GET. Разница в том, что при данном виде запроса не передаётся сообщение. Сервер получает только заголовки. Используется, к примеру, для того чтобы определить, был ли изменён ресурс.

TRACE: во время передачи запрос проходит через множество точек доступа и прокси серверов, каждый из которых вносит свою информацию: IP, DNS. С помощью данного метода, можно увидеть всю промежуточную информацию.

OPTIONS: используется для определения возможностей сервера, его параметров и конфигурации для конкретного ресурса.

Коды состояния

В ответ на запрос от клиента, сервер отправляет ответ, который содержит, в том числе, и код состояния. Данный код несёт в себе особый смысл для того, чтобы клиент мог отчётливей понять, как интерпретировать ответ:

1xx: Информационные сообщения

Набор этих кодов был введён в HTTP/1.1. Сервер может отправить запрос вида: Expect: 100-continue, что означает, что клиент ещё отправляет оставшуюся часть запроса. Клиенты, работающие с HTTP/1.0 игнорируют данные заголовки.

2xx: Сообщения об успехе

Если клиент получил код из серии 2xx, то запрос ушёл успешно. Самый распространённый вариант — это 200 OK. При GET запросе, сервер отправляет ответ в теле сообщения. Также существуют и другие возможные ответы:

• 202 Accepted: запрос принят, но может не содержать ресурс в ответе. Это полезно для асинхронных запросов на стороне сервера. Сервер определяет, отправить ресурс или нет.
• 204 No Content: в теле ответа нет сообщения.
• 205 Reset Content: указание серверу о сбросе представления документа.
• 206 Partial Content: ответ содержит только часть контента. В дополнительных заголовках определяется общая длина контента и другая инфа.

3xx: Перенаправление

Своеобразное сообщение клиенту о необходимости совершить ещё одно действие. Самый распространённый вариант применения: перенаправить клиент на другой адрес.

• 301 Moved Permanently: ресурс теперь можно найти по другому URL адресу.
• 303 See Other: ресурс временно можно найти по другому URL адресу. Заголовок Location содержит временный URL.
• 304 Not Modified: сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности — Enttity Tag);

4xx: Клиентские ошибки

Данный класс сообщений используется сервером, если он решил, что запрос был отправлен с ошибкой. Наиболее распространённый код: 404 Not Found. Это означает, что ресурс не найден на сервере. Другие возможные коды:

• 400 Bad Request: вопрос был сформирован неверно.
• 401 Unauthorized: для совершения запроса нужна аутентификация. Информация передаётся через заголовок Authorization.
• 403 Forbidden: сервер не открыл доступ к ресурсу.
• 405 Method Not Allowed: неверный HTTP метод был задействован для того, чтобы получить доступ к ресурсу.
• 409 Conflict: сервер не может до конца обработать запрос, т.к. пытается изменить более новую версию ресурса. Это часто происходит при PUT запросах.

5xx: Ошибки сервера

Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:

• 501 Not Implemented: сервер не поддерживает запрашиваемую функциональность.
• 503 Service Unavailable: это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

Форматы сообщений запроса/ответа

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

Давайте посмотрим на структуру передаваемого сообщения через HTTP:

Между заголовком и телом сообщения должна обязательно присутствовать пустая строка. Заголовков может быть несколько:

• Общие заголовки
• Заголовки запроса
• Заголовки ответа
• Заголовки сущностей

Тело ответа может содержать полную информацию или её часть, если активирована соответствующая возможность (Transfer-Encoding: chunked). HTTP/1.1 также поддерживает заголовок Transfer-Encoding.

Общие заголовки

Вот несколько видов заголовков, которые используются как в запросах, так и в ответах:

Что-то мы уже рассмотрели в этой статье, что-то подробней затронем во второй части.

Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.

Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache — это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.

Заголовок Date используется для хранения даты и времени запроса/ответа.

Заголовок Upgrade используется для изменения протокола.

Transfer-Encoding предназначается для разделения ответа на несколько фрагментов с помощью Transfer-Encoding: chunked. Это нововведение версии HTTP/1.1.

Заголовки сущностей

В заголовках сущностей передаётся мета-информация контента:

Все заголовки с префиксом Content- предоставляют информацию о структуре, кодировке и размере тела сообщения.

Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.

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

Формат запроса

Запрос выглядит примерно так:

SP — это разделитель между токенами. Версия HTTP указывается в HTTP-Version. Реальный запрос выглядит так:

Список возможных заголовков запроса:

В заголовке Accept определяется поддерживаемые mime типы, язык, кодировку символов. Заголовки From, Host, Referer и User-Agent содержат информацию о клиенте. Префиксы If- предназначены для создания условий. Если условие не прошло, то возникнет ошибка 304 Not Modified.

Формат ответа

Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:

• HTTP версия
• Код статуса
• Сообщение статуса, понятное для человека

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

Заголовки ответа могут быть следующими:

• Age время в секундах, когда сообщение было создано на сервере.
• ETag MD5 сущности для проверки изменений и модификаций ответа.
• Location используется для перенаправления и содержит новый URL адрес.
• Server определяет сервер, где было сформирован ответ.

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

Инструменты для определения HTTP трафика

Существует множество инструментов для мониторинга HTTP трафика. Вот несколько из них:

Наиболее часто используемый — это Chrome Developers Tools:

Если говорить об отладчике, можно воспользоваться Fiddler:

Для отслеживания HTTP трафика вам потребуется curl, tcpdump и tshark.

Библиотеки для работы с HTTP — jQuery AJAX

Поскольку jQuery очень популярен, в нём также есть инструментарий для обработки HTTP ответов при AJAX запросах. Информацию о jQuery.ajax(settings) можете найти на официальном сайте.

Передав объект настроек (settings), а также воспользовавшись функцией обратного вызова beforeSend, мы можем задать заголовки запроса, с помощью метода setRequestHeader().

Прочитать объект jqXHR можно с помощью метода jqXHR.getResponseHeader().

Если хотите обработать статус запроса, то это можно сделать так:

Итог

Вот такой вот он, тур по основам протокола HTTP. Во второй части будет ещё больше интересных фактов и примеров.

ruseller.com

The key difference between HTTP and HTTPS websites is that HTTPS supports SSL encryption. This is why push notifications work differently at these websites. How exactly, and what it means to you — we will tell now.

How it works

The most important thing that you need to know about push notifications is that their functioning in most browsers and applications is ensured and controlled by Google. So you’ll have to comply with its requirements. 

You can’t live without SSL, what do we do?

For example, Google’s requirements do not envisage working with push without an installed SSL certificate, that is, at http websites. This rule may be circumvented only by using third-party services (such as Push.World).

Subscription for push at websites with HTTP protocol

First and foremost, keep in mind that user subscription will be performed two stages: he will have to press «allow» in two windows.

Explanation for technically advanced readers:

First, the user clicks on the JS widget to open the sign-up page with SSL (a third party service), where he makes his subscription.

That is, the person subscribes to a domain/subdomain of a third-party service with pre-installed SSL, rather than your website. And they will get messages (technically) not from you, but from a third-party service, on your behalf, with your logo and your texts.

So be prepared and don’t be surprised.

Capabilities and features of the HTTPS Protocol

If you have a website with SSL, that’s fine, but, compared to http, your possibilities have been expanded. You can even «pick» code for your website from Google cloud messaging help, and start collecting subscribers.

Unlike HTTP, the HTTPS subscription window will appear only once. The only thing is that it is native (the standard browser one), and you virtually can’t change its appearance to increase conversion. And they look different in different operating systems:

• under Windows, the «Allow» button is on the left. and «Block» — on the right;
• under Mac OS X, «Allow» is on the right and «Block» — on the left.

 

And remember, if a visitor clicked «Block» once, he’ll never again see a subscription request from this website. Remember this sad fact. (But Push.World knows how to cope with it)

Tips for the tech-savvy

In order to draw attention to subscription requests at https websites, when the window appears, shade the main content of your page and point the arrow to the «Allow» button. This will increase conversion. Just don’t forget about the difference between buttons positions in Windows and Mac OS (see above).

Key things	HTTP	HTTPS
«Double-click subscription»	+	—
customization of time and place where subscription offer appears	+	—
independent work without third-party services	—	+
permanent blocking	—	+

How can the Push.World service help, and why subscription widgets are required

Push.World can turn all disadvantages of HTTP and HTTPS into advantages. The service offers the use of special subscription requests — in the form of widgets. They are customized (have various appearance) and appear to be most convenient moment of conversion. Unlike the annoying popups upon login!

But the main advantage of widgets is that if the user has clicked «No, thanks», it means that he only indicated his unwillingness to subscribe, rather than blocked your resource. Sometime in the future you will be able to invite this used to subscribe again.

Explanation for the technically advanced readers

After you introduce only one line of code into your website, the magic starts. The charm is that all these widgets are js-code, which can do a lot, for example, it can tell you:

• the number of times the user visited the website;
• what the website visit depth for the user is;
• how many minutes he has already been at the website.

Shure thing all this stuff you’ll get according only to push-notification subscription offer

That is, the Push.World service offers website owners all these convenient tools for obtaining user loyalty and conversion.

Conclusion and tips 

According to the statistics, HTTPS websites with their standard permission requests attract subscribers faster than HTTP websites. However, they do not care much about loyalty of subscribers and about blockings.

So, if you are not a one-day ad space, and you plan to painstakingly collect a loyal audience core keenly responsive to your push notifications, it is better to use subscription widgets.

And if you have an http:// website without SSL, then you have no choice but to resort to the help of a proxy service. And Push.World will help to do everything the best possible way — get involved!

push.world

Принцип работы

Действие протокола HTTP происходит по следующему принципу: программа-клиент осуществляет TCP-соединение с сервером (стандартный номер порта-80) и выводит ему HTTP-запрос. Сервер прорабатывает данный запрос и выдает HTTP-ответ клиенту.

2017

Россия: число сайтов с SSL-сертификатами за год выросло в четыре раза

По данным аналитического сервиса StatOnline, в российских национальных доменных зонах количество сайтов, использующих SSL-сертификаты, за год выросло в четыре раза. В июле 2015 года в зоне .RU количество таких ресурсов составляло 109 тыс., в том же месяце 2016 года — 189 тыс., а в июле 2017 года — 531 тыс. Для сравнения, показатели зоны .РФ составляли 18 тыс., 21 тыс. и 65 тыс. соответственно. По состоянию на август 2017 года, всего в зоне .RU насчитывается 5,5 млн сайтов, в зоне.РФ — 900 тыс., передают «Известия».^[1]

HTTPS-протокол призван защитить данные пользователей от перехвата. Согласно обещаниям Google, ссылки на ресурсы, которые всё еще не перешли на HTTPS, с начала 2018 года будут отображаться в результатах поиска с предупреждением об их небезопасности. С похожей инициативой выступила и компания Mozilla, выпускающая браузер Firefox.

SSL-сертификаты — уникальная цифровая подпись сайта, необходимая для организации защищенного соединения между браузером интернет-пользователя и сервером. Обычные сайты используют для обмена данными протокол HTTP, ресурсы с сертификатом — защищенный HTTPS. SSL-сертификаты выпускаются на разные сроки. По данным StatOnline, наиболее распространенный период действия SSL-сертификата — менее 1 года. В зоне .RU число таких сертификатов составляет 82% от общего числа, а в зоне .РФ — 95%.

Антивирусы влияют на безопасность HTTPS

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

В составе группы действовали специалисты Mozilla, Google, CloudFlare, представители университета Мичигана, иллинойсского университета в Урбан-Шампейне, калифорнийского университета в Беркли и Международного института информатики^[2].

Эксперты подозревали о влиянии инструментов защиты на защищенные соединения, в результате чего зашифрованный трафик подвергается риску и безопасность ослабевает. Они оказались правы в своих подозрениях. Исследователи проанализировали подтверждения сессий связи (handshakes), связанных с браузерами, антивирусными продуктами и вредоносными программами, и на основе этого создали эвристические методы контроля перехвата и вмешательства в HTTPS, определения субъекта перехвата трафика.

Созданные для тестов инструменты разместили на серверах Mozilla Firefox, CloudFlare CDN и сайтах электронной коммерции. Анализ показал: 4% соединений Firefox, 6,2% соединений e-commerce сайтов и 11% соединений CloudFlare перехвачены. После чего большинство этих соединений стали менее безопасны (97% применительно к Firefox, 54% для CloudFlare и 32% для e-commerce ресурсов). Безопасность более 62% процентов соединений ослабла до относительно приемлемого уровня, а 58% соединений стали подвержены критическим уязвимостям.

По мнению экспертов, беспокойство вызывает не только то, что перехватчики соединений использовали более слабые криптографические алгоритмы, но и то, что 10-40% из них объявили о поддержке давно взломанных шифров, что позволяет атакующему в позиции Man in the middle (MITM) перехватить соединение, произвести downgrade и расшифровать его.

Исследователи изучили работу продуктов A10 Networks, Blue Coat, Barracuda, Check Point, Cisco, Forcepoint, Fortinet, Juniper Networks, Microsoft, Sophos, Untangle и WebTitan. Из этого списка только технологии Blue Coat, по мнению исследователей, обращались с TLS-соединениями корректно. Остальные продукты получили 2-3 балла по пятибалльной шкале из-за уязвимостей и потенциальных MitM-атак.

2016: Только 5% HTTPS-серверов используют корректно настроенный HSTS

По данным компании Netcraft, 95% от всех использующихся в мире HTTPS-серверов уязвимы к хакерским атакам из-за неправильно настроенного механизма HSTS или его отсутствия. Как показали результаты исследования, только 5% изученных экспертами HTTPS-серверов используют корректно настроенный HSTS. Подобное исследование также проводилось три года назад, и с тех пор практически ничего не изменилось. По мнению исследователей, администраторы либо не знают о проблеме, либо относятся к ней недостаточно серьезно.

HSTS активирует форсированное защищенное соединение через HTTPS вместо HTTP. В настоящее время данный механизм поддерживается браузерами Internet Explorer 11, Microsoft Edge, Firefox, Chrome, Safari и Opera. С его помощью администраторы web-ресурсов могут предотвращать атаки «человек посередине», манипуляции с файлами cookie и т.д.

Как сообщают эксперты, простейший сценарий атаки выглядит следующим образом: пользователь вводит в строку поиска адрес сайта, указывая http:// вместо https://. Ресурс без поддержки HSTS открывается через HTTP, и у злоумышленников появляется возможность осуществить фишинговую атаку или атаку «человек посередине».

2015

Браузеры способствуют существованию фальшивых сайтов

Браузеры Google (Chrome), Microsoft (Internet Explorer), Apple (Safari) и Mozilla (Firefox) позволяют нарушать режим безопасного использования информации программам вроде Superfish, PrivDog, Gogo и аналогичным. Они делают это путем бездействия^[3].

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

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

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

Для использования защищенного веб-сайта HTTPS, необходимо вначале получить файл сертификата у любой из компаний в бизнесе по их продаже. Эти компании называют Центрами Сертификации (Certificate Authorities). Они берут на себя хлопоты по проверке идентичности субъекта, делающего запрос.

Технари упоминают файл сертификата, как «сертификат» или, чаще всего, просто «cert». Иногда его называют «сертификат HTTPS» или «сертификат шифрования». Google называет его «сертификат безопасности».

Чтобы подтвердить свою идентичность, сайты, использующие SSL-сертификаты, предоставляют сертификаты безопасности для Chrome, например. Любой желающий может создать веб-сайт, притворяющийся другим сайтом, но только реальный сайт имеет действительный сертификат безопасности для конкретного URL. Недействительные сертификаты могут означать: кто-то пытается манипулировать подключением к сайту.

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

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

Помимо этого, никто не знает эти компании. GeoTrust, Entrust, USERTrust, GTE CyberTrust, Starfield, CertPlus, DigiCert и Thawte не являются общеизвестными. Почтамт Гонконга, например, является доверенным Центром Сертификации. Кто будет доверять веб-узлу, идентичность которого удостоверена почтамтом Гонконга? Браузеры в пользовательских системах доверяют.

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

Нет сомнения, что Microsoft, Apple, Google и Mozilla будет указывать на то, что имя поручающегося Certificate Authority легко доступно. Технически, это так. Реально это не так, по крайней мере, не для не-технарей, которые нуждаются в этом больше всего.

Чтобы увидеть имя Certificate Authority, потребуется совершить несколько манипуляций, а маршрут передвижения никто никогда не объясняет новичкам. И эти манипуляции отличны для каждого браузера.

Рассмотрим действия на платформе Windows. Существует несколько путей по раскрытию имени CA.

В Firefox 36 (и выше), необходимо нажать на замок, слева от адреса сайта в адресной строке. Во всплывающем окне появится «Подтверждено» и имя Центра Сертификации.

В Chrome 41 название компании темно-зеленое в светло-зеленом прямоугольнике. Нужно нажать на название компании или на замок рядом с адресом, затем на слово «Соединения». Это не сразу понятно, в появившемся окне есть две вкладки — одна для Разрешений, другая для Соединений.

По какой-то причине, визуальный дизайн этих вкладок полностью отличается от вкладок браузера прямо над ними. На вкладке Соединения видно название Центра Сертификации.

В Internet Explorer 11 надо щелкнуть на замке с правой стороны адресной строки. В появившемся окне видно информацию об идентификации веб-сайта. Внизу окна щелкнуть Просмотр сертификатов и видно подробную информацию о Центре Сертификации, кому он выдан и сроках действия.

В Opera 27 требуется нажать на название компании, отображаемое зеленым цветом рядом с черным названием сайта, или на замок слева от адреса. Затем, нажать на слово «Подробнее». Название Центра Сертификации показывается, но он не идентифицирован, как таковой.

Браузер Vivaldi technical preview 2 предлагает секретный намек. Если навести курсор мыши на название компании, отображаемое зеленым цветом, слева от имени сайта, всплывающее окно покажет «информацию о сайте». После нажатия, цвет фона меняется со светло-зеленого до темно-зеленого. Нажатие на название компании вызовет окно, которое выглядит так же, как в Chrome — с вкладками Разрешения и Соединения.

В Safari на OS X необходимо нажать на маленький зеленый замок слева от названия компании.

Два браузера iOS 8 работают как Джекил и Хайд. Chrome не показывает название компании, только адрес. Safari, напротив, показывает только название компании и скрывает URL.

Хуже всего в Safari на iOS 8 то, что независимо от того, где ни щелкай, ни нажимай или наводи, он не выдаст название Центра Сертификации для безопасных веб-сайтов. Он не показывает даже полные URL-адреса. Chrome на Android также не в состоянии идентифицировать поручительства Центра Сертификации для защищенного веб-сайта.

Странное совпадение, что в наиболее популярных браузерах на iOS и Android отсутствует важная функция безопасности.

В скриншотах выше заметно, что Центр Сертификации никогда не идентифицируется как таковой. Разработчики интерфейса решили, что все на планете уже знакомы с системой.

В Windows, Firefox, Chrome и Vivaldi используется слово «подтверждено», Internet Explorer использует «определил веб-сайт как», а Opera просто показывает имя.

Лучшее объяснение в Safari на OS X: Компания X определила сайт Y, как принадлежащий компании Z. Довольно просто. Но даже это объяснение не определяет Certificate Authority как Certificate Authority (Центр Сертификации), что делает ситуацию гораздо сложнее для не-технарей.

Добавляет путаницы название Центров Сертификации. В приведенных выше примерах Bank Of America, видно четыре различных названия: VeriSign Inc, VeriSign (без Inc), Symantec Corporation и Symantec Class 3 EV SSL CA — G3.

Как Центр Сертификации может использовать четыре названия?

Отчасти это происходит из файла сертификата, имеющего несколько встроенных имен для каждого Центра Сертификации. Chrome отображает «общее название», а Firefox выводит «Название организации». Ни один из браузеров не показывает название «Организационной единицы», которое, в данном случае, «Symantec Trust Network».

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

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

В примерах с Bank Of America, браузеры сообщали, что VeriSign подтверждающая этот веб-сайт, получила название либо от CA-субподрядчика среднего уровня, или от оригинального CA (известного среди технарей, как корневой центр сертификации).

И все становится еще хуже.

В случае с Bank of America, технари знают, что Symantec купила VeriSign, так что эти два названия, по сути, одно и то же.

Но действительно ли Bank of America использует VeriSign? Может быть, они используют DigiCert или GeoTrust или Thawte. Как узнать? Единственный способ — если родственник работает в этом банке.

Кто еще думает, что определение «мошенничество» слишком сурово?

При этом вполне понятно, как работал Superfish.

Человек посередине (Man in the middle)

Superfish размещает себя между жертвой и остальным миром. Когда клиенты Lenovo думали, что у них установлено безопасное соединение с somebankingsite.com, его на самом деле не было. У них было безопасное соединение с программным обеспечением Superfish на их ПК с Windows 8.

Кроме того, банк тоже обманули, заставляя думать, что он общается непосредственно с клиентом. На самом деле, банк также общался с Superfish. Это классическая атака посредника, атака «человек посередине», MitM-атака^[4].

В старые времена, только плохие парни и шпионы проводили атаки посредника. Теперь рекламные компании делают это.

Классическая атака «человека посередине» использовала незащищенное соединение HTTP между веб-браузером и мошенником. Если происходит замена HTTPS на HTTP, то должен отсутствовать значок замка. С тех времен многие вещи изменились.

Superfish может скрыть свое присутствие представлением веб-браузеру файла сертификата — не настоящего файла-сертификата, а того, который Superfish создает «на лету». Независимо от того, какой защищенный веб-сайт HTTPS клиент Lenovo посещал, Superfish динамически создавал сертификат для него.

Другая часть атаки заставляет веб-браузеры доверять сертификатам от Superfish. Нормальные компьютеры так не делают.

Долгие месяцы клиенты Lenovo не замечали, что Superfish ручается за каждый защищенный веб-сайт в мире. Это свидетельствует о том, что найти название Certificate Authority довольно трудно. Gogo долго выпускал мошеннические сертификаты YouTube, пока этого не заметил сотрудник Google.

Веб-браузеры должны четко показывать Certificate Authority на видном месте — лучше заставить пользователя «щелкать», для сокрытия названия, а не для его показа. Браузеры должны пролить свет на систему, функционирующую в темноте.

Существовавшая некогда компания розничной торговли Sy Syms использовала слоган для рекламы: «Образованный потребитель — наш лучший клиент». В мире технологий все не так. Возникает стойкое чувство, что есть цель — удержание в неведении технически неграмотных пользователей.

Если имя Центра сертификации (Certificate Authority) будет на видном месте в окне браузера, конечные пользователи могут получить некоторые преимущества:

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

Спецслужбы не любят образованных потребителей. Нынешняя система служит им хорошо. Они могут предложить мошенническую копию веб-сайта и поручиться за него сертификатом от скомпрометированного Центра Сертификации. Компрометация одного CA, позволяет им поручиться за любой веб-сайт, пока скрыто название CA. Если бы мы могли видеть, что Центр Сертификации Harveys ручается за Bank of America, афера бы не сработала.

Все зависит от Google, Apple, Mozilla и Microsoft. Им стоит показать своим потребителям название Центров Сертификации, подтверждающих подлинность, якобы, безопасных веб-сайтов.

Идентичность Certificate Authority очень важный аспект во взаимном доверии между потребителями и поставщиками данных.

Спецификации HTTP/2

18 февраля 2015 года стало известно о предстоящих усовершенствованиях протокола HTTP. Цель модернизации — значительное ускорение загрузки страниц.

Разработкой спецификаций протокола занималась рабочая группа IETF HTTP.

HTTP2 – первый значимый апдейт протокола с 1999 года, когда на свет вышла версия HTTP под номером 1.1. Обновление ускорит загрузку интернет-страниц, улучшит качество интернет-соединений с удалёнными серверами, оптимизирует работу кэша на компьютере, чтобы браузеру не приходилось загружать одни и те же данные по нескольку раз, нагружая интернет-канал.

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

Корпорация Google официально заявила, что постарается перейти на протокол HTTP/2 максимально оперативно, чтобы ускорить загрузку данных для пользователей Интернета. Разработчики, заинтересованные в обновлённом протоколе, могут получить доступ к его спецификациям.

Основные особенности цифрового протокола HTTP2:

• Повышение эффективности использования сетевых ресурсов за счёт мультиплексирования запросов, расстановки приоритетов для запросов и сжатия заголовков HTTP, проактивных push-ответов со стороны сервера.
• Серьёзное увеличение производительности для современных браузеров и мобильных устройств.
• Возможность развёртывания в современном интернете, используя IPv4 и IPv6 и не забывая о NAT.
• Упрощение развёртывания решений на основе HTTP.
• Обеспечение современных требований к безопасности.

В основе HTTP/2 протокол SPDY^[5].

2014: Сайты с доступом по HTTP перейдут в разряд «опасных»

17 декабря 2014 года стало известно о предстоящей в 2015 году изменении в системе предупреждений браузера о небезопасных соединениях.

Chrome Security Team заявила, что все веб-страницы, доступ к которым осуществляется по протоколу HTTP, будут считаться опасными по умолчанию. По мнению разработчиков, подобная мера должна способствовать популяризации использования безопасных каналов связи и стимулировать владельцев сайтов переходит на применение HTTPS.

На 17 декабря 2014 года предупреждение появляется только в случае HTTPS-соединения, сертификат которого устарел или считается недопустимым (невалидным) и в то же самое время незащищённые каналы считаются браузером заслуживающими доверия, что не соответствует реалиям.

Согласно планам Chrome Security Team, будут определены три уровня безопасности:

• безопасное соединение с доступом по валидному HTTPS;
• сомнительное соединение, где в основном применяется доступ по HTTPS, но некоторые ресурсы используют обычный HTTP или имеются несущественные ошибки TLS;
• небезопасное соединение, где применяется обычный HTTP или некорректный HTTPS.

Первое время HTTP-сайты будут относиться к сомнительной категории. Когда доля защищённых сайтов вырастет до 75%, их будут маркировать как опасные. Когда доступ по HTTPS начнут практиковать более 85% сайтов, оповещение о безопасном доступе предлагается убрать, считая, что сеанс безопасен по умолчанию.

Смотрите также

• Криптография
• Криптография в цифровых технологиях
• ИБ — Средства шифрования
• PKI
• HTTPS
• SSL
• Электронная подпись (ЭЦП)

• Описание протокола HTTP
• HTTPS

www.tadviser.ru

Рекомендации по использованию HTTPS

Используйте надежные сертификаты безопасности

Если вы решили использовать протокол HTTPS на своем сайте, вам нужно получить сертификат безопасности. Его выдает центр сертификации, который проверяет, действительно ли указанный веб-адрес принадлежит вашей организации. Таким образом обеспечивается защита посетителей от атак с перехватом. Чтобы обеспечить высокий уровень защиты, при настройке сертификата выберите 2048-битный ключ. Если вы уже используете сертификат с менее надежным ключом (1024-битным), замените его на 2048-битный. При выборе сертификата следуйте изложенным ниже рекомендациям.

• Получайте сертификат в надежном центре сертификации, который может предоставить техническую поддержку.
• Определите, какой тип сертификата предпочтителен для вашего сайта:
  • Одиночный сертификат для одного защищенного источника (например, www.example.com).
  • Многодоменный сертификат для нескольких известных защищенных источников (например, www.example.com, cdn.example.com, example.co.uk).
  • Сертификат-шаблон для защищенного источника с несколькими динамическими субдоменами. (например, a.example.com, b.example.com).

Используйте переадресацию 301 на стороне сервера

Перенаправляйте пользователей и поисковые системы на страницу с поддержкой HTTPS или ресурс с переадресацией 301 на стороне сервера для адресов HTTP.

Убедитесь, что страницы HTTPS можно сканировать и индексировать

• Не запрещайте посредством файлов robots.txt сканировать и индексировать страницы HTTPS.
• Не используйте на страницах HTTPS метатеги noindex.
• Чтобы проверить, может ли робот Googlebot обработать ваш сайт, воспользуйтесь инструментом Просмотреть как Googlebot.

Используйте технологию HSTS

На сайтах, использующих протокол HTTPS, рекомендуется применять технологию HSTS (HTTP Strict Transport Security). В этом случае браузер будет запрашивать страницы HTTPS, даже если пользователь введет http в адресной строке. а Google будет предоставлять в результатах поиска только защищенные URL. Все это снижает вероятность показа пользователям незащищенного содержания.

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

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

1. Выполните переход на HTTPS, не включая HSTS.
2. Активируйте отправку заголовков HSTS с минимальным значением директивы max-age. Отслеживайте объем трафика пользователей и других клиентов, а также эффективность зависимых объектов, например объявлений.
3. Постепенно увеличивайте значение max-age в заголовках HSTS.

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

Включите предварительную загрузку HSTS

Чтобы повысить скорость загрузки и уровень безопасности страниц HTTPS, можно активировать предварительную загрузку HSTS. Также изучите требования на сайте hstspreload.org.

Распространенные проблемы

Ниже перечислены некоторые проблемы, которые могут возникнуть при использовании защиты TLS, и способы их устранения.

Описание	Действие
Просроченные сертификаты.	Вовремя обновляйте сертификаты.
В сертификате неправильно указано название сайта.	Убедитесь, что вы получили сертификат для всех имен хостов, которые обслуживают ваш сайт. Предположим, в сертификате указан только хост www.example.com. Пользователь, который попытается перейти на example.com (без префикса «www.»), не попадет туда из-за несоответствия сертификата.
Не поддерживается указание имени сервера (SNI, Server name indication).	Ваш веб-сервер должен поддерживать SNI. Также рекомендуйте посетителям использовать поддерживаемые браузеры. SNI поддерживают все современные браузеры. Для поддержки устаревших браузеров вам понадобится выделенный IP-адрес.
Проблемы сканирования.	Не блокируйте сканирование своего сайта HTTPS с помощью файла robots.txt.
Проблемы индексирования.	По возможности разрешите поисковым системам индексировать ваши страницы. Старайтесь не использовать метатег noindex.
Старые версии протоколов.	Старые версии протоколов уязвимы. Используйте последние версии библиотек TLS и протоколов.
Совмещение защищенных и незащищенных элементов.	В страницы HTTPS можно встраивать только контент, который передается по протоколу HTTPS.
Разное содержание на страницах HTTP и HTTPS.	Содержание на страницах HTTP и HTTPS должно быть идентичным.
Ошибки кода статуса HTTP на страницах с HTTPS.	Убедитесь, что ваш сайт возвращает правильный код статуса HTTP. Например, для доступных страниц используется код 200, а для несуществующих ‒ 404 или 410.

Дополнительные рекомендации

С другими рекомендациями по использованию страниц HTTPS на сайте можно ознакомиться здесь.

Перенос сайта с протокола HTTP на HTTPS

Смена протокола сайта с HTTP на HTTPS считается переносом сайта с изменением URL. Это действие может временно повлиять на учет трафика. Подробнее…

Добавьте в Search Console ресурс, использующий протокол HTTPS. Помните, что Search Console расценивает страницы HTTP и HTTPS как разные, поэтому их данные не совпадают.

Ознакомьтесь со страницей устранения неполадок при переносе файлов Sitemap.

Дополнительная информация

Статьи о реализации TLS на сайтах:

• Рекомендации Qualys по использованию SSL и TLS
• Информация об SSL и TLS на сайте Mozilla

support.google.com

Что такое HTTP и как он работает?

Чтобы получить нужный документ в интернете, пользователю достаточно ввести в поисковую строку браузера нужный URL-адрес (тут о структуре урлов подробности), который как раз содержит название протокола HTTP (или HTTPS).

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

http://goldbusinessnet.com/osnovy-html/chto-takoe-html-tegi-i-struktura-dokumenta/  http://goldbusinessnet.com/wp-content/uploads/2017/04/url.jpg  https://www.yandex.ru/

А теперь попробуем разобраться в общих чертах, как работает этот механизм. Для начала необходимо выяснить, что же такое HTTP. Это протокол, который служит для «транспортировки» информации между клиентским приложением и сервером.

Аббревиатура HTTP (HyperText Transfer Protocol) переводится с английского как «протокол передачи гипертекста». Вообще говоря, протоколов достаточно много, и каждый из них решает определенную задачу (например, тот же FTP).

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

Необходимо отметить, что передача данных по HTTP происходит посредством TCP/IP-соединения. При этом серверное приложение по умолчанию использует порт 80, хотя в некоторых случаях может применяться и другой.

TCP (Transmission Control Protocol)/IP является довольно сложной системой и включает в себя четыре уровня протоколов (прикладной, к которому и относится HTTP, транспортный, сетевой и канальный). Думаю, для общей информации этого пока достаточно, а то мы залезем в дебри.

Как осуществляется взаимодействие между клиентским приложением и сервером

Итак, мы определили, что HTTP организует передачу данных в форме гипертекста. Но как это происходит на практике? Я уже упомянул, что здесь применяется технология, заключающаяся в общении между клиентским приложением и сервером, на котором располагаются физические файлы, получаемые в чистом виде для просмотра, либо шаблоны той или иной CMS, генерирующие странички сайта «на лету».

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

Я уже давал общую схему того, как, благодаря отлаженному взаимодействию серверов DNS и системы IP-адресации реализовано бесперебойное функционирование интернета, когда пользователь сети может получить доступ к любому файлу или документу (например, к странице сайта) для получения информации, которая его интересует.

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

Там хранятся все имена доменов, каждому из которых соответствует уникальный IP адрес, связанный с сервером, на котором «живет» сайт с этим ДИ. Получив ай-пи, браузер отправляет на сервер HTTP-запрос, после чего получает ответ. Единую схему запросов и ответов при общении клиентского приложения (в нашем случае браузера) с сервером можно представить так:

«>

Между списком заголовков и телом сообщения присутствует пустая строка, которая определяется символом переноса. В случае запроса начальная строка состоит из следующих компонентов:

Метод URI HTTP/Версия  Host: site.ru

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

1. Метод — указывает на действие, которое необходимо совершить с данным веб-ресурсом. Таких методов несколько, но самые распространенные среди них это GET и POST. Первый предполагает получение данных с сервера для просмотра (например, определенную страницу конкретного сайта), а второй обратную операцию, то есть отправку информации на сервер (регистрации пользователей, формы авторизации, различных сообщений и т.д.).

2. URI (унифицированный идентификатор ресурса, который является более общим понятием, чем URL) — путь до файла относительно корневой папки (почитайте, как формируются абсолютные и относительные ссылки).

3. HTTP/Версия — указывается действующая модификация протокола. На данный момент это HTTP 1.1 (вы можете ознакомиться с ее спецификацией). Однако, в черновом виде уже существует следующая версия протокола 2.0, который основан на двоичной (бинарной) системе счисления.

Нижняя строка представляет собой заголовок Host в составе HTTP-запроса, отсылаемого браузером серверу в соответствии с полученным от ДНС IP. Для чего это надо? Для идентификации нужного сайта, поскольку на вебсерверах обычно расположен не один ресурс.

Разберем наглядный пример для закрепления пройденного. Скажем, браузер получил «задание» от пользователя отобразить страничку вот с таким адресом:

http://subscribe.ru/group/

Тогда HTTP-запрос посредством метода GET может быть составлен следующим образом (в этом случае обычно тело сообщения отсутствует):

GET /group/ HTTP/1.1  Host: subscribe.ru

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

HTTP/Версия Код состояния Пояснение

Теперь пробежимся вкратце и по составу ответа сервера:

1. Версия HTTP указывается по аналогии с запросом.

2. Код состояния (Status Code) — три цифры, информирующие о том, каков статус документа, запрошенного браузером. Например, 200 — ОК, страница существует и будет отображена в браузере, 301 — осуществлен постоянный редирект (перенаправление) на другой урл, 404 — вебстранички по такому адресу нет (возможно, она удалена либо юзер ошибся при вводе URL).

3. Пояснение (Reason Phrase) — текст дополнения к коду ответа. В некоторых случаях пояснение может отличаться от стандартного либо отсутствовать вовсе. Это связано в том числе с настройкой ПО, размещенного на сервере.

Реальный пример? Пожалуйста. Попробуем получить ответ сервера на запрос, приведенный мною в качестве примера выше (урл «http://subscribe.ru/group/»). Он будет выглядеть так (начальная строка с заголовками):

HTTP/1.1 200 OK  Server: nginx  Date: Sat, 10 Jun 2017 06:36:38 GMT  Content-Type: text/html; charset=utf-8  Connection: keep-alive  Content-Language: ru  Set-Cookie: Subscribe::Viziter=UQkivlk7k3YO3DgjAxM2Ag==; expires=Thu, 31-Dec-37 23:55:55 GMT; domain=subscribe.ru; path=/  P3P: policyref="/w3c/p3p.xml", CP="NOI PSA OUR BUS UNI"

В данном случае отсутствуют пояснение и тело сообщения, которое при использовании метода GET может содержать, например, HTML-код запрашиваемого документа (веб-странички). В зависимости от типа приложения клиента эти разделы могут присутствовать.

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

В любом случае, по содержанию HTTP-ответа сервера (включая код состояния) можно получить полезную информацию, связанную с запрашиваемым документом.

Для того, чтобы выше предложенная информация без усилий ложилась в пазл, не хватает конкретного примера. Его мы рассмотрим с помощью одного из расширений Google Chrome (именно этот веб-обозреватель является моим рабочим инструментом), именуемого HTTP Headers.

Он удобен тем, что дает полную картину взаимодействия «клиент-сервер», предоставляя в «одном флаконе» содержание HTTP запроса (request) и ответа (response). Посмотрите, какой документ выдал этот плагин при переходе по ссылке с одной страницы моего блога на другую:

«>

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

Интерес вызывают также HTTP Headers (заголовки), отображенные ниже. Например, пункт «Referer» дает информацию в виде урла, откуда был осуществлен переход.

Заголовок «User Agent» отражает как раз клиентское приложение, отправившее запрос вебсерверу. В данном случае это браузер, но могут быть и другие (мобильные устройства, поисковые роботы и т.д.). Данные, представленные в Юзер Агенте, необходимы серверному программному обеспечению для идентификации приложения, посылающего запрос.

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

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

goldbusinessnet.com

Что такое HTTPS и зачем оно нужно

Перед переводом сайта на HTTPS соединение следует разобраться, что это такое и как оно работает. HTTPS является защищенным вариантом HTTP протокола (Hypertext Transfer Protocol), в нем передаются необходимые данные для работы страниц (название браузера, разрешение экрана, наличие Cookie и т. п.).

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

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

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

Что такое SSL/TLS сертификат

Главным нововведением в HTTPS является обязательное применение цифрового SSL сертификата. Это файл, в котором хранится вся информация (IP адрес сервера, страна сайта, E-mail владельца и т. п.). Цифровой документ находится в зашифрованном виде на сервере сайта и на сервере центра сертификации (GoDaddy, Comodo и т. п.). При каждом соединении эти файлы сравниваются, и если они одинаковы, то соединение продолжается. Иначе появляется предупреждение безопасности.

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

• DV – подтверждают только домен (для небольших сайтов и блогов).
• OV – проверяется домен и организация.
• EV – расширенная проверка (появится зеленая полоса и замочек в браузере).

Наиболее предпочтительным для магазинов и банков считается EV вариант. Дальше идут дополнительные уточнения в виде:

• SGC (поддерживает старые браузеры).
• Wildcard (поддержка субдоменов).
• SAN (альтернативные домены в одном сертификате).
• IDN (поддержка национальных доменов www).

Для большинства сайтов достаточно использовать DV SSL сертификат. Он стоит недорого и гарантирует защиту от фишинга.

Как перевести сайт на защищенное соединение

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

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

1. Получение SSL сертификата.
2. Установка сертификата на сервер.
3. Изменение внутренних ссылок сайта.
4. Настройка redirect на 301 порт.
5. Изменение Hosts в robots.txt.

Если используются платные хостинги типа beget, то обратитесь в службу поддержки с сертификатом, и все дальнейшие действия выполнят работники сервиса. Наиболее сложным этапом при ответе на вопрос, как сделать https соединение, является настройка редиректа .htaccess, так как большинство скриптов не помогают.

Получение сертификата и его установка на сервер

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

• WoSign.
• Startssl.

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

• Reg.ru.
• Godaddy.
• Hostland.
• Symantec.
• Comodo.
• GlobalSign.
• Thawte.

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

• генерация CSR запроса;
• заполнение почты сайта (admin@[адрес сайта]);
• заполнение информации о владельце домена (для EV и OV документа).

CSR запрос включает в себя общие данные для проверки (доменное имя, организация, город, область, страна). После заполнения информации пользователь получает 2 кода (секретный ключ и CSR код), обязательно сохраните их в отдельный документ. Отправьте данный код для получения SSL сертификата и подождите его выдачу от центра.

Теперь перейдите на сайт хостинга и найдите раздел «SSL сертификат» или же обратитесь в поддержку. Потребуется предоставить информацию о CSR коде, приватном ключе и сертификате. Не забудьте включить поддержку SSL в панели хостинга.

Как создать https соединение на постоянной основе

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

То есть вместо http://site.ru/img/bg.png установить: //site.ru/img/bg.png.

Нужно убрать HTTP из названий ссылок. Если сомневаетесь, то позовите WEB-программиста или фрилансера, он быстро это настроит. Выискивать ссылки можно через редактор кода в каждом файле или же найти всю информацию через поиск в PhpMyAdmin.

После настройки ссылок нужно указать поисковикам об изменении. Откройте файл robots.txt и в строчке Host: вместо HTTP поставьте HTTPS.

Вместо http://example.ru вставьте: https://example.ru.

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

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

RewriteEngine on

RewriteCond %{HTTP:X-Forwarded-Proto} !https

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]

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

Кроме того потребуется изменить настройки в панели вебмастера «Яндекс» или Google. Потребуется в разделе настроек индексирования перейти в пункт главного зеркала и установить HTTPS. Кроме того, потребуется перенести:

• sitemap.xml;
• исключения URL;
• геолокацию;
• ссылки Disawov Tool для Гугла.

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

Как сделать https соединение в WordPress

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

• easy HTTPS Redirection;
• HTTPS (SSL).

Первый заменяет ссылки, а второй позволяет указать SSL сертификат. Кроме того, перейдите в раздел параметры->общие. Здесь нужно изменить URL и указать HTTPS протокол. Позаботьтесь, чтобы старые страницы тоже имели защищенное соединение. После изменения ссылок проведите настройку редиректа и измените файл robots.txt.

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

fb.ru