Отличие https от http – Переход на https, что такое протокол https и чем он отличается от http

Содержание

Чем HTTPS лучше HTTP? | Блог Perfecto Web

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

Предисловие

Начнем с разъяснения обоих типов соединений и покажем, что представляет из себя каждый из них. HTTP — это аббревиатура от английского HyperText Transfer Protocol — «протокол передачи гипертекста». Изначально он разрабатывался для передачи гипертекстовых документов в формате HTML. На данный момент он используется для передачи произвольных данных. HTTP обеспечивает транспорт между клиентом и сервером. Клиентом может быть ваш браузер, а сервером — машина, на которой установлен запрашиваемый сайт. При наборе адреса сайта отправляется запрос на соединение с сервером. Сервер в свою очередь ожидает запроса, выполняет определенные действия при запросе и возвращает клиенту результат.

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

HTTPS же является не отдельным протоколом, а расширенной версией протокола HTTP. Он имеет аббревиатуру от английского HyperText Transfer Protocol Secure. Как вы поняли, буква S в конце обозначает Secure — безопасность. Данное расширение протокола разработано для поддержки шифрования в целях повышения безопасности.

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

 

1. Забота о ваших клиентах

Забота о ваших клиентах

Основной пункт перехода с HTTP на HTTPS — его преимущество в защите и способности предотвращения хищения данных на пути от клиента к серверу. Ваши клиенты должны быть в безопасности, чтобы их логины и пароли никто не смог перехватить по пути. А если у вас на сайте есть платежная форма, которая требует ввода платежных данных клиента, то вы 100% должны использовать HTTPS и минимизировать риски хищения платежных данных ваших клиентов.

Для обычного сайта блога, где регистрация нужна исключительно для возможности комментирования, вы можете подумать: «Ну украдут данные от учетной записи пользователя, ну и что? Удалят комментарии?» Не все так однозначно. Во-первых, сам факт несанкционированного доступа от имени вашего пользователя — уже плохой знак. Во-вторых, не забывайте, что большая часть людей (особенно в возрасте от 40 лет) используют идентичные данные на разных ресурсах и даже в платежных сервисах. Таким образом, невинный логин/пароль от учетной записи в вашем блоге, может сильно навредить пользователю. Уважаете вашу аудиторию? Заботьтесь о ней!

 

2. Принуждения Рекомендации Google

Рекомендации Google относительно HTTPS

С 15 января 2017 года, Google ввел в новую версию браузера Google Chrome предупреждающий красный значок возле адресной строки, который будет информировать пользователей о том, что ваш сайт работает не по защищенному протоколу. Если раньше строка браузера просто была «серой», то сейчас табличка имеет ярко-красный вид, который привлекает внимание и осведомляет пользователя о незащищенном соединении с вашим сайтом. Чему это мешает? Во-первых, вашим продажам, если вы интернет магазин. Будет создавать ощущение, что ваш сайт «не серьезный» и на нем не стоит оставлять реальные персональные данные. А многие люди вовсе будут бояться вашего сайта, так как они где-то наслышались о хакерах, взломах и кражах личных данных. Они попросту уйдут к вашим конкурентам, где соединение защищено.

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

 

3. HTTPS работает быстрее HTTP

HTTPS работает быстрее HTTP

Кроме защищенности, HTTPS также обеспечивает более быстрый транспорт. Очень часто соединение к одному и тому же сервису через HTTP и HTTPS имеет разницу в скорости в 2-3 раза. Тем самым, HTTPS также уменьшит скорость загрузки вашего сайта, что тоже очень сильно может влиять на конверсию. Вы можете проверить данное убеждение через сервис для сравнения скорости протоколов HTTP и HTTPS.

 

4. Имидж вашей компании

Имидж вашей компании

Как вы бы отнеслись к люксовой компании, которая продает одеяло за $1,500 и не имеет SSL сертификат за $10-100, который бы обеспечивал безопасность и сохранность данных своих клиентов? Подобные мелочи отличают хорошую компанию от не очень хорошей. Вашим вниманием к мелочам, вашей заботой и реальным желанием обезопасить своих посетителей и клиентов, вы сможете добиться большего уважения в ответ.

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

Немного бонусной информации

Немного бонусной информации
  1. на 28 июня 2016, 10,2% сайтов из списка «Alexa top 1,000,000» используют протокол HTTPS по умолчанию;
  2. для перехода на HTTPS вам нужен SSL/TSL сертификат;
  3. средняя стоимость SSL сертификата $10-100;
  4. не используйте бесплатные и самодельные сертификаты на глобальных проектах;
  5. SSL сертификаты бывают на один домен, на домен и поддомены, на несколько доменов;
  6. благодаря SSL сертификату, данные не могут быть изменены и искажены во время передачи клиент←→сервер;
  7. для большинства сайтов достаточен сертификат с проверкой домена. Например Positive SSL от Comodo

 

