Что такое протокол HTTPS и как он работает

HTTPS (HyperText Transfer Protocol Secure) — это зашифрованная версия HTTP, сочетающая стандартный протокол передачи данных в интернете с TLS (Transport Layer Security) для создания аутентифицированного зашифрованного канала между браузером клиента и веб-сервером. Каждый байт данных, передаваемых по HTTPS, криптографически защищён, что означает: ни пассивные перехватчики, ни активные злоумышленники, осуществляющие атаку «человек посередине», не могут прочитать или незаметно изменить передаваемые данные.

На практике: когда браузер подключается к https://example.com, он сначала завершает TLS-рукопожатие, которое аутентифицирует личность сервера с помощью подписанного сертификата, согласовывает набор шифров и формирует симметричные сеансовые ключи — и всё это происходит до того, как будет передан хотя бы один байт данных приложения. Только после успешного завершения рукопожатия HTTP-запрос передаётся по сети в полностью зашифрованном виде.

HTTP и HTTPS: прямое сравнение

TLS-рукопожатие в деталях

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

Рукопожатие TLS 1.2 (устаревшее)

1. ClientHello — Браузер отправляет поддерживаемые наборы шифров, версию TLS и случайный одноразовый номер (client_random).
2. ServerHello — Сервер выбирает набор шифров и отправляет собственный одноразовый номер (server_random).
3. Certificate — Сервер передаёт цепочку сертификатов X.509 для проверки браузером по его хранилищу доверенных CA.
4. ServerKeyExchange — Для эфемерного Diffie-Hellman (ECDHE) сервер отправляет свои параметры DH, подписанные закрытым ключом.
5. ClientKeyExchange — Браузер генерирует предварительный секрет, шифрует его открытым ключом сервера (RSA) или вычисляет общий секрет DH (ECDHE) и отправляет его.
6. ChangeCipherSpec / Finished — Обе стороны формируют сеансовые ключи из client_random, server_random и предварительного секрета, затем подтверждают это сообщением Finished.

Общее количество циклов приёма-передачи до начала обмена данными: 2 RTT.

Рукопожатие TLS 1.3 (текущий стандарт)

TLS 1.3, стандартизированный в RFC 8446, устраняет ряд устаревших механизмов и значительно снижает задержку:

1. ClientHello — Браузер сразу включает свою долю ключа (открытое значение ECDHE) вместе с поддерживаемыми наборами шифров. Обмен ключами RSA не допускается.
2. ServerHello + EncryptedExtensions + Certificate + CertificateVerify + Finished — Сервер отвечает в одном пакете, уже шифруя расширения и свой сертификат с помощью производного ключа рукопожатия.
3. Client Finished — Браузер проверяет сертификат сервера и отправляет сообщение Finished. Данные приложения могут передаваться сразу после этого.

Общее количество циклов приёма-передачи до начала обмена данными: 1 RTT. При возобновлении 0-RTT (сеансовые билеты) возвращающиеся посетители могут отправлять данные уже в первом пакете — хотя это создаёт риски атак повторного воспроизведения, требующих тщательной обработки на стороне сервера.

Ключевые улучшения TLS 1.3 по сравнению с 1.2:

• Удалён обмен ключами RSA (нет риска нарушения прямой секретности)
• Удалены MD5, SHA-1, RC4, DES, 3DES
• Обязательная прямая секретность через ECDHE
• Зашифрованная передача сертификата (снижает утечку метаданных)
• Более быстрое рукопожатие заметно сокращает время загрузки страницы при высокой задержке соединения

Типы сертификатов и что они на самом деле защищают

Не все SSL/TLS-сертификаты равнозначны. Выбор неправильного типа — распространённая операционная ошибка.

Проверка домена (DV)

Выдаётся в течение нескольких минут автоматизированными системами (например, Let’s Encrypt). Подтверждает, что владелец сертификата контролирует DNS домена или веб-сервер. Обеспечивает полное шифрование, но не проверяет личность организации, стоящей за доменом. Подходит для блогов, личных проектов и внутренних инструментов.

