Поисковые системы прямо заявляют, что отдают предпочтение в выдаче сайтам, которые работают с HTTPS-протоколом вместо HTTP (без S). Что это за протоколы, и почему поисковики так стимулируют к переходу с одного на другой? Какая между ними разница и стоит ли прислушаться к доводам гигантов IT-рынка? Обо всём этом максимально подробно ниже.
Что такое HTTP и HTTPS (немного теории)
Всё, что вы видите в интернете, начиная от страниц поисковых систем и заканчивая видео в любимом онлайн-сервисе – это данные, которые передаются по глобальной сети. Мы называем её Интернет. Хотя на самом деле – это огромное количество разрозненных локальных сетей, которые объединяются в одну только благодаря стеку технологий и протоколов TCP/IP. В этот стек входит много разных протоколов, например, FTP (используется для передачи файлов), SMTP и POP3 (протоколы для работы с электронной почтой), но самым востребованным можно назвать HTTP.
HTTP – это протокол для передачи гипертекста (аббревиатура образована от англ. слов Hyper Text Transfer Protocol). С этим протоколом мы сталкиваемся каждый день, когда открываем браузер. Ведь гипертекст – это знакомые всем нам web-страницы.
HTTPS – это специальная надстройка для протокола HTTP, которая позволяет использовать механизмы шифрования при обмене данными между сервером и браузером. То есть любой сайт, который работает с HTTP может перейти на HTTPS, для этого достаточно только правильно настроить существующий сервер и подключить к нему механизм шифрования.
В чём разница между HTTP и HTTPS
Как можно было догадаться из определений, основное отличие простого HTTP от шифрованного HTTPS – это защита передаваемых данных. Если при использовании классического HTTP данные передаются в открытом виде, то при передаче по HTTPS данные надёжно шифруются, причём, чтобы никто не мог подменить ключи шифрования, они «заверяются» ключами доверенных организаций, которые уполномочены выдавать такие «разрешения».
Получается двойной контроль: вы можете сгенерировать свой ключ шифрования и подключить его к своему сайту, но пока вы его не заверите «подписью» (это так называемый «сертификат» ключа) в специальном Центре сертификации, браузер не сможет ему доверять и будет показывать сообщение о потенциальной опасности. Подменить подписанный ключ, минуя контроль, нельзя.
Преимущества использования HTTPS
Что даёт использование HTTPS вместо HTTP-протокола? В первую очередь – это безопасность конечных пользователей. Так как Интернет – это «сеть сетей», то сложно контролировать безопасность отдельных её участков. Всегда есть вероятность, что кто-то целенаправленно будет «слушать» весь ваш трафик и сможет использовать полученные данные в своих корыстных целях. Например, кто-то сможет похитить ваши пароли, когда они будут передаваться в открытом виде на сервер, или провайдер сможет «подмешать» в код сайта свою рекламу, и т.д.
При использовании HTTPS браузер шифрует данные ещё до момента передачи по открытому каналу, поэтому, даже если их и перехватят, то прочесть не смогут, ведь нужно иметь на руках вторую часть ключа (закрытый ключ), которая хранится только на сервере.
HTTPS и SEO-оптимизация
Почему Google и Яндекс в один голос заговорили о повышении позиций сайтов, работающих с HTTPS? Всё очень просто. Они потенциально безопаснее для своих пользователей, особенно, если сайты работают с какими-либо персональными данными. А какие сайты сейчас не принимают никаких данных от клиентов (номеров телефона, email-адресов, данных банковских карт и т.п.)? Таких единицы.
Чтобы стимулировать к переходу на безопасный протокол, IT-гиганты принимают кардинальные меры: например, все современные версии браузеров специальным образом оповещают пользователей о небезопасности соединения прямо в строке адреса.
Не заметить такое просто невозможно. Как поведёт себя пользователь, который увидит это при открытии вашего сайта? Правильно, он просто покинет его и продолжит поиск более безопасных страниц.
Все преимущества
Из всего вышесказанного можно сформулировать основные преимущества использования HTTPS:
- Повышение безопасности и конфиденциальности.
- Повышение позиций в поисковой выдаче (при прочих равных показателях сайтов).
- Повышение лояльности пользователей (они будут знать, что соединение защищено, браузер им в этом поможет).
- Улучшение поведенческих факторов (никто не будет покидать ваш сайт из-за предупреждения об опасности).
Обратите внимание, для поисковых систем HTTP и HTTPS – это разные версии сайтов.
Недостатки HTTPS
Было бы нечестно не упомянуть об обратной стороне медали. Из минусов HTTPS выделим основные:
- Сервер нужно перенастроить. Если нет панели управления или поддержки готовых решений по интеграции сертификатов шифрования, то понадобятся специальные знания и навыки, чтобы сделать это самостоятельно. Конечно, всегда можно нанять профильного специалиста.
- Шифрование данных так или иначе повышает нагрузку на сервер и увеличивает время отклика сайта, так как ему требуется больше времени на обработку запросов.
- Сгенерировать SSL/TLS-сертификат можно хоть самому, но он не станет доверенным, пока его не заверит специальная организация. Доверенные сертификаты в большинстве своём платные. Они бывают разных видов (выдаются на домен, на несколько связанных доменов или на организацию), но в любом случае, это дополнительные расходы на содержание сайта.
- Есть бесплатные альтернативы, например, от Let’s Encrypt, но они выдаются на короткий промежуток времени и требуют частой замены.
- После полного перехода с HTTP на HTTPS сайт может «вылететь» из поисковой выдачи до тех пор, пока не будет проиндексирована версия HTTPS.
- Нужно помнить, что технология HTTPS строится на базе практически не дешифруемого алгоритма. Это значит, что нужно слишком много времени и ресурсов, чтобы взломать защиту на практике. Но, например, изобретение и внедрение квантовых компьютеров может резко изменить ситуацию – они смогут обеспечить техническую реализацию полного перебора и взлома ключа.
Как перейти на HTTPS
Для начала работы как минимум нужно получить валидный SSL/TLS-сертификат у уполномоченных организаций. Если это платные сертификаты, то их можно заказать через сеть партнёров удостоверяющих центров. В качестве таких партнёров часто выступают хостинг-провайдеры. А можно обратиться к уполномоченной организации напрямую.
Когда необходимые файлы сгенерированы, подписаны ключом удостоверяющего центра и получены, их необходимо загрузить на сервер. Причём, сам сервер нужно перенастроить, чтобы данные передавались через специальный порт и зашифровались/расшифровывались.
Чтобы браузер не показывал предупреждения о смешанном контенте, все ссылки на странице, как на собственные ресурсы, так и на сторонние сайты, начинались с HTTPS (возможно, придётся обновить базу данных, поправить ссылки в шаблонах и/или в HTML-файлах, скриптах, настроить специальный редирект).
Что такое SSL-сертификат
Вообще-то, современные браузеры и сайты используют более актуальные и надёжные TLS-сертификаты, а не SSL. Но и те, и другие имеют одну и ту же цель – шифрование соединений между браузером и сервером сайта (сайтом). Термин SSL остался в обиходе в угоду привычкам клиентов.
TLS и SSL – это технологии защищённого обмена данными. А TLS- и SSL-сертификаты – это открытые ключи шифрования, с помощью которых данные преобразуются в нечитаемый для злоумышленников вид (шифруются).
Как работает TLS/SSL-защита:
- Клиент устанавливает подключение к серверу. Обе стороны согласовывают между собой поддерживаемые алгоритмы шифрования. Обычно это ассиметричное RSA-шифрование или протокол Диффи-Хелмана (на базе постоянных или разовых сессионных ключей).
- Когда протоколы согласованы, сервер отправляет клиенту свой TLS/SSL-сертификат, который включает в себя открытый ключ, имя сервера и название удостоверяющего центра (того, который подписал этот ключ).
- Клиент (в данном случае браузер) проверяет валидность предоставленного ему сертификата. Сделать это он может двумя способами:
- на основе установленных в операционной системе сертификатов корневых удостоверяющих центров (сертификаты устанавливаются или самой операционной системой, или добавляются пользователями вручную).
- на основе проверки сертификата напрямую у известных браузеру удостоверяющих центров.
- Когда сертификат подтверждён, браузер генерирует общий сессионный ключ по алгоритму Диффи-Хелмана и на нём зашифровывает и расшифровывает данные, которыми дальше обменивается с сервером (сайтом).
- Алгоритмы генерации общего секрета (ключа) и у сервера, и у клиента одинаковые, ведь они их согласовали при установке соединения, поэтому браузер «понимает», какие данные ему передаёт сайт (сервер).
Если кто-то попытается перехватить данные посередине, уже в процессе их передачи от сервера к браузеру или обратно, то злоумышленник ничего не сможет понять, кроме основных заголовков TCP/IP-пакетов. Всё содержимое будет зашифровано. А так как злоумышленник не знает общего секрета, на основе которого шифровались данные, то и расшифровать их обратно он не сможет (для этого нужно знать ещё и закрытую часть ключа).
Центр сертификации – это важная третья сторона, через которую можно безопасно обмениваться второй (закрытой) частью ключа. Для понимания: в процессе генерации общего секрета есть как минимум 2 составляющие: открытый (видимый всем) ключ, он выступает в роли своего рода идентификатора, и закрытый (его знают только участники обмена).
Если сгенерировать свой TLS/SSL-сертификат вручную, то браузер не сможет его проверить в удостоверяющем центре. Соответственно, браузер выдаст предупреждение о том, что соединение небезопасно.
Как итог. TLS/SSL-сертификат – это одновременно ключ и набор данных для идентификации сервера, а также удостоверяющего центра, который выдал его выдал (подтвердил).
Какие именно данные содержатся в SSL/TLS-сертификате (при желании их можно узнать в специальном интерфейсе браузера «Безопасное подключение» или в сторонних сервисах для проверки):
- Информация о том, кому выдан сертификат (сайт и/или компания, владеющая им, для каких доменов действует).
- Информация об удостоверяющем центре (кем выдан сертификат).
- Срок действия (когда истечёт право его использования).
- Подробная информация для идентификации самого сертификата (серийный номер, дата выдачи, алгоритм подписи, идентификатор, отпечатки по SHA-1/SHA-256, подпись центра сертификации и т.п.).
Виды SSL-сертификатов
Обычно сертификаты шифрования классифицируют по уровню защиты (уровню доверия):
- EV SSL (Extended Validation SSL) – сертификаты с расширенной защитой. Наиболее дорогие, но при этом самые «трастовые» для браузеров (а значит и для клиентов сайта/веб-сервиса). При выдаче такого сертификата удостоверяющий центр проверяет все данные о клиенте, которые могут потребоваться для его идентификации. Плюс, запрашивается подтверждение официальных прав на владение доменами, для которых выдаётся сертификат (как минимум сверяются сведения из Who-Is-запросов). Ранее браузеры подсвечивали EV SSL особым образом (выводили название компании рядом со значком замка), но сейчас такой подход больше не актуален – все сертификаты подсвечиваются одинаково. Доступны только юрлицам.
- OV SSL (Organization Validation SSL) – сертификаты, подтверждающие данные организации-владельца. И по степени защиты, и по проверяемым данным во многом соответствуют EV SSL-сертификатам (доступны тоже только юридическим лицам и ИП).
- DV SSL (Domain Validation SSL) – сертификаты, подтверждающие владение доменом. Реквизиты компании-владельца здесь не нужны, поэтому сертификаты могут быть выданы в том числе физлицам. Из-за отсутствия процедур проверки документов и контактных данных, VD-сертификаты выдаются максимально быстро (в течение нескольких минут), часто процесс автоматизирован.
От уровня доверия зависит и размер компенсации (страховки) в случае наступления гарантийных обязательств. Естественно, минимальный уровень доверия у DV-сертификатов.
В норме сертификаты выдаются для одного домена. Но ситуацию можно исправить, если выбрать специальные варианты услуг (опции):
- SAN/UCC-сертификаты или MDC (мультидоменные сертификаты) – могут выдаваться для нескольких разных доменов, в том числе для поддоменов основного доменного имени.
- Wildcard-сертификаты – выдаются для основного домена и его поддоменов. Например, с помощью одного сертификата можно обслуживать одновременно блог, форум, интернет-магазин и т.п., которые работают на разных движках и даже на разных серверах (у разных хостеров).
Чисто технически сертификаты мало чем отличаются друг от друга – всё это сертификаты стандарта X.509. Они выглядят одинаково и имеют одни и те же атрибуты, устанавливаются на сервер одним и тем же способом. Отличается только процедура получения и стоимость.
Где взять SSL-сертификат для сайта в зоне .ru и .рф
От обслуживания клиентов из РФ отказались многие крупнейшие поставщики сертификатов, в их числе Seсtigo (он же Comodo), DigiCert (+GeoTrust), Thawte, RapidSSL и другие. В списке даже провайдеры бесплатных SSL/TLS – ZeroSSL и Buypass.
Где можно получить работающие сертификаты для Рунета (в том числе для сайтов в зонах .ru и .рф):
- Госуслуги – услуга предоставляется только юридическим лицам, сами сертификаты выдаются бесплатно, но работают фактически только в Рунете.
- Let’s Encrypt – проверяется только владение доменом, сами сертификаты полностью бесплатные, требуют перевыпуск каждые 3 месяца, имеют глобальный охват.
- GlobalSign – компания входит в структуру японского холдинга, предлагает прямые продажи сертификатов в РФ от 9000 до 34000 руб./год (в зависимости от типа и опций). Такие же сертификаты можно приобрести через официальных партнёров (цены могут отличаться, причём как в большую, так и в меньшую сторону).
- AlphaSSL – дочерняя компания GlobalSign, цены от 49 до 149 $/год (в зависимости от типа сертификата и опций).
- FreeSSL – бесплатные и платные SSL-сертификаты от китайской компании (цены – от 102 до 1020 $/год), подходит только для работы с применением бесплатных SSL, так как нет возможности оплаты услуг с российских карт.
На рынке можно найти сертификаты и других удостоверяющих центров, которые никак не блокируют выдачу для .ru или .рф доменов, но при этом есть других нюансов. Во-первых, сертификаты выдаются компаниями, которые рассчитывают преимущественно на свой региональный (локальный) рынок. Во-вторых, будет сложно оплатить сертификат с российских банковских карт или с российских счетов (особенно это касается юрлиц). В-третьих, очень много вопросов, касающихся гарантий и исполнения обязательств, которые предполагаются в рамках любого договора с удостоверяющим центром (кто и как будет их исполнять непонятно, так как юрисдикции стран разные, а официальных партнёров или офисов в РФ у таких удостоверяющих центров нет).
Где взять бесплатные SSL-сертификаты
Первый вариант. Самый неправильный с точки зрения SEO – сгенерировать его самостоятельно. Для этого используется специальное открытое программное обеспечение. Такой сертификат может использоваться разве что для тестирования/настройки протокола HTTPS. При попытке перехода на сайт с таким сертификатом будет выдаваться предупреждение об опасности.
Отдельные удостоверяющие центры или их партнёры иногда проводят акции, в результате которых можно получить бесплатные SSL/TLS-сертификаты на ограниченное или неограниченное (с возможностью продления) время. Они будут распознаваться браузерами как положено. Но тут возможны проблемы. Так как многие удостоверяющие центры перестали обслуживать клиентов из РФ, то и бесплатные сертификаты у них будет получить невозможно.
Самый надёжный и простой способ – получить сертификат через сервис Let’s Encrypt. Правда в этом случае вам понадобится собственный сервер и установка специального программного обеспечения. Хотя многие хостинг-провайдеры позволяют получить такие сертификаты прямо из панели управления хостингом. Поэтому, если вам не нужны проблемы сразу после запуска сайта – выбирайте хостинг правильно и проверяйте возможность работы с HTTPS. Например, для сайтов WordPress отлично подойдёт HostGator, здесь безлимитные тарифы, цены – от 2,75 $/месяц, установка CMS в один клик и быстрое подключение SSL/TLS-сертификатов (от Let’s Encrypt).
Установка TLS/SSL сертификатов в CMS
Во многом процесс перехода на HTTPS-протокол будет связан с особенностями архитектуры CMS-системы. Где-то достаточно поправить конфигурационный файл или установить специальный плагин, а где-то придётся вручную обновлять все ссылки в базе данных и искать неправильные ссылки в шаблонах.
Всё очень индивидуально.
Например, WordPress сам обнаруживает доступность HTTPS-версии и предлагает переключить настройку в панели «Инструменты –> Здоровье сайта». Если встроенный мастер настройки не помогает, можно попробовать установить плагин Really Simple SSL или аналогичные расширения.
Универсальный для всех способ:
- Правильная настройка web-сервера (зависит от используемой панели, типа хостинга и самого сервера).
- Получение и установка сертификата в систему (например, это может быть автоматическое получение в панели управления хостинга, а может быть установка специального ПО на выделенном или виртуальном сервере).
- Правка всех ссылок вида http://… Во всех шаблонах и базах данных они должны начинаться с https://…
- Настройка автоматического редиректа со страниц вида http://ваш-сайт на страницы вида https://ваш-сайт (настройка редиректа будет зависеть от типа web-сервера), чтобы пользователи всегда перенаправлялись на безопасный протокол HTTPS.
Как будет выглядеть настройка web-сервера:
- Устанавливается ПО для обслуживания SSL-сертификатов на уровне операционной системы.
- Вносятся правки в конфигурационные файлы серверов (Apache, Nginx и т.п.), чтобы запросы от клиентов правильно перенаправлялись между разными портами – 443 порт для SSL/TSL, 80 порт для простых HTTP-запросов. Если используется проксирующий сервер, то настройка будет заметно сложней, но важно помнить, что сертификаты должен обслуживать основной, то есть принимающий сервер (в данном случае – проксирующий).
Пример конфигурации для Nginx (/etc/nginx/sites-enabled/ваш-сайт):
server {
listen 80; ## listen for ipv4
listen 443 ssl; # default_server;
# выше можно добавить default_server для клиентов без SNI
ssl_certificate /etc/letsencrypt/live/ВАШ-САЙТ/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/ВАШ-САЙТ/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/ВАШ-САЙТ/chain.pem;
ssl_stapling on;
ssl_stapling_verify on;
Это пример прямой правки конфигурационных файлов. Для той же задачи логично использовать хостинг-панели. Они обеспечивают работу в удобном графическом режиме.
Пример, получения SSL-сертификата через утилиту Certbot для Let’s Encrypt (консольные команды, применимы для Debian-систем, более детальные инструкции по каждой отдельной ОС смотрите в официальной документации утилиты здесь):
- Подключение по SSH.
- Установка окружения SNAP (sudo apt install snapd).
- Обновление окружения SNAP:
- sudo snap install core
- sudo snap refresh core
- Удаление старой версии сертбота (если был установлен на уровне системного пакета – sudo apt-get remove certbot).
- Установка Сертбота в виде SNAP-пакета (sudo snap install —classic certbot – тут должно быть два коротких тире перед опцией classic).
- Выбор дефолтного сервера, для которого нужно сгенерировать сертификаты и конфиги (sudo certbot —apache – тут тоже двойное короткое тире). Бот всё сделает автоматически.
- Если вы предпочитаете правку конфигов вручную, то можно просто получить сертификаты (команда sudo certbot certonly —apache).
- Чтобы бот работал в фоне и сам перевыпускал новые сертификаты, нужно добавить следующую команду в системный планировщик cron: sudo certbot renew (как минимум нужно убедиться, что команда там появилась после установки и автоматической настройки бота). Если работа планировщика вам недоступна, просто авторизуйтесь в SSH и выполняйте команду вручную.
Ручная установка платного сертификата на примере ISPmanager 6:
- Переключитесь в панели на пользователя, которому принадлежит домен/сайт. Не забудьте активировать галочку «Может управлять SSL» в правах доступа.
- Скопируйте файлы сертификата, выданные удостоверяющим центром (файл открытого ключа, обычно с расширением .crt, файл закрытого ключа, обычно с расширением .key, и цепочка сертификатов удостоверяющего центра, обычно с расширением .ca или .ctrca) на свой ПК.
- Откройте раздел панели ISPmanager «SSL-сертификаты –> Добавить сертификат».
- Выберите пункт «Существующий».
- В поля открывшейся формы нужно разложить файлы, полученные от удостоверяющего центра: SSL-Сертификат – файл или содержимое открытого ключа, Ключ SSL-сертификата – файл или содержимое закрытого ключа, Цепочка SSL-сертификатов – файл с цепочкой сертификатов УЦ. Если вам выдали отдельные файлы корневого сертификата (Root CA) и промежуточного ключа (CA — SHA256 и т.п.), то нужно открыть их в любом текстовом редакторе, скопировать содержимое и переместить в один текстовый файл, первым копируется корневой сертификат, с новой строчки – промежуточный ключ, файл нужно сохранить с расширением .ca. Если в форме есть имя ключа, можете ввести название сайта или любую другую информацию с использованием латиницы и цифр.
- Переключитесь на управление сайтом, к которому нужно привязать загруженный SSL-сертификат (пункт панели «Сайты –> ваш-сайт»).
- В строке «SSL-сертификат» в выпадающем списке выберите сертификат, который нужно связать с вашим сайтом.
- Готово. Теперь можно переходить к настройкам движка и редиректов.
Подключение SSL/TLS в онлайн-конструкторах
Многие онлайн-конструкторы предоставляют сертификаты шифрования бесплатно и подключают их к сайту автоматически. В отдельных случаях возможно подключение и использование сторонних сертификатов, например, полученных на имя организации, для большего доверия пользователей и браузеров. Алгоритм настройки использования своих ключей шифрования будет зависеть от выбранного сервиса (онлайн-конструктора).
Например, в uKit достаточно подключить свой домен или приобрести его внутри сервиса.
В uCoz можно добавить сторонние сертификаты:
- Панель управления сатом –> раздел «Безопасность» —> Пункт «Настройка SSL».
- Отметить галочку «Подключить HTTPS».
- Скопируйте и вставьте содержимое файлов, полученных от удостоверяющего центра: приватный (закрытый) ключ, сертификат (открытый ключ), промежуточный сертификат (файлы цепочки сертификатов).
Выводы
Если вы только задумываетесь о запуске своего первого сайта – обязательно настраивайте поддержку протокола HTTPS с самого начала. Это убережёт вас от массы проблем в будущем. Не нужно будет править ссылки, шаблоны и/или базу данных. Сайт будет получать лучшие позиции в выдаче и будет гарантированно безопасным для конечных пользователей.
Если ваш сайт пока ещё работает с незащищённым HTTP-протоколом, его срочно нужно переводить на HTTPS. Даже если это единственная посадочная страница или небольшой сайт-визитка. При посещении HTTP-страниц все современные браузеры предупреждают о небезопасности ресурса, что автоматически снижает лояльность клиентов, их интерес к контенту и побуждает их покинуть ваш сайт. Какие тут могут быть целевые действия или другая полезная активность?