3.4. HTTPS secure HTTP

HTTPS — это HTTP с шифрованием. Единственная разница между этими двумя протоколами заключается в том, что HTTPS использует SSL/TLS для шифрования обычных HTTP-запросов и ответов. В результате HTTPS гораздо более безопасен, чем HTTP. Веб-приложение на HTTP имеет http:// в своём URL-адресе, а веб-сайт на HTTPS — https://.

Посмотрим, как выглядит запрос при HTTPS.

Вместо:

GET /hello HTTP/1.1
User-Agent: curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
Host: www.htmlacademy.ru
Accept-Language: ru

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

t8Fw6T8UV81pQfyhDkhebbz7+oiwldr1j2gHBB3L3RFTRsQCpaSnSBZ78Vme+DpDVJPvZdZUZHpzbb

HTTPS использует SSL/TLS для шифрования HTTP-запросов и ответов, поэтому вместо текста злоумышленник увидит набор, казалось бы, случайных символов.

Как TLS/SSL шифрует HTTP-запросы и ответы в HTTPS?

TLS использует технологию, называемую шифрованием с открытым ключом. Есть два ключа: открытый и закрытый. Открытый ключ передаётся клиентским устройствам через SSL-сертификат сервера. Когда клиент открывает соединение с сервером, два устройства используют открытый и закрытый ключи, чтобы согласовать новые (их называют ключами сеанса) для шифрования дальнейших коммуникаций.

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

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

Как HTTPS помогает аутентифицировать веб-серверы?

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

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

При правильной настройке HTTPS-соединение гарантирует три условия:

  • Конфиденциальность. Соединение посетителя зашифровано, что скрывает URL-адреса, файлы cookie и другие конфиденциальные метаданные.
  • Подлинность. Посетитель общается с «настоящим» веб-сайтом, а не с имитатором или через посредника.
  • Честность. Данные, передаваемые между посетителем и веб-сайтом, не были подделаны или изменены.

Какую информацию защищает HTTPS?

Незашифрованный HTTP-запрос показывает не только тело запроса, но и полный URL-адрес, строку запроса и различные заголовки HTTP о клиенте и запросе:

Какая информация доступна в HTTP

HTTPS-запрос шифрует почти всю информацию, передаваемую между клиентом и веб-службой:

Какая информация доступна в HTTPS

Это одинаково для всех методов HTTP (GET, POST, PUT и так далее). URL-адрес и параметры строки запроса зашифрованы, как и тело.

Какую информацию не защищает HTTPS?

В то время как HTTPS шифрует весь HTTP-запрос и ответ, разрешение DNS и настройка соединения могут раскрывать другую информацию: исходный IP-адрес и полный домен или субдомен.

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

Как HTTPS связан с HTTP/2?

HTTP/2 (доработка завершена в 2015 году) — это обратно совместимое обновление HTTP/1.1 (доработан в 1999 году), оптимизированное для современной сети. Он включает в себя множество функций, которые могут значительно повысить производительность веб-сайта и появились благодаря SPDY.

Хотя HTTP/2 не требует использования шифрования в его формальной спецификации, каждый браузер с поддержкой HTTP/2 реализовал только поддержку зашифрованных соединений. И ни один из основных браузеров не работает над поддержкой HTTP/2 для незашифрованных соединений.

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

Как переход на HTTPS влияет на поисковую оптимизацию (SEO)

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

Можно ли атаковать HTTPS-соединение

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

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

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

Как сделать миграцию плавной и избежать SEO-удара

Используйте правильный 301-редирект для перенаправления пользователей с http:// на https://. Не используйте переадресацию 302, это может негативно повлиять на ранжирование.

Также используйте элемент канонической ссылки <link rel="canonical">, чтобы сообщить поисковым системам, что «канонический» URL-адрес веб-сайта использует https://.

HTML:

<!DOCTYPE html>
<html>
<head>
  <link rel="canonical" href="https://htmlacademy.ru/page.php">
</head>
<body>

</body>
</html>

HTTP:

HTTP/1.1 200 OK
Content-Type: application/pdf
Link: <https://htmlacademy.ru/page.php>; rel="canonical"
Content-Length: 4223

Приведён пример HTML-кода, в котором используется rel=canonical внутри тега <head>. Код можно использовать на странице https://htmlacademy.ru/page.php?parameter=1. Он сообщит поисковым системам о том, что https://htmlacademy.ru/page.php является предпочтительной версией веб-страницы.

HTTPS защищает не всё

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

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

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

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