Проверка организации (OV)

CA вручную проверяет юридическое существование организации. Сертификат содержит название компании. Подходит для бизнес-сайтов и SaaS-платформ, где важно доверие к бренду.

Расширенная проверка (EV)

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

Wildcard-сертификаты

Один сертификат охватывает домен и все его поддомены первого уровня (*.example.com). Важная оговорка: wildcard-сертификат не охватывает поддомены второго уровня (для *.sub.example.com требуется отдельный wildcard). Компрометация закрытого ключа wildcard-сертификата одновременно раскрывает все поддомены — это значительный радиус поражения.

Многодоменные сертификаты (SAN)

Subject Alternative Names (SAN) позволяют одному сертификату охватывать несколько различных доменов (example.com, example.net, shop.example.org). Идеально подходит для хостинговых сред, управляющих несколькими ресурсами с одного сервера.

Почему HTTPS обязателен в 2025 году

Шифрование конфиденциальных данных

Без TLS каждый пакет между пользователем и вашим сервером проходит через потенциально враждебную сетевую инфраструктуру — точки доступа к публичному Wi-Fi, прозрачные прокси-серверы провайдеров и маршруты с BGP-перехватом. Учётные данные, сеансовые токены, платёжные данные и отправленные формы передаются в открытом виде и легко перехватываются с помощью таких инструментов, как Wireshark. HTTPS полностью устраняет эту уязвимость.

Аутентифицированная личность сервера

Цепочка доверия сертификатов предотвращает атаки подмены DNS и ARP-спуфинга, которые могут незаметно перенаправить пользователей на мошеннический сервер. Когда браузер проверяет сертификат, он подтверждает три вещи: сертификат подписан CA из его хранилища доверенных сертификатов, доменное имя соответствует полям CN или SAN сертификата, а сертификат не истёк и не был отозван (проверяется через OCSP или CRL).

Целостность данных с помощью AEAD-шифров

Современные наборы шифров TLS используют аутентифицированное шифрование со связанными данными (AEAD) — в частности, AES-256-GCM или ChaCha20-Poly1305. Они обеспечивают как конфиденциальность, так и целостность в одной операции. Любая попытка изменить биты или внедрить данные в процессе передачи приводит к сбою проверки MAC, и соединение немедленно разрывается. Это предотвращает атаки внедрения контента, при которых провайдеры или злоумышленники-посредники вставляют рекламу, скрипты отслеживания или вредоносное ПО в HTTP-ответы.

SEO и сигналы ранжирования

Google подтвердил HTTPS как сигнал ранжирования в 2014 году и постепенно увеличивал его вес. Помимо прямого фактора ранжирования, предупреждение Chrome «Не защищено» на HTTP-страницах заметно увеличивает показатель отказов — поведенческий сигнал, который косвенно снижает позиции в поисковой выдаче. HTTP/2 и HTTP/3 (QUIC), обеспечивающие значительное улучшение производительности, требуют TLS во всех основных реализациях браузеров. Более быстрые страницы ранжируются лучше; HTTPS является обязательным условием.

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

HTTP Strict Transport Security (заголовок Strict-Transport-Security) предписывает браузерам отклонять все HTTP-соединения с доменом в течение указанного периода max-age, даже до выполнения перенаправления. Добавление вашего домена в список предварительной загрузки HSTS жёстко закодирует это поведение в бинарных файлах браузера, полностью устраняя уязвимость при первом посещении.

Внедрение HTTPS: пошаговое руководство для производственной среды

Шаг 1: Получение SSL/TLS-сертификата

Let’s Encrypt (бесплатный, автоматизированный) — стандартный выбор для большинства развёртываний. Certbot является эталонным ACME-клиентом:

sudo apt update && sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d example.com -d www.example.com

Для Apache:

