Криптографический фундамент соединения
Обычный HTTP передаёт данные в открытом виде через транспортный протокол TCP. Любой маршрутизатор, провайдер или злоумышленник с анализатором трафика вроде Wireshark в общей сети Wi-Fi может прочитать заголовки запросов, куки авторизации, пароли и тело сообщений. Протокол HTTPS встраивает между прикладным уровнем HTTP и транспортным уровнем TCP криптографический уровень TLS, ранее известный как SSL.
Для обеспечения комплексной защиты протокол решает три независимые задачи. Конфиденциальность гарантирует, что посторонний наблюдатель увидит лишь случайный набор байтов. Целостность подтверждает доставку данных получателю без искажений или внедрения вредоносного кода со стороны транзитных узлов. Аутентификация проверяет подлинность удалённого сервера через доверенные удостоверяющие центры.
Симметричное шифрование работает быстро, но требует наличия общего секрета у обеих сторон. Передать такой секрет по открытому каналу без предварительной защиты невозможно. Асимметричное шифрование решает проблему доставки ключей с помощью пары из открытого и закрытого ключей, однако требует значительных вычислительных мощностей процессора. Архитектура TLS объединяет достоинства обоих методов. Медленная асимметричная криптография используется исключительно на этапе установки сессии для безопасного согласования параметров, а вся последующая полезная нагрузка шифруется быстрыми симметричными шифрами вроде AES-GCM или ChaCha20-Poly1305.
Пошаговый процесс рукопожатия TLS
Прежде чем клиент отправит первый HTTP-запрос GET или POST, стороны выполняют процедуру согласования параметров связи. В современных сетях стандартным протоколом выступает TLS 1.3, утверждённый инженерным советом IETF в документе RFC 8446 в 2018 году. По сравнению с предшествующей версией TLS 1.2 процедура рукопожатия сократилась с двух сетевых кругов задержки до одного.
- Клиент отправляет сообщение ClientHello, содержащее список поддерживаемых версий протокола, перечень криптографических наборов cipher suites, случайную последовательность байтов client_random и свои открытые доли ключа для алгоритма Диффи — Хеллмана
- Сервер отвечает пакетом ServerHello, выбирая совместимый криптографический набор и отправляя встречную открытую долю ключа для вычисления общего сессионного секрета
- Сервер передаёт свой цифровой сертификат стандарта X.509 вместе с цифровой подписью, подтверждающей владение соответствующим закрытым ключом
- Обе стороны независимо друг от друга вычисляют мастер-ключ на основе алгоритма ECDHE и переходят на симметричное шифрование трафика
- Сервер завершает фазу рукопожатия сообщением Finished, зашифрованным уже согласованным сессионным ключом, после чего клиент проверяет целостность всей цепочки рукопожатия и отправляет встречный Finished
Если клиент уже подключался к этому серверу ранее, спецификация TLS 1.3 позволяет активировать режим 0-RTT Resumption. В такой схеме зашифрованные данные первого HTTP-запроса уходят на сервер вместе с первым же пакетом рукопожатия на основе сохранённых ранее сессионных билетов.
Цифровые сертификаты и инфраструктура открытых ключей
Шифрование само по себе защищает от пассивного прослушивания кабеля, но остаётся уязвимым перед активным перехватом. Без проверки подлинности злоумышленник может встать посередине канала, представиться клиенту целевым сервером, а серверу — клиентом. Эту проблему решает инфраструктура открытых ключей PKI.
Сервер предъявляет клиенту электронный документ стандарта X.509, связывающий доменное имя сайта с его открытым криптографическим ключом. Подлинность этой связки заверяется цифровой подписью аккредитованного удостоверяющего центра. В операционную систему или браузер заранее встроен список доверенных корневых сертификатов крупных центров сертификации, таких как Let's Encrypt, DigiCert или Sectigo.
Клиент строит цепочку доверия от конечного сертификата веб-сайта через промежуточные звенья к доверенному корню. Браузер расшифровывает подпись вышестоящего центра с помощью его открытого ключа и сравнивает полученный хеш с фактическим хешем проверяемого сертификата. Совпадение хешей математически доказывает, что сертификат выдан доверенной организацией и не изменялся третьими лицами после выпуска. Дополнительно проверяется текущий срок действия документа и статус его возможного отзыва через протокол OCSP или списки CRL.
Уязвимости старых версий SSL и TLS
Надёжность криптографической защиты формировалась десятилетиями через обнаружение и устранение фундаментальных архитектурных брешей. Протоколы SSL 2.0 и SSL 3.0 полностью запрещены к использованию из-за критических слабостей в реализации хеширования и процедуре согласования шифров. Спецификации TLS 1.0 и 1.1 были официально признаны устаревшими комитетом IETF весной 2021 года.
- Атака POODLE использовала особенности работы режима сцепления блоков шифра CBC в протоколе SSL 3.0, позволяя злоумышленнику байт за байтом расшифровывать содержимое защищённых cookie-файлов
- Уязвимость BEAST эксплуатировала предсказуемость векторов инициализации в TLS 1.0, предоставляя возможность перехватывать маркеры пользовательских сессий
- Атака Heartbleed представляла собой критическую программную ошибку в популярной библиотеке OpenSSL, позволявшую удалённому узлу считывать до шестидесяти четырёх килобайтов оперативной памяти сервера вместе с закрытыми ключами
- Атаки класса DROWN и FREAK заставляли клиентские приложения использовать устаревшие экспортные алгоритмы шифрования с намеренно заниженной длиной ключей, созданные по требованиям американского законодательства девяностых годов
В протоколе TLS 1.3 разработчики полностью исключили поддержку уязвимых алгоритмов. Из стандарта удалили блочные шифры в режиме CBC, хеш-функции MD5 и SHA-1, статический обмен ключами RSA, а также алгоритм RC4. Современный протокол поддерживает исключительно поточные шифры с аутентифицированным шифрованием AEAD и обязательную прямую секретность Forward Secrecy.
Гарантия долговременной безопасности Forward Secrecy
В устаревших реализациях TLS клиент шифровал общий сессионный ключ с помощью открытого ключа сервера из сертификата. При таком подходе возникала угроза отложенного раскрытия данных. Спецслужбы или злоумышленники могли годами перехватывать и сохранять зашифрованный трафик на накопители, а затем выкрасть закрытый ключ сервера и разом расшифровать все накопленные архивы сообщений.
Современные версии протокола требуют применения эфемерных криптографических протоколов обмена ключами ECDHE на основе эллиптических кривых. Для каждого нового сетевого соединения стороны генерируют одноразовые пары ключей, которые уничтожаются в оперативной памяти сразу после завершения сеанса. Компрометация постоянного закрытого ключа веб-сервера позволяет злоумышленнику лишь подделывать новые соединения в будущем, но оставляет ранее записанные гигабайты трафика нечитаемыми.
Частые вопросы
Видит ли администратор локальной сети вводимые пароли при открытом HTTPS?
Администратор сети или владелец роутера видит только IP-адрес сервера и доменное имя сайта. Все отправляемые формы, логины, пароли и заголовки запросов надёжно зашифрованы симметричным ключом и недоступны для чтения.
В чём разница между протоколами SSL и TLS?
TLS является прямым эволюционным развитием SSL. Корпорация Netscape разработала SSL версий 1.0, 2.0 и 3.0 в девяностых годах. После передачи стандарта под управление сообщества IETF следующую модификацию переименовали в TLS 1.0, поэтому термин SSL сегодня используется лишь как устаревший синоним.
Может ли сайт с HTTPS распространять вирусы или быть фишинговым?
Да, протокол защищает исключительно канал передачи данных от прослушивания и подмены третьими лицами. Сертификат базового уровня Domain Validation лишь подтверждает, что домен принадлежит владельцу сайта, но ничего не говорит о честности его намерений.
Зачем нужен протокол HSTS?
Механизм HTTP Strict Transport Security сообщает браузеру о необходимости обращаться к сайту строго по защищённому каналу HTTPS. Это блокирует атаки класса SSL Stripping, при которых вредоносный шлюз перехватывает первый незашифрованный запрос пользователя и принудительно оставляет его на небезопасном протоколе HTTP.