HTTP в сравнении с HTTPS и SEO

В 2016 году сразу два представителя Google выступили в поддержку смены протокола HTTP на HTTPS. Google начнет маркировать незащищенные сайты. Поэтому интернет-маркетологам необходимо понимать различия между HTTP и HTTPS, преимущества перехода с одного протокола на другой и все проблемы, которые могут возникнуть:

Начиная с октября 2017 года, браузер Chrome отображает в строке URL-адреса предупреждение «Не безопасно», когда пользователи вводят данные на HTTP-странице. А также на всех HTTP-страницах, посещенных в режиме инкогнито:

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

HTTPS (Secure HyperText Transfer Protocol) был разработан для создания защищенных транзакций и авторизации через интернет. Обмен информацией, например номерами банковских карт, требует максимальной безопасности для предотвращения несанкционированного доступа.

HTTPS — это защищенная версия HTTP. В HTTPS используется дополнительный уровень безопасности протокол Secure Sockets Layer, или SSL.

Протокол HTTPS работает одновременно с другим протоколом, SSL (Secure Sockets Layer), чтобы безопасно передавать данные. При этом обеспечивается:

  • Шифрование передаваемых данных для обеспечения безопасности.
  • Целостность данных: данные не могут быть изменены или повреждены во время передачи.
  • Аутентификация: пользователи аутентифицируются для связи с сайтом.

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

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

Еще в 2013 году специально проведенные исследования показали увеличение количества защищенных URL-адресов. Но только после официального релиза мы начали повсеместно встречать такие сайты.

Если вы следуете рекомендациям Google, решение поменять протокол HTTP на HTTPS очевидно. Также существуют дополнительные преимущества с точки зрения SEO:

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

Если вы изучите данные Google Analytics для сайта на HTTP, то увидите, что трафик, проходящий через реферальные источники, может отображаться как «прямой». Для HTTPS-сайта четко отслеживаются ссылающиеся домены. Это делает решение о необходимости как можно скорее изменить протокол с HTTP на HTTPS еще более актуальным.

Безопасность обеспечивается несколькими способами:

  • Аутентификация при соединении между сайтом и сервером;
  • Шифрование данных, например, истории просмотров и информации о банковской карте.

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

Ниже приведены официальные рекомендации Google о том, как правильно сменить протокол http на https:

  • Определитесь, какой тип SSL-сертификата вам нужен.
  • Используйте 2048-разрядные сертификаты ключей для создания запроса на подпись сертификата (CSR) на своем сервере.
  • Используйте относительные URL-адреса для ресурсов, которые находятся на одном защищенном домене.
  • Добавьте HTTP-редирект 301 на HTTPS-страницы (mod_rewrite является стандартной практикой).
  • Обновите файл robots.txt, чтобы разрешить сканирование HTTPS-страниц.
  • Убедитесь, что ваш сайт возвращает правильный код статуса HTTP.
  • Получите и настройте необходимые сертификаты TLS на вашем сервере.

Дополнительная информация с форума поддержки Google:

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

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

После перехода на HTTPS добавьте URL-адреса в Search Console. Убедитесь, что в аккаунте Search Console указан, как старый, так и новый сайт. Обязательно проверьте все варианты как исходного, так и целевого сайтов. Например, нужно проверить версии www.example.com и example.com, а также включить как HTTPS, так и HTTP-версию сайта, если используются URL-адреса с HTTPS. Сделайте это как для исходного, так и для целевого сайта.

Использование протокола HTTPS сделает ваш сайт более безопасным, и Google активно продвигает эту политику.

Данная публикация представляет собой перевод статьи «HTTP vs HTTPS and SEO HTTPS Chrome Warning Starting in October 2017» , подготовленной дружной командой проекта Интернет-технологии.ру

что должен знать каждый Web-разработчик / Habr

Как же все-таки работает HTTPS? Это вопрос, над которым я бился несколько дней в своем рабочем проекте.

Будучи Web-разработчиком, я понимал, что использование HTTPS для защиты пользовательских данных – это очень и очень хорошая идея, но у меня никогда не было кристального понимания, как HTTPS на самом деле устроен.

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

Трубопровод

Перед тем как мы погрузимся в то, как это работает, давайте коротко поговорим о том, почему так важно защищать Интернет-соединения и от чего защищает HTTPS.

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

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

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

• Для этого требуется больше вычислительных мощностей
• Передается больше данных
• Нельзя использовать кеширование

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

Transport Layer Security (TLS)

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

TLS — наследник SSL — это такой протокол, наиболее часто применяемый для обеспечения безопасного HTTP соединения (так называемого HTTPS). TLS расположен на уровень ниже протокола HTTP в модели OSI. Объясняя на пальцах, это означает, что в процессе выполнения запроса сперва происходят все “вещи”, связанные с TLS-соединением и уже потом, все что связано с HTTP-соединением.