sudo apt install certbot python3-certbot-apache -y
sudo certbot --apache -d example.com -d www.example.com

Certbot автоматически изменяет конфигурацию виртуального хоста и настраивает задание cron или таймер systemd для обновления. Сертификаты Let’s Encrypt истекают через 90 дней; автоматическое обновление запускается каждые 60 дней по умолчанию.

Для проверки обновления без внесения изменений:

sudo certbot renew --dry-run

Для производственных сред, требующих сертификатов OV или EV, приобретите их у коммерческого CA (DigiCert, Sectigo, GlobalSign) и следуйте их процессу ручной выдачи. На странице SSL-сертификатов AlexHost представлены доступные варианты, включая как DV, так и коммерческие сертификаты.

Шаг 2: Установка и настройка сертификата на веб-сервере

Пример Nginx (/etc/nginx/sites-available/example.com):

server {
    listen 443 ssl http2;
    server_name example.com www.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_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;

    root /var/www/example.com;
    index index.php index.html;
}

Пример Apache (/etc/apache2/sites-available/example.com-ssl.conf):

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem

    SSLProtocol -all +TLSv1.2 +TLSv1.3
    SSLCipherSuite HIGH:!aNULL:!MD5
    SSLHonorCipherOrder off

    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</VirtualHost>

Шаг 3: Принудительное использование HTTPS с постоянным перенаправлением 301

Nginx — добавьте отдельный блок server:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Apache — в .htaccess или виртуальном хосте HTTP:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Используйте 301 (постоянное) вместо 302 (временное). Перенаправление 302 не передаёт ссылочный вес и не обновляет кэш браузера, что означает, что пользователи будут продолжать обращаться к HTTP при каждой новой сессии.

Шаг 4: Устранение смешанного контента

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

Обнаружение: Откройте Chrome DevTools (F12), перейдите на вкладку Console и найдите предупреждения Mixed Content. Также можно использовать SSL Labs Mixed Content Checker или инструмент why-no-padlock.com.

Стратегии устранения:

• Обновите жёстко заданные URL http:// в базе данных CMS с помощью инструмента поиска и замены (например, wp-cli search-replace 'http://example.com' 'https://example.com' для WordPress)
• Установите заголовок Content-Security-Policy: upgrade-insecure-requests в качестве временной меры, пока вы исправляете источники
• Проверьте сторонние встраиваемые элементы — если поставщик не поддерживает HTTPS, замените или удалите встраиваемый элемент

Шаг 5: Проверка конфигурации

# Test certificate chain and expiry
openssl s_client -connect example.com:443 -servername example.com < /dev/null

# Check TLS protocol versions and cipher suites
nmap --script ssl-enum-ciphers -p 443 example.com

Для комплексного внешнего аудита отправьте ваш домен на проверку SSL Labs Server Test. Рейтинг A+ требует:

• Только TLS 1.2 и 1.3 (TLS 1.0 и 1.1 отключены)
• Отсутствие слабых наборов шифров (RC4, 3DES, экспортные шифры)
• Заголовок HSTS с max-age >= 180 дней
• Отсутствие проблем с цепочкой сертификатов (промежуточные сертификаты включены)
• OCSP stapling включён

Распространённые ошибки и граничные случаи

Неполная цепочка сертификатов — наиболее частая проблема в производственной среде. Если установить только конечный сертификат без промежуточного CA-сертификата, большинство настольных браузеров всё равно восстановят цепочку (они кэшируют промежуточные сертификаты), но мобильные браузеры, API-клиенты и curl завершатся с ошибкой SSL_ERROR_RX_RECORD_TOO_LONG или unable to get local issuer certificate. Всегда используйте fullchain.pem (Let’s Encrypt) или объединяйте конечный и промежуточный сертификаты для других CA.

