--- title: 'HTTP vs HTTPS Explained' source: 'https://youtube.com/watch?v=WvSVSbGo0wI' video_id: 'WvSVSbGo0wI' date: 2026-09-03 duration_sec: 431 channel: 'ByteByteGo' --- # HTTP vs HTTPS Explained > Source: [HTTP vs HTTPS Explained](https://youtube.com/watch?v=WvSVSbGo0wI) ## Summary This video explains the fundamental differences between HTTP and HTTPS, focusing on the security mechanisms that HTTPS adds. It details the TLS handshake process, including certificate validation and key exchange, and clarifies why HTTPS is essential for secure communication. ### Key Points - **HTTP's Three Fundamental Problems** [00:16] — HTTP lacks confidentiality, does not verify server identity, and does not protect messages from tampering during transmission. - **HTTPS Uses TLS, Not SSL** [01:45] — TLS (Transport Layer Security) is the modern protocol; SSL is its older predecessor. HTTPS is HTTP over TLS, not a replacement for HTTP. - **TLS Handshake Begins After TCP** [02:13] — After the TCP handshake, the browser initiates a TLS handshake to verify the server's identity and establish shared encryption keys. - **Certificate Validation** [02:42] — The server sends its certificate, which includes its public key and is signed by a trusted CA. The browser checks the certificate's validity, hostname, and chain of trust. - **Modern Key Exchange Uses Ephemeral Diffie-Hellman** [04:33] — TLS 1.3 removed static RSA key exchange. Instead, clients and servers use ephemeral Diffie-Hellman to compute a shared secret that is never transmitted, providing forward secrecy. - **HTTP Messages Are Encrypted** [05:46] — After the handshake, HTTP requests and responses are encrypted, protecting the request line, headers, cookies, and body from eavesdroppers. - **Why Symmetric Encryption?** [06:17] — Symmetric encryption is fast enough for large data volumes, while asymmetric cryptography is used for identity verification and key agreement but is more expensive. ### Conclusion HTTPS is not a different protocol but HTTP wrapped in a secure TLS tunnel, providing confidentiality, authentication, and integrity. The 'S' in HTTPS signifies this added security layer. ## Transcript пароль и нажимаете «Отправить» ? В общих чертах, браузер отправляет HTTP-запрос на сервер. Сервер отправляет обратно HTTP- ответ. Эта часть проста. Проблема заключается в том, что происходит между браузером и сервером. Именно здесь HTTP и HTTPS ведут себя совершенно по-разному. Прежде чем браузер сможет отправить данные приложения, он обычно устанавливает сетевое соединение с помощью трехэтапного рукопожатия TCP. Это классический путь для HTTP 1.1 и HTTP/2. В протоколе HTTP/3 используется протокол QUIC вместо TCP, поэтому пока оставим этот вопрос в стороне. Сначала клиент отправляет SYN-запрос. Сервер подтверждает получение сообщения и отправляет ответное сообщение SYN ACK. Затем клиент отправляет обратно подтверждение (ACK). Теперь TCP-соединение установлено. При использовании обычного протокола HTTP браузер может отправить запрос немедленно. Но вот в чем загвоздка. Всё HTTP- сообщение передаётся в открытом виде. Строка запроса, заголовки, cookie и тело запроса. Если это форма авторизации, то введенные имя пользователя и пароль могут быть прочитаны любым, кто имеет доступ к данным о трафике. В сети общего пользования это может быть вредоносная точка доступа Wi-Fi. Это также может быть прокси-сервер или другое устройство, расположенное между клиентом и сервером. А если злоумышленник может изменять трафик во время его передачи, он также может изменить ответ до того, как он достигнет браузера. Вкратце, HTTP предоставляет нам стандартный формат сообщений, но у него есть три фундаментальные проблемы. Это не обеспечивает конфиденциальность. Это не подтверждает личность сервера. И это не защищает сообщения от изменений во время передачи. В протоколе HTTP эти проблемы решаются добавлением протокола TLS. TLS расшифровывается как Transport Layer Security (безопасность транспортного уровня). SSL был более старым предшественником, поэтому люди до сих пор говорят об SSL-сертификатах. Но современный HTTPS использует TLS. Важно понимать, что HTTPS не заменяет HTTP. Вместо этого, HTTP- сообщение помещается в защищенный туннель. Это HTTP поверх TLS. Для классического TCP-пути начало выглядит так же. Браузер по-прежнему запускается со стандартного TCP-рукопожатия. Но сразу после установления TCP-соединения браузер еще не отправляет HTTP-запрос. Сначала инициируется установление соединения TLS. Процесс установления соединения TLS выполняет две задачи. Во-первых, браузеру необходимо убедиться, что он взаимодействует с настоящим сервером, а не с злоумышленником, выдающим себя за этот сервер. Во-вторых, браузеру и серверу необходимо создать общие ключи, которые смогут защитить остальную часть соединения. Начнём с идентичности. Процесс установления TLS-соединения начинается с приветствия клиента. Это сообщение сообщает серверу, какие версии TLS и криптографические параметры поддерживает браузер. Сервер отвечает сообщением " Server Hello". Оно выбирает параметры для этого соединения и отправляет свой сертификат. Сертификат является удостоверением личности, подтверждающим личность пользователя сайта. Это даёт название домену. Он включает в себя открытый ключ сервера. И он подписан уже доверяют. Прежде чем браузер признает соединение надежным, он проверяет сертификат. Если срок действия сертификата истек, заявка отклоняется. Если сертификат выдан для неверного имени хоста, он также будет отклонен. Браузер также проверяет цепочку сертификатов. Цепочка должна вести к доверенному центру сертификации. Сервер также должен доказать, что он контролирует закрытый ключ, соответствующий открытому ключу в сертификате. Если эти проверки не пройдут, браузер остановится и отобразит предупреждение. Это часть протокола HTTPS, которая предотвращает попытки случайного сервера выдать себя за ваш банк, вашего поставщика электронной почты или вашу внутреннюю панель администратора. Однако сертификат не шифрует каждый байт данных приложения. Сертификат подтверждает подлинность сервера. Для шифрования браузеру и серверу необходимы общие ключи. Это вторая проблема: обмен ключами Это вторая проблема: обмен ключами в ненадежной сети. Во многих объяснениях HTTPS в качестве модели используется более старый протокол обмена ключами RSA из TLS 1.2 . В этой модели клиент генерирует предварительный главный секретный ключ. Она шифрует секрет с помощью открытого ключа сервера, а затем отправляет зашифрованное значение на сервер. Только сервер располагает соответствующим закрытым ключом, поэтому только сервер может его расшифровать. Затем обе стороны определяют симметричные ключи, используемые для сессии. Эта модель полезна, потому что она показывает, почему задействованы открытые и закрытые ключи , но это не тот способ, которым обычно устанавливается общий доступ к ключам в современном HTTPS. В TLS 1.3 был удален статический обмен ключами RSA . Сертификат по-прежнему используется для аутентификации, но общие секреты обычно создаются с помощью временного обмена ключами Диффи-Хеллмана. Проще говоря, клиент и сервер обмениваются временными общедоступными значениями. Каждая сторона хранит свой закрытый ключ в секрете. Используя эти элементы, обе стороны независимо друг от друга вычисляют один и тот же общий секрет. Сам общий секретный ключ никогда не передается по сети. Эта деталь важна, потому что она обеспечивает нам дальнейшую секретность. Если кто-то сегодня запишет зашифрованный трафик, а позже украдет закрытый ключ сертификата сервера, он все равно не сможет расшифровать эти старые сессии. Временные ключи для установления контакта утеряны. Математические основы обмена ключами сложны, но цель проста. Клиент и сервер завершают процедуру установления соединения, используя одни и те же секретные ключи. Наблюдатель недостаточно информации для вычисления этих ключей. На данном этапе браузер знает две вещи. Оно знает, с каким сервером общается, и имеет ключи для защиты соединения. Теперь браузер наконец-то может отправлять HTTP-запросы. В этот раз HTTP-запрос не отправляется по сети в виде читаемого текста. Путь запроса, заголовки, файлы cookie и тело запроса зашифрованы. Наблюдатель может по-прежнему видеть некоторые метаданные соединения, такие как IP-адрес сервера, но он не может прочитать . Сервер расшифровывает данные, обрабатывает HTTP-запрос, а затем отправляет обратно зашифрованный HTTP-ответ. Зачем же переходить на симметричное шифрование? Потому что симметричное шифрование достаточно быстрое для обработки больших объемов данных. Асимметричная криптография полезна для идентификации и согласования ключей, но она дороже по сравнению с симметричным шифрованием. После установления соединения большая часть данных передается по протоколу HTTP. данных передается по протоколу HTTP. Заголовки, cookie, JSON, XML, изображения, ответы API. Для всего этого необходимы эффективное шифрование и защита целостности данных на протяжении всего срока действия соединения. Это позволяет нам получить полную ментальную модель. В классическом варианте TCP устанавливает надежное соединение. Протокол TLS превращает его в защищенный канал. HTTP передает запрос и ответ. При использовании обычного протокола HTTP это сообщение передается по сети напрямую. При использовании HTTPS браузер сначала проверяет сервер и создает новые ключи для передачи трафика. Затем то же самое HTTP-сообщение передается по зашифрованному каналу. Тот же HTTP, но другая модель безопасности. Same HTTP, different security model. That is why the S matters.