TLS – гибридная криптографическая система. Это означает, что она использует несколько криптографических подходов, которые мы и рассмотрим далее:

1) Асиметричное шифрование (криптосистема с открытым ключом) для генерации общего секретного ключа и аутентификации (то есть удостоверения в том, что вы – тот за кого себя выдаете).
2) Симметричное шифрование, использующее секретный ключ для дальнейшего шифрования запросов и ответов.

Криптосистема с открытым ключом

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

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

Это означает, что если кто-нибудь находится между клиентом и сервером и наблюдает за соединением – он все равно не сможет узнать ни закрытый ключ клиента, ни закрытый ключ сервера, ни секретный ключ сессии.

Как это возможно? Математика!

Алгоритм Ди́ффи — Хе́ллмана

Одним из наиболее распространенных подходов является алгоритм обмена ключами Ди́ффи — Хе́ллмана (DH). Этот алгоритм позволяет клиенту и серверу договориться по поводу общего секретного ключа, без необходимости передачи секретного ключа по соединению. Таким образом, злоумышленники, прослушивающие канал, не смогу определить секретный ключ, даже если они будут перехватывать все пакеты данных без исключения.

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

Немного математики…

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

Пусть Алиса и Боб – две стороны, осуществляющие обмен ключами по DH-алгоритму. Сперва они договариваются о некотором основании root (обычно маленьком числе, таком как 2,3 или 5 ) и об очень большом простом числе prime (больше чем 300 цифр). Оба значения пересылаются в открытом виде по каналу связи, без угрозы компрометировать соединение.

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

По каналу связи же передается смесь mixture, полученная из закрытых ключей, а также значений prime и root.

Таким образом:
Alice’s mixture = (root ^ Alice’s Secret) % prime
Bob’s mixture = (root ^ Bob’s Secret) % prime
где % — остаток от деления

Таким образом, Алиса создает свою смесь mixture на основе утвержденных значений констант (root и prime), Боб делает то же самое. Как только они получили значения mixture друг друга, они производят дополнительные математические операции для получения закрытого ключа сессии. А именно:

Вычисления Алисы
(Bob’s mixture ^ Alice’s Secret) % prime

Вычисления Боба
(Alice’s mixture ^ Bob’s Secret) % prime

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

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

Обратите внимание как начальный цвет (желтый) в итоге превращается в один и тот же “смешанный” цвет и у Боба, и у Алисы. Единственное, что передается по открытому каналу связи так это наполовину смешанные цвета, на самом деле бессмысленные для любого прослушивающего канал связи.

Симметричное шифрование

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

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

Аутентификация

Алгоритм Диффи-Хеллмана позволяет двум сторонам получить закрытый секретный ключ. Но откуда обе стороны могут уверены, что разговаривают действительно друг с другом? Мы еще не говорили об аутентификации.

Что если я позвоню своему приятелю, мы осуществим DH-обмен ключами, но вдруг окажется, что мой звонок был перехвачен и на самом деле я общался с кем-то другим?! Я по прежнему смогу безопасно общаться с этим человеком – никто больше не сможет нас прослушать – но это будет совсем не тот, с кем я думаю, что общаюсь. Это не слишком безопасно!

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

Но, на самом деле, что это за сертификат, и как он предоставляет нам безопасность?

Сертификаты

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

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

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

Чтобы сертификату доверял любой веб-браузер, он должен быть подписан аккредитованным удостоверяющим центром (центром сертификации, Certificate Authority, CA). CA – это компании, выполняющие ручную проверку, того что лицо, пытающееся получить сертификат, удовлетворяет следующим двум условиям:

1. является реально существующим;
2. имеет доступ к домену, сертификат для которого оно пытается получить.

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

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

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

Прочие вещи которые нужно знать о сертификатах

Расширенная валидация

В дополнение к обычным X.509 сертификатам, существуют Extended validation сертификаты, обеспечивающие более высокий уровень доверия. Выдавая такой сертификат, CA совершает еще больше проверок в отношении лица, получающего сертификат (обычно используя паспортные данные или счета).

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

Обслуживание множества веб-сайтов на одном сервере

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

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

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

Примечания переводчика:

1)Спасибо хабраюзеру wowkin за отличную ссылку по теме (видео переведено и озвученно хабраюзером freetonik):

2) По результатам развернувшейся в коменатариях дискуссии (спасибо за участие хабраюзерам a5b, Foggy4 и Allen) дополняю основную статью следующей информацией:

По данным netcraft на базе свежего SSL survey (2.4 млн SSL сайтов, июнь 2013), большинство SSL соединений не используют Perfect forward secrecy алгоритмы: news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html

Особенно ситуация плоха в случае с IE (даже 10 версии), который поддерживает Диффи-Хеллмана только на эллиптических кривых (RSA и ECDSA сертификаты), либо классический Диффи-Хеллман с более редкими сертификатами DSS (DSA).
По подсчетам netcraft 99,7 % соединений с IE и по 66% — с Chrome, Opera и Firefox не будут использовать Диффи-Хеллмана.