OCSP stapling снижает задержку рукопожатия и повышает конфиденциальность, поскольку сервер кэширует и предоставляет ответ OCSP вместо того, чтобы браузер обращался к OCSP-ответчику CA. Без stapling каждое TLS-рукопожатие инициирует сторонний HTTP-запрос, добавляя 50–200 мс задержки при холодных соединениях. Включите его в Nginx с помощью ssl_stapling on; ssl_stapling_verify on;.

Безопасность закрытого ключа часто игнорируется. Файл закрытого ключа должен принадлежать root, быть доступным для чтения только процессу веб-сервера и храниться с правами доступа chmod 600. Никогда не добавляйте закрытые ключи в систему контроля версий. В общей инфраструктуре используйте аппаратные модули безопасности (HSM) или системы управления секретами (HashiCorp Vault, AWS Secrets Manager) для хранения ключей.

Отзыв wildcard-сертификата имеет непропорционально большое воздействие. Если закрытый ключ wildcard-сертификата скомпрометирован и сертификат отозван, все поддомены одновременно теряют HTTPS. Для сред с высокими требованиями к безопасности предпочтительнее использовать сертификаты для отдельных поддоменов, автоматизированные через ACME DNS-01 challenges.

Терминация TLS на балансировщике нагрузки — распространённая архитектура, при которой TLS расшифровывается на границе сети (балансировщик нагрузки, CDN, обратный прокси), а трафик передаётся внутри в незашифрованном виде. Это допустимо только в том случае, если внутренняя сеть полностью доверенная и изолированная. Для регулируемых сред (PCI-DSS, HIPAA) требуется сквозное шифрование — повторное шифрование трафика между балансировщиком нагрузки и серверами бэкенда.

HTTPS в инфраструктуре AlexHost

В среде VPS-хостинга у вас есть полный root-доступ для установки Certbot, прямой настройки Nginx или Apache и реализации усиленных параметров TLS, описанных выше. Это рекомендуемый подход для производственных рабочих нагрузок, требующих пользовательских наборов шифров, предварительной загрузки HSTS и OCSP stapling.

Для пользователей виртуального веб-хостинга сертификаты Let’s Encrypt, как правило, доступны через панель управления с установкой в один клик, которая автоматически обрабатывает выдачу и обновление сертификатов без SSH-доступа.

Если вы управляете несколькими доменами или ведёте реселлерскую деятельность, VPS с cPanel предоставляет графический интерфейс для управления SSL на всех размещённых доменах, включая AutoSSL для автоматической подготовки Let’s Encrypt.

Для развёртываний электронной коммерции, обрабатывающих платёжные данные, сочетание HTTPS с коммерческим сертификатом OV или EV из раздела SSL-сертификатов обеспечивает проверку организационной идентичности, которую DV-сертификаты не могут предложить — это актуально для аудитов соответствия PCI-DSS.

Если ваша инфраструктура включает транзакционную или маркетинговую электронную почту, обратите внимание, что HTTPS и TLS для SMTP/IMAP — это разные вопросы. Защита вашего веб-присутствия не обеспечивает автоматически безопасность почтовой инфраструктуры; для этого требуется отдельная настройка TLS в вашем стеке почтового хостинга.

Матрица решений и технический чеклист

Используйте этот чеклист перед тем, как считать миграцию на HTTPS завершённой:

Сертификат

• [ ] Сертификат выдан доверенным CA (проверить с помощью openssl verify)
• [ ] Установлена полная цепочка сертификатов (конечный + промежуточные)
• [ ] Сертификат охватывает все обслуживаемые домены/поддомены (проверить SAN)
• [ ] Настроен мониторинг истечения срока действия (оповещения за 30 дней и за 7 дней)
• [ ] Автоматическое обновление протестировано с помощью --dry-run

Конфигурация сервера

• [ ] TLS 1.0 и 1.1 явно отключены
• [ ] TLS 1.3 включён
• [ ] Слабые наборы шифров удалены (RC4, 3DES, NULL, EXPORT)
• [ ] OCSP stapling включён и проверен
• [ ] ssl_session_tickets off (предотвращает проблемы с ротацией ключей сеансовых билетов)

