Коротко. HTTPS — это обычный HTTP, завёрнутый в слой шифрования TLS. Между браузером и сервером поднимается защищённый канал: адрес страницы, заголовки, cookie, пароли и ответ сервера не видны никому в сети. Дополнительно браузер по сертификату проверяет, что говорит именно с тем доменом, который написан в адресной строке.
Что такое HTTPS простыми словами
HTTP — это набор правил, по которым браузер просит у сервера страницу, а сервер отвечает. Правила прекрасно работают, но у них есть одно свойство: всё передаётся открытым текстом. Любой узел на пути — Wi-Fi точка в кафе, провайдер, корпоративный прокси, скомпрометированный роутер — видит запрос целиком и может его изменить.
HTTPS (HyperText Transfer Protocol Secure) — это тот же самый HTTP, но перед отправкой он попадает в шифрованный канал TLS. Сам протокол HTTP при этом не меняется: те же методы GET и POST, те же заголовки, те же коды ответа. Меняется только транспорт под ним. Схема https:// в адресной строке описана в спецификации HTTP — RFC 9110, а сам протокол шифрования — в RFC 8446 (TLS 1.3).
Аналогия, которая не врёт: HTTP — это открытка. Текст читает каждый почтальон, и любой из них может дописать пару строк, а получатель не заметит подмены. HTTPS — это запечатанный конверт, у которого вдобавок проверяется печать отправителя.
Три вещи, которые даёт HTTPS
- Конфиденциальность. Содержимое запроса и ответа зашифровано. Наблюдатель видит факт соединения, но не его содержимое.
- Целостность. Данные подписаны на уровне шифра. Если провайдер или зловредный узел попытается подменить один байт в ответе, соединение оборвётся с ошибкой, а не отдаст испорченную страницу.
- Аутентификация сервера. Браузер убеждается по сертификату, что на том конце действительно сервер запрошенного домена, а не чужая машина, перехватившая трафик.
Обратите внимание на формулировку третьего пункта: подтверждается домен, а не добросовестность его владельца. Это принципиально, и ниже есть отдельный раздел про то, чего замок не гарантирует.
Чем HTTPS отличается от HTTP
Разница не только в букве S. Ниже — практические отличия, которые видны админу и владельцу сайта.
| Признак | HTTP | HTTPS |
|---|---|---|
| Схема URL | http:// | https:// |
| Порт по умолчанию | 80 | 443 |
| Шифрование канала | нет | да, TLS |
| Проверка подлинности сервера | нет | да, по сертификату |
| Защита от подмены содержимого в пути | нет | да, целостность на уровне шифра |
| Нужен сертификат | нет | да |
| HTTP/2 в браузерах | не поддерживается | поддерживается |
| HTTP/3 (QUIC) | не существует без TLS | поддерживается, TLS 1.3 обязателен |
| Метка в адресной строке | «Не защищено» | замок |
| Service Workers, геолокация, камера | браузер блокирует | доступны |
Заголовок Referer при переходе на HTTP-сайт | передаётся | по умолчанию не передаётся |
Отдельно стоит выделить строку про HTTP/2 и HTTP/3. Формально стандарт HTTP/2 допускает работу без шифрования (режим h2c), но ни один массовый браузер это не реализовал. То есть на практике переход на современные версии протокола возможен только через HTTPS — а это уже вопрос скорости, а не только безопасности. Если вы измеряете скорость загрузки страниц, то часть выигрыша от HTTP/2 и HTTP/3 без HTTPS просто недоступна.
Ещё один эффект, о котором забывают: браузеры постепенно перевели «мощные» возможности в разряд доступных только по HTTPS. Service Worker, доступ к камере и микрофону, точная геолокация, Web Push на HTTP-странице либо не работают вовсе, либо работают только на localhost при разработке.
Что такое HTTPS-соединение: как проходит TLS-рукопожатие
Прежде чем уйдёт первый байт HTTP-запроса, клиент и сервер должны договориться о ключах. Этот обмен называется рукопожатием (handshake). Без академического занудства он выглядит так.
TLS 1.3 — один круг обмена
- ClientHello. Браузер сообщает: поддерживаемые версии TLS, список шифров, имя нужного хоста (расширение SNI) и — главное — сразу присылает свою половину ключа для обмена по алгоритму Диффи — Хеллмана на эллиптических кривых. Он угадывает, какую группу выберет сервер, и не ждёт ответа.
- ServerHello. Сервер выбирает шифр, отдаёт свою половину ключа. С этого момента обе стороны независимо вычисляют общий секрет — по сети он никогда не передавался.
- Сертификат и подпись. Сервер присылает цепочку сертификатов и подписывает ею всё рукопожатие целиком (сообщение CertificateVerify). Это доказывает, что у него есть закрытый ключ, соответствующий сертификату. В TLS 1.3 всё это уже зашифровано.
- Finished. Обе стороны сверяют хеш всего диалога. Если посередине кто-то поменял хотя бы один байт, хеши не сойдутся и соединение оборвётся.
Итог: одна поездка туда-обратно (1-RTT) — и можно слать HTTP-запрос.
Чем отличался TLS 1.2
В TLS 1.2 сервер сначала отвечал приветствием и сертификатом, и только потом клиент отправлял свою часть ключа — получалось два круга обмена (2-RTT). Плюс сертификат сервера передавался открытым текстом: любой наблюдатель видел, на какой домен выписан сертификат. В TLS 1.3 сертификат зашифрован, а из набора шифров вычищены устаревшие конструкции вроде RSA-обмена ключами без прямой секретности.
TLS 1.0 и TLS 1.1 официально объявлены устаревшими отдельным документом IETF — RFC 8996. Актуальные браузеры их уже не согласуют. Если на сервере включены только они, посетитель увидит ошибку соединения, а не старомодную, но рабочую страницу.
Посмотреть, чем именно договорились ваш сервер и клиент, можно одной командой. Она открывает TLS-соединение и печатает согласованную версию протокола, шифр и результат проверки цепочки:
echo | openssl s_client -connect example.com:443 -servername example.com 2>&1 \
| grep -E 'Protocol|Cipher|Verify return code'Флаг -servername здесь обязателен: он передаёт SNI. Без него сервер с несколькими сайтами на одном IP отдаст сертификат по умолчанию, и вы будете отлаживать чужой сертификат. Строка Verify return code: 0 (ok) означает, что цепочка собралась и доверие подтвердилось; любое другое число — повод разбираться.
Проверить, поддерживается ли конкретная версия протокола, можно принудительным флагом. Если сервер не умеет TLS 1.3, команда завершится ошибкой согласования:
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null
# и наоборот — убедиться, что древние версии отключены:
openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/nullЧто такое SSL-сертификат и кто его выдаёт
Сертификат — это файл, который связывает доменное имя с открытым ключом и подписан удостоверяющим центром (Certificate Authority, CA). Название «SSL-сертификат» историческое: протокол SSL давно уступил место TLS, а имя прижилось. Технически это X.509-сертификат для TLS.
Доверие работает по цепочке. В операционной системе и браузере лежит хранилище корневых сертификатов — несколько сотен CA, которым производитель решил доверять. Корневой сертификат подписывает промежуточный, промежуточный — сертификат вашего сайта. Браузер разворачивает цепочку до корня, который у него уже есть, и только тогда показывает замок.
Самая частая ошибка настройки — отдавать браузеру только сертификат сайта, забыв промежуточный. В Chrome на десктопе такой сайт может открыться нормально (браузер иногда достраивает цепочку сам), а на мобильном или в curl — упасть с ошибкой. Всегда отдавайте полную цепочку: в Let's Encrypt это файл
fullchain.pem, а неcert.pem.
Типы проверки: DV, OV, EV
| Тип | Что проверяет CA | Выпуск | Что видит посетитель |
|---|---|---|---|
| DV (Domain Validation) | только контроль над доменом: DNS-запись, файл на сайте или письмо на служебный адрес | минуты, автоматически | обычный замок |
| OV (Organization Validation) | дополнительно существование юридического лица | дни, с документами | обычный замок; название компании только внутри сертификата |
| EV (Extended Validation) | расширенная проверка организации по регламенту CA/Browser Forum | дни или недели | обычный замок; отдельной подсветки в адресной строке браузеры давно не показывают |
Практический вывод неприятен для продавцов дорогих сертификатов: с точки зрения шифрования DV, OV и EV не отличаются вообще ничем. Один и тот же алгоритм, одна и та же стойкость. Разница только в том, что записано в поле «владелец» и сколько бумаг для этого собрали. Посетитель эту разницу не увидит, пока не откроет сертификат вручную — а этого не делает почти никто.
Бесплатные сертификаты и срок жизни
Проект Let's Encrypt сделал DV-сертификаты бесплатными и автоматическими. Стандартный срок действия его сертификата — 90 дней, а обновление рассчитано на автоматику: клиент вроде certbot продлевает сертификат по расписанию, обычно когда до конца остаётся около трети срока.
Общий тренд отрасли — сокращение максимального срока жизни публичных TLS-сертификатов. Конкретный лимит задаётся требованиями CA/Browser Forum и время от времени пересматривается, поэтому ориентироваться стоит на актуальную редакцию Baseline Requirements, а не на цифру из статьи. Практический вывод от этого не меняется: ручное продление раз в год — стратегия, которая рано или поздно закончится упавшим сайтом в выходные.
Посмотреть, на какие имена выписан сертификат и когда он истекает:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates
# полный список доменов, которые покрывает сертификат (OpenSSL 1.1.1 и новее):
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -ext subjectAltNameПоле subjectAltName (SAN) — единственное, что имеет значение при проверке имени. Старое поле Common Name современные клиенты игнорируют: правила проверки имени сервера описаны в RFC 9525. Если домена нет в SAN, браузер покажет ошибку несоответствия имени, даже когда сертификат абсолютно валиден.
Ещё один полезный факт: все публично доверенные сертификаты попадают в открытые журналы Certificate Transparency (RFC 6962). Это значит, что любой выпуск сертификата на ваш домен виден публично — в том числе выпуск, которого вы не заказывали. Хорошая привычка — периодически просматривать эти журналы по своему домену.
Что означает замок в браузере — и чего он не гарантирует
Это самый недопонятый элемент интерфейса за всю историю вебa. Разберём честно.
Что замок действительно подтверждает
- Соединение с сервером зашифровано, и содержимое страницы не читается по дороге.
- Сертификат не истёк и не отозван на момент проверки.
- Сертификат выписан на то самое доменное имя, которое стоит в адресной строке.
- Сертификат подписан удостоверяющим центром, которому доверяет ваш браузер.
Чего замок не подтверждает
- Что сайт не мошеннический. DV-сертификат бесплатен и выдаётся автоматически любому, кто доказал контроль над доменом, — включая владельца фишингового домена. Замок на поддельной странице банка сегодня скорее правило, чем исключение.
- Что владельца кто-то проверил. При DV-проверке не проверяется вообще ничего, кроме контроля над доменом. Ни компания, ни человек, ни адрес.
- Что на сайте нет вредоносного кода. Шифруется канал, а не содержимое. Заражённая страница доедет до вас в целости и сохранности — именно это и гарантирует TLS.
- Что данные в безопасности после доставки. Что происходит с паролем на сервере — хешируется он или пишется в лог открытым текстом, — TLS не знает и знать не может.
- Что домен принадлежит той компании, чьё название вы прочитали. Домены вроде
sberbank-online-support.exampleполучают сертификат ровно так же, как настоящие.
Замок означает «канал до этого домена защищён», а не «этому сайту можно доверять». Это разные утверждения, и подмена одного другим — рабочий инструмент фишинга уже много лет. Проверяйте домен глазами, а не наличие замка.
Если вы оцениваете чужой сайт, а не свой, полезнее смотреть не на замок, а на репутационные сигналы: возраст домена, данные регистрации, наличие сайта в базах вредоносного ПО. Отдельные проверки для этого есть на странице проверки сайта на вредоносное ПО и в WHOIS-инструменте.
Что такое HTTPS-запрос: что шифруется, а что видно
Формулировка «HTTPS шифрует всё» удобна, но неточна. Часть метаданных остаётся видимой — и это важно понимать при разговорах о приватности.
| Элемент | Виден наблюдателю в сети | Комментарий |
|---|---|---|
Путь и query-строка (/order?id=42) | нет | зашифровано целиком |
| Заголовки запроса, cookie, токены | нет | зашифровано |
| Тело запроса и ответа | нет | зашифровано |
| IP-адрес сервера и порт | да | иначе пакет не доедет |
| Имя хоста в SNI | да | передаётся открытым текстом при рукопожатии |
| DNS-запрос перед соединением | да, если не DoH или DoT | обычный DNS идёт открытым текстом |
| Объём и тайминги трафика | да | по размеру ответа иногда можно угадать страницу |
| Сертификат сервера | только в TLS 1.2 | в TLS 1.3 зашифрован |
Практический вывод: HTTPS надёжно скрывает что именно вы делаете на сайте, но не скрывает факт обращения к домену. Механизм Encrypted Client Hello, который прячет и SNI, на момент написания остаётся черновиком IETF и включён далеко не везде. Шифрование самих DNS-запросов решается отдельно — через DoH или DoT.
Второй практический вывод — для разработчиков. Раз путь и query зашифрованы, значит, промежуточные узлы не увидят токен в URL. Но его увидят логи сервера, заголовок Referer у внешних ресурсов и история браузера. HTTPS не отменяет правила «секреты не кладут в query-строку».
HTTPS и www — это разные вещи
Путаница возникает потому, что и то, и другое живёт в начале адреса. Но это разные уровни:
https://— схема, то есть протокол доступа. Отвечает на вопрос «как соединяться».www— поддомен, то есть часть имени хоста. Отвечает на вопрос «с кем соединяться». Техническиwww.example.com— такой же поддомен, какblog.example.com, просто исторически принятый.
Отсюда следует важное: комбинаций четыре, и для браузера, кэша и поисковой системы это четыре разных адреса.
| Адрес | Схема | Хост | Что должно происходить |
|---|---|---|---|
http://example.com | HTTP | apex | 301 на канонический адрес |
http://www.example.com | HTTP | www | 301 на канонический адрес |
https://example.com | HTTPS | apex | канонический или 301 |
https://www.example.com | HTTPS | www | канонический или 301 |
Правило простое: выбрать один канонический вариант и увести на него остальные три постоянным редиректом. Какой именно выбирать — вопрос не технический, а организационный, обе схемы рабочие. Единственный технический довод в пользу www: на apex-домене нельзя поставить CNAME-запись рядом с другими записями, поэтому подключение CDN к голому домену требует нестандартных решений провайдера, а на www достаточно обычного CNAME.
Сертификат на
example.comне покрываетwww.example.comавтоматически — оба имени должны быть в SAN. И наоборот: wildcard-сертификат*.example.comпокрываетwww.example.com, но не покрывает самexample.comи не покрываетa.b.example.com— звёздочка заменяет ровно одну метку имени.
Минимальная конфигурация nginx, которая закрывает все четыре адреса и включает HSTS:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on; # nginx 1.25.1+; раньше: listen 443 ssl http2;
server_name www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}Обратите внимание: у блока с редиректом на 443 порту тоже указан сертификат. Это не избыточность — чтобы отдать редирект по HTTPS, сервер сначала должен завершить TLS-рукопожатие, а для этого ему нужен сертификат, валидный для www. Полное описание директив есть в документации nginx.
Про HSTS — с осторожностью
Заголовок Strict-Transport-Security (RFC 6797) велит браузеру ходить на домен только по HTTPS в течение max-age секунд, даже если пользователь набрал http://. Это закрывает окно уязвимости на первом запросе.
Осторожность нужна с двумя вещами. Первое: includeSubDomains распространяется на все поддомены, включая внутренние сервисы, которые могут быть без сертификата, — они просто перестанут открываться. Второе: включать большой max-age стоит только после того, как HTTPS отработал без сбоев. Начните с небольшого значения, убедитесь, что всё работает, и только потом поднимайте до года.
Как проверить HTTPS у своего сайта
Проверка «замок есть — значит всё хорошо» пропускает большую часть реальных проблем. Ниже пять проверок, которые ловят почти всё.
1. Сертификат: имя, цепочка, срок
Смотрим, что сертификат выписан на нужные имена, цепочка полная, до истечения достаточно времени. Быстрее всего — через проверку SSL-сертификата: она разворачивает цепочку, показывает SAN, издателя, дату окончания и найденные проблемы. Локальный эквивалент — команды с openssl из раздела про сертификаты. Подробный разбор того, на что смотреть в выводе, есть в статье о проверке SSL-сертификата.
2. Редиректы: HTTP действительно уводит на HTTPS
Классическая ошибка — редирект настроен только для главной страницы, а внутренние адреса по HTTP отдают 200. Проверяем цепочку целиком, обязательно на внутреннем адресе, а не только на корне:
curl -sIL http://example.com/catalog/page | grep -Ei '^(HTTP/|location:)'
# одной строкой: конечный адрес, код и результат проверки сертификата
curl -sS -o /dev/null -L -w '%{http_code} %{ssl_verify_result} %{url_effective}\n' http://example.comЗначение ssl_verify_result, равное нулю, означает успешную проверку сертификата — но читать его имеет смысл, только если конечный адрес в выводе действительно начинается с https://. На обычном HTTP-соединении там тоже будет ноль, просто потому что проверять было нечего. Всю цепочку переходов с кодами удобно смотреть в проверке редиректов — там же видны лишние промежуточные хопы, которые стоит схлопнуть.
3. Заголовки безопасности
HTTPS — фундамент, но не весь дом. На нём стоят HSTS, политика Content-Security-Policy, флаги cookie Secure и HttpOnly. Полный набор отдаваемых заголовков показывает просмотр HTTP-заголовков, а оценку с рекомендациями — сканер безопасности.
curl -sSI https://example.com \
| grep -iE 'strict-transport-security|content-security-policy|x-content-type-options'4. Смешанный контент
Если страница отдаётся по HTTPS, но тянет картинку, скрипт или стиль по http://, браузер либо заблокирует ресурс, либо снимет замок. Грубая первичная проверка по исходному HTML:
curl -s https://example.com | grep -oE '(src|href)="http://[^"]+' | sort -uКоманда честно ловит только то, что есть в HTML: ресурсы, подгружаемые скриптами или из CSS, она не увидит. Полный разбор причин и способов починки — в статье о смешанном контенте.
5. Мониторинг срока действия
Просроченный сертификат — авария, которая случается в известную заранее дату и всё равно застаёт врасплох. Настройте мониторинг, чтобы получить уведомление за недели до истечения, а не звонок от клиента. Это же покрывает случай, когда автопродление молча сломалось: certbot отработал, а сервис не перечитал новый сертификат.
Частые вопросы
Что означает «что такое https yandex ru» или «https dzen ru» в поиске
Ничего особенного — это адрес сайта, случайно введённый в поисковую строку вместо адресной. Запись https://yandex.ru означает «сайт yandex.ru по защищённому протоколу», и точно так же читается любой другой адрес. Если поиск выдаёт что-то странное вместо перехода на сайт, скопируйте адрес в адресную строку браузера — обычно это верхнее поле окна.
HTTPS замедляет сайт
Рукопожатие добавляет один круг обмена при установке соединения, а шифрование современными шифрами на процессорах с аппаратной поддержкой практически бесплатно. При этом HTTPS открывает доступ к HTTP/2 и HTTP/3, которые дают мультиплексирование запросов и заметно выигрывают на страницах с большим числом ресурсов. На реальных сайтах итог обычно в пользу HTTPS. Проверить на своём проекте можно в тесте скорости.
Нужен ли HTTPS сайту-визитке без форм и оплаты
Да, и причины не только про пароли. Без HTTPS браузер помечает страницу как «Не защищено», часть возможностей браузера недоступна, провайдер технически может вставить в страницу свой скрипт или баннер, а форма обратной связи всё равно передаёт персональные данные. Плюс современные протоколы HTTP/2 и HTTP/3 без TLS в браузере не работают.
Бесплатный сертификат хуже платного
С точки зрения шифрования — нет, стойкость одинаковая. Разница в типе проверки (DV против OV и EV), в сроке действия и в том, что у платных сертификатов бывает страховка и поддержка. Посетитель разницы не видит: браузер показывает один и тот же замок.
Влияет ли HTTPS на позиции в поиске
Google публично называл HTTPS лёгким сигналом ранжирования, но рассчитывать на рост позиций от одной установки сертификата не стоит. Более ощутимый эффект — косвенный: отсутствие метки «Не защищено» и доступ к быстрым версиям протокола. Общее правило: HTTPS убирает повод потерять трафик, а не добавляет повода его получить.
Что делать, если браузер пишет «Ваше подключение не защищено»
Прочитайте код ошибки — он говорит о причине. Чаще всего это истёкший сертификат, несоответствие имени (зашли на www, а сертификат только на apex), неполная цепочка или сбитые часы на устройстве. Разбор конкретных кодов и что делать с каждым — в справочнике по ошибкам SSL.
Что даёт переход на TLS 1.3, если 1.2 работает
Более короткое рукопожатие, шифрование сертификата сервера и вычищенный набор шифров без устаревших конструкций. Держать оба — TLSv1.2 TLSv1.3 — нормальная практика: новые клиенты получат 1.3, старые не отвалятся. Подробнее — в статье об улучшениях TLS 1.3.
Чеклист: HTTPS настроен правильно
- Сертификат валиден, не истёк, цепочка отдаётся полностью (
fullchain, а не только сертификат сайта). - В SAN сертификата есть все используемые имена: и apex, и
www. - Все четыре варианта адреса сходятся к одному каноническому через 301.
- Редирект на HTTPS работает не только на главной, но и на внутренних адресах.
- Включены только TLS 1.2 и TLS 1.3; устаревшие версии отключены.
- Заголовок HSTS отдаётся,
max-ageподнят до большого значения только после проверки. includeSubDomainsвключён осознанно — все поддомены умеют HTTPS.- Смешанного контента нет: страница не тянет ресурсы по
http://. - Cookie помечены флагами
SecureиHttpOnly. - Автопродление сертификата настроено и проверено, сервис перечитывает новый файл.
- Настроено уведомление об истечении сертификата за несколько недель.
- Вы понимаете, что замок подтверждает канал и домен, а не добросовестность сайта.