На Hacker News в обсуждении это тоже заметили.

Also (and I made the same mistake in my talk…), yes, explaining DH is important, but now it kind of sounds like in TLS both sides figure out the master secret using DH (and, in your talk, specifically, regular DH, not EC-based DH), when in reality that depends on the ciphersuite, and the vast majority of TLS connections don’t work that way. From what I understand to be most TLS configurations in the wild, the pre-master secret is encrypted using the server’s public key. (RFC 5246: 7.4.7.1, 8.1.1)
это важно и интересно, но не все понимают что он в реальности применяется не так часто. В большинстве сеансов SSL и TLS действительно обмен ключей происходит путем их шифрования с помощью RSA.

В чем разница и отличие протоколов http и https

Приветствую всех, с Вами автор блога matrixblog.ru. Сегодня мы рассмотрим, в чем отличие протоколов http и https. Формально, ответ на данный вопрос очень простой – между http и https разница заключается лишь в том, что один протокол (http) не использует шифрование, а другой (https) – использует шифрование передаваемых данных.

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

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

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

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

Для интернете ситуация аналогичная – мы вводим адрес сайта, видим его содержимое, если ничего не показывается, то или интернет отсутствует, или сайт не доступный.

Как это не обидно, но большинство людей, словно собачки Павлова – реагируют на или иные сигналы.

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

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

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

Если разница между http и https состоит лишь в шифровании передаваемых данных, то почему не использовать всегда https, и почему данный протокол не использовали сразу?

В первую очередь, определимся с тем, что интернет протоколов много. Протоколы являются своеобразным набором правил, описание которых можно найти в документации RFC. Согласно этим правилам происходит передача разного типа информации – для электронной почты одни правила, для сайтов другие и так далее. Есть ещё порты, которые тесно связаны с интернет протоколами, так, http протокол использует порт под номером 80, а https – 443 порт.

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

Ладно, со вступлением закончили, перейдем теперь к сути статьи – какая разница между http и https протоколом.

 

Какая между http и https разница

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

Введя адрес веб-сайта, мы не всегда задумываемся над сочетаниями и комбинациями букв, которые приводятся в поле поиска. Оказывается, однако, что «http» и «https» это очень важно с точки зрения поиска и позиционирования сайта.

 

Протокол http

Протокол http (сокращение от английского Hypertext Transfer Protocol) — это протокол, обеспечивающий передачу гипертекстовых данных по сети интернет.

Http используется уже с 90-х годов XX века для осуществления связи между клиентом и сервером. Изначально можно было отправлять один запрос и получать данные в рамках одного соединения. Передаваемые данные не имели большого веса и размера. Добавление этого протокола в соответствии с форматом MIME привело к тому, что передача больших объемов данных, в виде дополнения, основанных на различных параметрах, стала возможной.

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

 

Протокол https

Рассматривая разницу между протоколами http и https, мы должны также смотреть на версию https. Hypertext Transfer Protocol Secure — это зашифрованная версия протокола http. В отличие от своей нешифрованной версии, где связь появляется между клиентом и сервером без использования специальных настроек отправляющего запроса, протокол https шифрует данные. Сначала это происходило с помощью протокола SSL. В настоящее время используется протокол TLS. Их использование позволяет избегать ситуации, перехвата данных и их возможного изменения.

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

 

Отличие http от https

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

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

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

 

Влияет ли разница между http и https протоколами на позиции сайта

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

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

Простым языком об HTTP / Habr

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

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

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.

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

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

Также HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».

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

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

Как отправить HTTP-запрос?

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

Предположим, что он ввёл в адресной строке следующее:

http://alizar.habrahabr.ru/

Соответственно вам, как веб-браузеру, теперь необходимо подключиться к веб-серверу по адресу alizar.habrahabr.ru.

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

telnet alizar.habrahabr.ru 80

Сразу уточню, что если вы вдруг передумаете, то нажмите Ctrl + «]», и затем ввод — это позволит вам закрыть HTTP-соединение. Помимо telnet можете попробовать nc (или ncat) — по вкусу.

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

Для того, чтобы сформировать HTTP-запрос, необходимо составить стартовую строку, а также задать по крайней мере один заголовок — это заголовок Host, который является обязательным, и должен присутствовать в каждом запросе. Дело в том, что преобразование доменного имени в IP-адрес осуществляется на стороне клиента, и, соответственно, когда вы открываете TCP-соединение, то удалённый сервер не обладает никакой информацией о том, какой именно адрес использовался для соединения: это мог быть, например, адрес alizar.habrahabr.ru, habrahabr.ru или m.habrahabr.ru — и во всех этих случаях ответ может отличаться. Однако фактически сетевое соединение во всех случаях открывается с узлом 212.24.43.44, и даже если первоначально при открытии соединения был задан не этот IP-адрес, а какое-либо доменное имя, то сервер об этом никак не информируется — и именно поэтому этот адрес необходимо передать в заголовке Host.

Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:

Метод URI HTTP/Версия

Например (такая стартовая строка может указывать на то, что запрашивается главная страница сайта):

GET / HTTP/1.1

Метод (в англоязычной тематической литературе используется слово method, а также иногда слово verb — «глагол») представляет собой последовательность из любых символов, кроме управляющих и разделителей, и определяет операцию, которую нужно осуществить с указанным ресурсом. Спецификация HTTP 1.1 не ограничивает количество разных методов, которые могут быть использованы, однако в целях соответствия общим стандартам и сохранения совместимости с максимально широким спектром программного обеспечения как правило используются лишь некоторые, наиболее стандартные методы, смысл которых однозначно раскрыт в спецификации протокола.

URI (Uniform Resource Identifier, унифицированный идентификатор ресурса) — путь до конкретного ресурса (например, документа), над которым необходимо осуществить операцию (например, в случае использования метода GET подразумевается получение ресурса). Некоторые запросы могут не относиться к какому-либо ресурсу, в этом случае вместо URI в стартовую строку может быть добавлена звёздочка (астериск, символ «*»). Например, это может быть запрос, который относится к самому веб-серверу, а не какому-либо конкретному ресурсу. В этом случае стартовая строка может выглядеть так:

OPTIONS * HTTP/1.1

Версия определяет, в соответствии с какой версией стандарта HTTP составлен запрос. Указывается как два числа, разделённых точкой (например 1.1).

Для того, чтобы обратиться к веб-странице по определённому адресу (в данном случае путь к ресурсу — это «/»), нам следует отправить следующий запрос:

GET / HTTP/1.1
Host: alizar.habrahabr.ru

При этом учитывайте, что для переноса строки следует использовать символ возврата каретки (Carriage Return), за которым следует символ перевода строки (Line Feed). После объявления последнего заголовка последовательность символов для переноса строки добавляется дважды.

Впрочем, в спецификации HTTP рекомендуется программировать HTTP-сервер таким образом, чтобы при обработке запросов в качестве межстрочного разделителя воспринимался символ LF, а предшествующий символ CR, при наличии такового, игнорировался. Соответственно, на практике бо́льшая часть серверов корректно обработает и такой запрос, где заголовки отделены символом LF, и он же дважды добавлен после объявления последнего заголовка.

Если вы хотите отправить запрос в точном соответствии со спецификацией, можете воспользоваться управляющими последовательностями \r и \n:

echo -en "GET / HTTP/1.1\r\nHost: alizar.habrahabr.ru\r\n\r\n" | ncat alizar.habrahabr.ru 80

Как прочитать ответ?

Стартовая строка ответа имеет следующую структуру:

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

Версия протокола здесь задаётся так же, как в запросе.

Код состояния (Status Code) — три цифры (первая из которых указывает на класс состояния), которые определяют результат совершения запроса. Например, в случае, если был использован метод GET, и сервер предоставляет ресурс с указанным идентификатором, то такое состояние задаётся с помощью кода 200. Если сервер сообщает о том, что такого ресурса не существует — 404. Если сервер сообщает о том, что не может предоставить доступ к данному ресурсу по причине отсутствия необходимых привилегий у клиента, то используется код 403. Спецификация HTTP 1.1 определяет 40 различных кодов HTTP, а также допускается расширение протокола и использование дополнительных кодов состояний.

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

После стартовой строки следуют заголовки, а также тело ответа. Например:

HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Sat, 08 Mar 2014 22:53:46 GMT
Content-Type: application/octet-stream
Content-Length: 7
Last-Modified: Sat, 08 Mar 2014 22:53:30 GMT
Connection: keep-alive
Accept-Ranges: bytes

Wisdom

Тело ответа следует через два переноса строки после последнего заголовка. Для определения окончания тела ответа используется значение заголовка Content-Length (в данном случае ответ содержит 7 восьмеричных байтов: слово «Wisdom» и символ переноса строки).

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

Смотрите сами:

HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Sat, 08 Mar 2014 22:29:53 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
Keep-Alive: timeout=25
Location: http://habrahabr.ru/users/alizar/

<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h2>302 Found</h2></center>
<hr><center>nginx</center>
</body>
</html>

В заголовке Location передан новый адрес. Теперь URI (идентификатор ресурса) изменился на /users/alizar/, а обращаться нужно на этот раз к серверу по адресу habrahabr.ru (впрочем, в данном случае это тот же самый сервер), и его же указывать в заголовке Host.

То есть:

GET /users/alizar/ HTTP/1.1
Host: habrahabr.ru

В ответ на этот запрос веб-сервер Хабрахабра уже выдаст ответ с кодом 200 и достаточно большой документ в формате HTML.

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