Прикладной уровень

• [ ] Все внутренние ссылки используют относительные URL или https://
• [ ] Отсутствуют предупреждения о смешанном контенте в консоли браузера
• [ ] Заголовок Content-Security-Policy: upgrade-insecure-requests установлен
• [ ] Перенаправления 301 с HTTP на HTTPS для всех имён хостов

Заголовки безопасности

• [ ] Заголовок Strict-Transport-Security с max-age >= 31536000
• [ ] Директива includeSubDomains добавлена (после проверки того, что все поддомены поддерживают HTTPS)
• [ ] Домен добавлен в список предварительной загрузки HSTS (необязательно, но рекомендуется)

Проверка

• [ ] SSL Labs Server Test возвращает рейтинг A или A+
• [ ] openssl s_client подтверждает правильную цепочку сертификатов
• [ ] Подтверждена активность задания cron/таймера systemd для обновления

Часто задаваемые вопросы

Защищает ли HTTPS от всех видов кибератак?

Нет. HTTPS шифрует транспортный уровень и аутентифицирует сервер, но не защищает от уязвимостей на уровне приложений (SQL-инъекции, XSS, CSRF), скомпрометированного серверного кода или атак, направленных на устройство аутентифицированного пользователя. Фишинговый сайт может получить действительный DV-сертификат и отображать значок замка — HTTPS подтверждает, что соединение зашифровано, а не то, что сайт заслуживает доверия.

Как включение HTTPS влияет на производительность?

При использовании TLS 1.3 и HTTP/2 накладные расходы незначительны на современном оборудовании. TLS-рукопожатие добавляет один дополнительный цикл приёма-передачи при первом подключении (ноль при возобновлении с сеансовыми билетами или 0-RTT). Аппаратное ускорение AES-NI, доступное практически на всех серверных процессорах с 2010 года, обрабатывает симметричное шифрование на скорости линии. На практике HTTPS-сайты часто загружаются быстрее, чем их HTTP-аналоги, поскольку мультиплексирование HTTP/2 и сжатие заголовков — которые требуют TLS в браузерах — перевешивают затраты на рукопожатие.

Что происходит при истечении срока действия SSL/TLS-сертификата?

Браузеры немедленно отображают полностраничное предупреждение, блокирующее доступ к сайту. API-клиенты и мобильные приложения, как правило, завершаются с жёсткой ошибкой, а не предупреждением. Поисковые роботы могут продолжать индексировать сайт, но будут отмечать ошибку сертификата. Автоматическое обновление через Certbot или ACME предотвращает истечение срока действия; критическое операционное требование — убедиться, что задание cron или таймер systemd для обновления работает и настроены оповещения об обновлении.

В чём разница между TLS и SSL?

SSL (Secure Sockets Layer) — это протокол-предшественник, версии 2.0 и 3.0 которого устарели и запрещены RFC 7568 из-за критических уязвимостей (POODLE, DROWN). TLS (Transport Layer Security) — это преемник, при этом TLS 1.2 (RFC 5246) и TLS 1.3 (RFC 8446) являются единственными версиями, считающимися безопасными. Термин «SSL-сертификат» сохраняется в разговорной речи, но фактический протокол, используемый на любом современном сервере, — это TLS. Настройка сервера для разрешения SSLv3 является неправильной конфигурацией, а не функцией совместимости.

Могу ли я использовать HTTPS для домена, которым не владею?

Нет. Центры сертификации проверяют контроль над доменом перед выдачей сертификата. Протокол ACME (используемый Let’s Encrypt) требует, чтобы вы либо разместили определённый файл по известному HTTP-пути (HTTP-01 challenge), либо создали определённую DNS TXT-запись (DNS-01 challenge) для подтверждения контроля. Без прохождения одного из этих испытаний ни один сертификат не будет выдан для домена, которым вы не управляете.