А что с безопасностью?

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

Название этого расширения — HTTPS (HyperText Transfer Protocol Secure). Для HTTPS-соединений обычно используется TCP-порт 443. HTTPS широко используется для защиты информации от перехвата, а также, как правило, обеспечивает защиту от атак вида man-in-the-middle — в том случае, если сертификат проверяется на клиенте, и при этом приватный ключ сертификата не был скомпрометирован, пользователь не подтверждал использование неподписанного сертификата, и на компьютере пользователя не были внедрены сертификаты центра сертификации злоумышленника.

На данный момент HTTPS поддерживается всеми популярными веб-браузерами.

А есть дополнительные возможности?

Протокол HTTP предполагает достаточно большое количество возможностей для расширения. В частности, спецификация HTTP 1.1 предполагает возможность использования заголовка Upgrade для переключения на обмен данными по другому протоколу. Запрос с таким заголовком отправляется клиентом. Если серверу требуется произвести переход на обмен данными по другому протоколу, то он может вернуть клиенту ответ со статусом «426 Upgrade Required», и в этом случае клиент может отправить новый запрос, уже с заголовком Upgrade.

Такая возможность используется, в частности, для организации обмена данными по протоколу WebSocket (протокол, описанный в спецификации RFC 6455, позволяющий обеим сторонам передавать данные в нужный момент, без отправки дополнительных HTTP-запросов): стандартное «рукопожатие» (handshake) сводится к отправке HTTP-запроса с заголовком Upgrade, имеющим значение «websocket», на который сервер возвращает ответ с состоянием «101 Switching Protocols», и далее любая сторона может начать передавать данные уже по протоколу WebSocket.

Что-то ещё, кстати, используют?

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

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

Опубликованный в ноябре 2012 года черновик спецификации протокола HTTP 2.0 (следующая версия протокола HTTP после версии 1.1, окончательная спецификация для которой была опубликована в 1999) базируется на спецификации протокола SPDY.

Многие архитектурные решения, используемые в протоколе SPDY, а также в других предложенных реализациях, которые рабочая группа httpbis рассматривала в ходе подготовки черновика спецификации HTTP 2.0, уже ранее были получены в ходе разработки протокола HTTP-NG, однако работы над протоколом HTTP-NG были прекращены в 1998.

На данный момент поддержка протокола SPDY есть в браузерах Firefox, Chromium/Chrome, Opera, Internet Exporer и Amazon Silk.

И что, всё?

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

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

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

Удачи и плодотворного обучения!

Что лучше использовать для SEO-продвижения: HTTP или HTTPS?

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

Получи нашу книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Подпишись на рассылку и получи книгу в подарок!

Влияние HTTPS на продвижение

Более 50% веб-страниц, загружаемых Firefox, обслуживаются через защищенное соединение. Во многом это связано с тем, что Google устроил крестовый поход против незашифрованного веб-трафика, и в последние полгода число доменов, использующих HTTPS, резко пошло вверх. Давайте выясним, такой ли уж страшный монстр этот HTTPS и может ли он сделать что-то полезное для вашего веб-сайта.

Переход на HTTPS: защищай знамя до последнего

Google объявил, что HTTPS является сигналом ранжирования еще в 2014 году.  С тех пор в SEO-сообществе не утихают обсуждения перспектив этого шага. На данный момент довольно много вебмастеров перевели свои сайты с HTTP на HTTPS, и у нас даже есть несколько примеров, которые доказывают, что повышение безопасности соединения приводит к ощутимым выгодам в области SEO.

Перейдем к делу.

Потребность в обновлении протокола HTTP появилась в 2010 году, когда под давлением угроз безопасности персональной информации Google решил перевести всю свою выдачу на HTTPS. Со временем стало очевидно, что практика шифрования регулярных страниц контента действительно прижилась. В немалой степени позитивной реакции на нововведение способствовал всплеск активности в области распространения вредоносного ПО – в тот период появилась программа Snooper (аудио шпион для персонального компьютера). Любой из имевших доступ к программе Snooper мог контролировать деятельность других людей в интернете. С помощью Snooper осуществлялся незаконный сбор чужих паролей, в связи с чем процент жертв шантажа в области бизнеса и политической деятельности заметно увеличился.

Вот почему Google и другие крупные организации разработали программу перевода большей части Всемирной паутины на протокол HTTPS. Google планировал несколько тактик ведения войны с незащищенными сайтами.

Какое влияние HTTPS оказывает на продвижение

Одно из последствий борьбы за переход к новому соединению – оказание влияния на посетителя небезопасных сайтов. Так, версия браузера Google Chrome 56 предупреждает пользователей (хотя и достаточно тонко, ненавязчиво) об опасности, когда они собираются ввести данные для входа через незащищенное соединение. Чтобы мотивировать владельцев сайтов к переводу веб-ресурсов на новый протокол Google даже прибегал к своеобразной тактике – пристыжению.  Так появилась публикация со списком популярных сайтов с безопасным соединением и с небезопасным.

Уйдем немного в сторону от безопасности. В конце концов, то,  что действительно заботит веб-мастеров, так это вопрос: действительно ли переход сайта на новый тип соединения позволит почувствовать ощутимую разницу в продвижении. И ответ – да, перевод сайта на HTTPS окажет позитивное влияние на SEO.

Влияние HTTPS на продвижение: действительно ли протокол – сигнал ранжирования

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

Какое влияние HTTPS оказывает на продвижение

Другой золотой самородок для нашего исследования – данные, полученные с помощью MOZ и их знаменитого трекера 10 000 ключевых слов. Они отслеживали HTTPS в качестве сигнала ранжирования на протяжении нескольких последних лет. Еще в 2014 г. только 7% выдачи с первой страницы результатов поиска Google были на безопасном протоколе. Если перенестись в наше время, то, согласно кейс-стади по SEO, проведенному в июле 2016, доля сайтов с поддержкой HTTPS на первой странице выдаче поднялась до 32,5%.

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

Сложен ли переход на HTTPS?

Нет, если вы знаете, что делаете. В прошлом это было дорого и утомительно. Вместе с исследованием «Давайте шифровать» Let’s Encrypt начала предоставлять бесплатные сертификаты TLS. Помимо них появилось множество других хостинговых компаний, предлагающих своим клиентам установку сертификата TLS в два клика. С помощью такой помощи обслуживать сайт на HTTPS стало намного проще.

Трюк в том, что после того, как ваш сайт получает зеленый замочек в адресной строке, игра не заканчивается. Если вы просто оставите все как есть, велик шанс, что вы своим переездом на HTTPS создадите больше проблем в SEO, чем у вас было. Это означает, что любой потенциальный прирост рейтинга из сертификата TLS будет быстро обесцениваться из-за накопленных технических вопросов, которые вы не решили на своем сайте.

Все внутренние абсолютные пути должны быть скорректированы вручную. Вы должны убедиться в том, что настроили редирект с HTTP на HTTPS должным образом, изменили настройки в Analytics, Search Console. И это только верхушка айсберга.

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

Выводы

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

Ирина Винниченко

Контент-маркетолог SEMANTICA

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

Да. Но нужно иметь в виду некоторые нюансы.

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

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

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

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

Что остается? Пользовательский опыт, недооценивать который не стоит вне зависимости от сайта. Это опосредованный фактор влияния на SEO, который обязательно нужно учитывать.

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

Переход на https, что такое протокол https и чем он отличается от http

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

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

Starting January 2017, Chrome 56 will label HTTP pages with password or credit card form fields as «not secure»

(С января 2017, Хром 56 будет помечать HTTP страницы с полями для ввода пароля или данных кредитных карт как «небезопасные»)

Первый лагерь сразу заявил — мол, это касается только страниц, где требуется оплата. Статейникам и сайтам без онлайн-оплаты на это плевать. А второй лагерь обратил внимание на эту цитату:

we plan to label all HTTP pages as non-secure

(Мы планируем помечать все HTTP страницы как небезопасные)

Теперь надо думать, как перейти на https. Но давайте с самого начала и до самого конца разберемся.

Что такое https

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

Вот его отличия:

  • https – расширенный протокол передачи данных;
  • https посылает серверу от вас и обратно зашифрованные данные;
  • https работает с 443 TCP-портом, а не с 80.

Если на сайте нет https, то теоретически любой дурак может при вашем подключении к публичному Wi-Fi перехватить данные, которые вы вводите на этом сайте.

Почему сегодня важно делать сайты на https

Ну во-первых, ради безопасности данных пользователей — их паролей от соцсетей, онлайн-кошельков, кодов кредиток и так далее. Обеспечивает безопасность ssl-сертификат, включенный в новую версию протокола.
А из этого уже вытекает во-вторых: ради обеспечения будущего своего бизнеса. Как видите, заявление Гугла многих взбудоражило и дало понять: будущее за https. И вам в итоге придется перейти на этот протокол, если хотите получать больше трафика из поисковиков.

Поисковики обеспечивают коммерческим сайтам приток новых клиентов. Большая часть коммерческих сайтов уже отказалась от http в пользу https из-за заявления, сделанного компанией «Google».

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

На деле успешно перешедших на https тогда ждал рост в 5% с Гугла, а неуспешно перешедших — вылет сайта из индекса обоих поисковиков и другие неприятности.

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

Можно ли избавиться от фильтров, если перевести сайт на https

Переход на https может снять фильтр АГС Яндекса. Вот таким макаром:

  1. Сначала надо выяснить, в чем была причина наложения АГС;
  2. Убрать эту причину;
  3. Перевести сайт на https;
  4. Дождаться переиндексации.

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

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

SSL-сертификаты делят на доверительные (Trusted — выданные специальными центрами) и недоверительные (Self-Signed — сгенерированные самостоятельно), стандартные (Standard — для одного домена) и групповые (WildCard сертификат — для домена и его поддоменов), индивидуальные (Private — на один домен) и общие (Shared — на несколько сайтов).

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

На Бегете можно бесплатно получить SSL-сертификат от компании Let’s Encrypt, прямо через панель управления. Можно и получить этот сертификат через сайт компании: https://letsencrypt.org/.

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

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

Вот как купить этот сертификат на рег.ру:

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

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

Во-первых: сделайте бекап, будьте ж вы людьми, всегда вам говорю.

Бекап — всему голова. С ним будете увереннее. Как настоящий альфа самец будете переносить сайт на https.

Потом подумайте, что у вас — Вордпресс или другая система управления сайтом. Посмотрите видосы, как переносить конкретно вашу систему на https, когда купите и поставите SSL-сертификат. Короче, подойдите во всеоружии. Быть может, имеет смысл сменить все ссылки в ссылочной структуре сайта на относительные. Может быть, надо посмотреть, откуда подгружаются медиафайлы — может, они запрашиваются по протоколу http.

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

Весь переезд на https можно разделить на шесть этапов.

  1. Подготовка;
  2. Установка SSL-сертификата;
  3. Настройка сайта/смена его ссылок с http на https;
  4. Настройка 301 редиректа;
  5. Уведомление поисковых систем о переезде;
  6. Через какое-то время — удаление из индекса поисковых систем старых страниц на http, если таковые остались.

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

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

Затем прописываете редирект (позже в статье будет указано, какие коды и куда вписывать). И проверяйте, все ли корректно работает:

  • Открывается ли сайт по адресу с https;
  • Перебрасывает ли вас на https страницы со страниц с http;
  • Указаны ли в коде сайта ссылки с https.

Ну а после этого, если все точно работает хорошо и вы семь раз отмерили, пора один раз отрезать — уведомить поисковики, что мы окончательно перешли на https. Тут я бы сделал следующие шаги:

  1. Прописал бы ссылки с https в файле robots.txt, особенно это касается директивы Host и сайтмапа;
  2. Зашел бы в панели вебмастера Яндекса и Гугла и добавил бы туда версию с https;
  3. После этого там же настроил бы новое основное зеркало;
  4. Можно еще попробовать «скормить» как можно больше страниц инструментам «Переобход страниц» и «Просмотреть как Googlebot».

Ну и, наконец, придется проверить и другие нюансы, такие как настройка региона и путь к файлу Sitemap.

Какие могут быть проблемы при переходе

Ну, ТиЦ потеряете скорее всего. Ссылки, стоявшие на вас, будут из-за редиректа передавать не весь вес. Некоторые плагины могут отказаться работать на https. Некоторые способы монетизации — тоже. А главное — если что-то сделано не так, ваш сайт может вылететь из индекса. Даже если все сделано правильно — первое время в выдаче могут быть дубли страниц (одна страница с http и вторая такая же с https). И их нужно будет удалять с помощью соответствующего инструмента в панелях Яндекс Вебмастера и Гугл Вебмастера.

Как настроить 301 редирект на версию с https

Чтобы настроить перенаправление с http на https, необходимо добавить в файл .htaccess (лежащий в корне сайта) директиву:

RewriteCond %{SERVER_PORT} ^80$ [OR] RewriteCond %{HTTP} =on RewriteRule ^(.*)$ https://domain.ru/$1 [R=301,L]

RewriteCond %{SERVER_PORT} ^80$ [OR]

RewriteCond %{HTTP} =on

RewriteRule ^(.*)$ https://domain.ru/$1 [R=301,L]

Как настроить 301 редирект на версию с http

Чтобы настроить переадресацию на http, необходимо добавить в .htaccess эту директиву:

RewriteCond %{HTTPS} «on» RewriteRule .* http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L,QSA]

RewriteCond %{HTTPS} «on»

RewriteRule .* http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L,QSA]

Вот как как изменить https на http.

Кстати, если у вас сайт на http и вы не собираетесь делать сайт на https, рекомендую вам сделать этот редирект. Чтобы в индекс поисковиков не попадали дубли с https.

Заключение

Короче, слушайте СУТЬ. ЕСТЬ смысл ставить протокол https уже сейчас для коммерческих сайтов с онлайн-оплатой. Для остальных пока что нет (пишу в конце 2016), но возможно уже года через полтора все будут запускаться только на https. Вот тогда и будем думать. Потому что сейчас всех условий для полноценного перехода на https нет. Многие вебмастера отмечают трудности с монетизацией сайтов на https, потому что не все партнерки, тизерки и так далее готовы к работе с этим протоколом.

Author: admin

Добавить комментарий

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