Module 2 → Lesson 10 → Part 4 of 8
Как начинается защищенное HTTPS-соединение
Lesson contents
- Что происходит, когда вы открываете сайт
- Как браузер находит сервер
- Как устанавливается соединение
- Как начинается защищенное HTTPS-соединение
What you'll learn
Соединение есть. Но с кем мы разговариваем?
В предыдущей части браузер Emma Lee нашел сетевой адрес academy.example.com → 203.0.113.20 и установил транспортное взаимодействие.
Теперь пакеты могут ходить между сторонами.
Но этого недостаточно.
Emma вводила https://academy.example.com.
Поэтому браузеру нужно решить сразу несколько задач:
- Убедиться, что удаленная сторона имеет право представлять нужное доменное имя.
- Договориться о криптографических параметрах.
- Получить ключи для защищенного обмена.
- Защитить данные от чтения посторонними по пути.
- Обнаруживать недопустимое изменение защищаемых данных.
Этим занимается TLS.
HTTPS — это не просто буква S
Концептуально: HTTP → TLS → TCP → IP.
Для HTTP/3 устройство стека другое: HTTP/3 → QUIC + TLS → UDP → IP.
Но идея та же:
веб-данные передаются через криптографически защищенный канал.
Что TLS должен защитить
У TLS есть три особенно важных для нас свойства.
Конфиденциальность: посторонний участник сетевого пути не должен просто прочитать содержимое защищенного обмена.
Целостность: если защищаемые данные были недопустимо изменены по пути, это должно быть обнаружено.
Аутентификация сервера: браузер должен проверить, что сервер может криптографически подтвердить право представлять запрошенное имя.
Конфиденциальность — это не невидимость
Представим: Emma → ISP → Internet → Server.
После установления TLS содержимое защищенного обмена шифруется.
Но это не означает, что все сетевые следы исчезают.
Для доставки пакетов по-прежнему нужны определенные сетевые сведения.
Например, участники маршрута могут видеть: IP-адреса; время обмена; объемы трафика; сам факт существования соединения.
Поэтому:
зашифрованное соединение ≠ невидимое соединение.
С чего начинается TLS
Упрощенно браузер и сервер проводят TLS handshake.
Концептуально: браузер отправляет ClientHello, сервер отвечает ServerHello и сертификатом, происходит верификация и согласование ключей, и в результате получается защищенное соединение.
Не нужно пока запоминать каждое сообщение.
Главное — понять последовательность.
- 1ClientHello — браузер сообщает поддерживаемые параметры защиты.
- 2ServerHello — сервер выбирает совместимый вариант.
- 3Certificate — сервер предъявляет криптографическое подтверждение для доменного имени.
- 4Key agreement — стороны получают общий секретный материал без простой передачи готового сеансового ключа открытым текстом.
- 5Protected connection — дальнейшие данные защищаются эффективными сеансовыми ключами.
ClientHello
Браузер начинает криптографический разговор.
В ClientHello он сообщает серверу информацию, необходимую для выбора параметров TLS.
Например, какие варианты протокола и криптографических механизмов он способен использовать.
Упрощенно:
«Я умею защищать соединение такими способами. Что поддерживаешь ты?»
ServerHello
Сервер отвечает:
«Используем вот этот совместимый вариант».
Это ServerHello.
После этого стороны знают, какие параметры будут использоваться для текущего соединения.
Но серверу еще нужно представиться
Мы знаем IP: 203.0.113.20.
Но Emma просила academy.example.com.
Поэтому сервер предоставляет TLS-сертификат.
В нашем случае браузеру важно проверить:
сертификат подходит для `academy.example.com`?
Сертификат не говорит: «этот сайт хороший»
Это критически важно.
Сертификат может подтверждать:
сервер имеет действительные криптографические полномочия представлять определенный домен.
Но он не утверждает: что магазин честный; что инвестиционное предложение разумное; что продавец вернет деньги; что сайт не принадлежит мошеннику.
Мошенник может зарегистрировать собственный домен example-secure-login.com и получить для него совершенно действительный TLS-сертификат.
HTTPS будет работать правильно.
Просто пользователь оказался не на том домене.
Поэтому проверяется именно имя
Emma хочет academy.example.com.
Если сервер показывает сертификат только для totally-different.example, браузер должен заметить несоответствие.
Это называется hostname verification, проверка имени.
Это одна из причин, почему нельзя бездумно заменять доменное имя IP-адресом.
Сертификат обычно проверяется именно относительно запрошенного имени.
Кто подписывает сертификат
Браузеру недостаточно получить файл certificate.pdf с текстом:
«Честно обещаем, мы настоящий сервер».
Нужна проверяемая криптографическая цепочка доверия.
Для этого используются Certificate Authorities, CA.
Браузер и операционная система имеют набор доверенных корневых сертификатов.
Цепочка сертификатов
Сертификат сайта может быть подписан не непосредственно корневым CA.
Часто существует цепочка: Root CA → Intermediate CA → Server certificate.
Браузер проверяет эту цепочку до доверенного корня.
Это называется certificate chain.
Что браузер проверяет
На базовом уровне браузеру важно убедиться: сертификат относится к нужному имени; срок его действия подходит; цифровые подписи в цепочке корректны; цепочка приводит к доверенному корню; сертификат допустим для требуемого использования.
Реальная проверка содержит больше деталей.
Но уже видно:
браузер не просто спрашивает сервер «ты настоящий?» и доверяет ответу.
- 1Trusted Root CA — доверенный корень, которому браузер и операционная система изначально доверяют.
- 2Intermediate CA — подтверждает сертификат сервера, сам подтвержден корневым CA.
- 3Server certificate (academy.example.com) — браузер проверяет, что запрошенное имя совпадает с именем в сертификате; если сервер показывает сертификат для другого имени, это NAME MISMATCH.
Сертификат содержит публичный ключ
Мы уже встречали идею пары ключей в криптовалютной части курса.
Здесь она используется в другой задаче.
У сервера есть public key, связанный с сертификатом, и соответствующий private key, который сервер должен защищать.
Публичный и закрытый ключи выполняют разные роли
В TLS сервер использует закрытый ключ, чтобы криптографически доказать владение соответствующими полномочиями.
Браузер может проверить это с помощью публичной информации.
Но весь интернет-трафик не шифруют просто публичным ключом сервера
Это частое упрощение:
«Сервер дал публичный ключ, и теперь весь HTTPS зашифрован этим ключом».
Современный TLS устроен иначе.
Асимметричная криптография используется прежде всего для: аутентификации; безопасного согласования ключевого материала.
А основной объем данных затем защищается симметричным шифрованием.
Почему нужен отдельный ключ соединения
Симметричная криптография намного удобнее для защиты большого объема данных.
В ней стороны используют согласованный секретный ключ.
Упрощенно: TLS handshake → key agreement → session keys → fast encrypted traffic.
Они не являются: паролем пользователя; private key сервера; вечным ключом всего сайта.
Стороны должны получить общий секрет
Возникает вопрос:
Как Emma и сервер получают общий секрет, если раньше безопасного канала между ними не было?
Для этого TLS использует механизм key agreement, согласование ключей.
На современном уровне часто применяются методы на основе Diffie–Hellman и эллиптических кривых.
Математику сейчас не трогаем.
Концептуально: Browser contribution + Server contribution → shared secret → session keys.
Главная идея:
секретный сеансовый ключ не нужно просто отправлять по сети открытым текстом.
Очень грубая аналогия
Представим, что Emma и сервер публично обмениваются некоторыми ингредиентами.
Каждый добавляет собственный секретный ингредиент.
В результате обе стороны получают одинаковый итоговый секрет.
Наблюдатель видит публичную часть процесса, но не должен суметь получить тот же секрет.
Аналогия быстро перестает работать, если пытаться приготовить из нее реальную криптографию.
Но принцип для первого знакомства подходит.
После handshake начинается защищенный обмен
Когда TLS handshake успешно завершен, стороны имеют необходимые ключи.
Теперь HTTP-запрос можно передать внутри защищенного соединения: GET /course.
Для участника сети по пути содержимое выглядит уже не как обычный читаемый HTTP-текст.
TLS защищает не только конфиденциальность
Допустим, злоумышленник по пути пытается изменить Amount: 100 на Amount: 900.
Правильно установленный TLS должен позволить стороне обнаружить недопустимое изменение защищаемых данных.
То есть TLS обеспечивает не только секретность, но и целостность.
Это особенно важно для: банковских операций; учетных записей; API; криптобирж; любых чувствительных действий.
Аутентифицируется прежде всего сервер
В обычном HTTPS браузер обычно проверяет сервер.
То есть браузер спрашивает: подходит ли этот сертификат для academy.example.com?
Но сервер еще не знает:
кто такая Emma.
Это другой уровень.
Позже пользователь может пройти: логин; пароль; passkey; 2FA.
То есть:
TLS-аутентификация сервера
и:
аутентификация пользователя в аккаунте
— разные процессы.
Иногда сертификат может быть и у клиента
Существуют системы mTLS — mutual TLS, где сертификат предъявляет не только сервер, но и клиент.
Такое встречается, например: в корпоративных системах; API; инфраструктурных сервисах.
Но обычному пользователю Web чаще знакома модель, где браузер проверяет сервер, а пользователь затем отдельно входит в свой аккаунт.
Что увидит Emma, если сертификат неправильный
Например: сертификат просрочен; имя не совпадает; цепочка не проходит проверку; сертификат считается недоверенным.
Браузер может показать предупреждение:
Your connection is not private
или аналогичное сообщение.
Это уже не обычная информационная табличка.
Это сигнал:
браузер не смог нормально подтвердить защищенное соединение.
Не следует механически нажимать «Продолжить»
Если пользователь видит серьезное предупреждение TLS на банковском сайте, бирже, кошельке, почте — правильная реакция не:
«браузер опять мешает, нажму Advanced → Continue».
Сначала нужно понять причину.
Она может быть безобидной.
А может означать реальную проблему.
Но нормальный HTTPS тоже не делает сайт безопасным во всех смыслах
Сравним.
Настоящий домен exchange.example имеет правильный сертификат.
Фишинговый домен exchange-example-login.com тоже может иметь правильный сертификат — для своего имени.
Оба соединения могут быть зашифрованы.
Но пользователь хотел попасть только на первый сайт.
Значит, нужно проверять:
кому именно мы установили защищенное соединение.
- 1https://exchange.example — valid TLS, intended domain: пользователь действительно попал туда, куда хотел.
- 2https://exchange-example-login.com — valid TLS, wrong domain for user's intention: соединение тоже зашифровано, но это не тот ресурс. Шифрование отвечает на вопрос о защите соединения. Проверка домена — на вопрос, с тем ли ресурсом пользователь вообще установил соединение.
Именно поэтому домен критически важен
Неправильное мышление:
«Есть замочек — все хорошо».
Лучше: правильный домен? → HTTPS установлен корректно? → нет предупреждений? → доверяю ли я самому сервису?
Это четыре разных вопроса.
Что может видеть провайдер
После установления HTTPS провайдер не должен видеть содержимое защищенных HTTP-данных просто как открытый текст.
Например, он не должен получать читаемый password=EmmaSecret123 из корректно защищенного HTTPS-обмена.
Но определенные метаданные сетевого соединения остаются необходимыми для его маршрутизации.
Например: Client IP ↕ Server IP.
Поэтому снова:
HTTPS защищает содержимое соединения, а не делает сам факт соединения невидимым.
А доменное имя всегда видно?
Здесь ответ уже сложнее.
Исторически имя сервера могло передаваться в TLS ClientHello через механизм SNI в открытом виде.
Современные технологии постепенно развивают защиту этой информации, например с помощью ECH — Encrypted ClientHello.
Но поддержка зависит от: браузера; сервера; DNS; сети; конфигурации.
Поэтому нельзя использовать универсальное утверждение:
«провайдер всегда видит точное доменное имя HTTPS-сайта».
И нельзя говорить обратное:
«HTTPS всегда полностью скрывает домен».
Для нашего уровня достаточно:
HTTPS хорошо защищает содержимое веб-обмена, но видимость метаданных зависит от конкретных технологий и конфигурации.
HTTP/3 немного меняет последовательность
Для классического HTTP/2 поверх TCP можно мысленно представить: TCP handshake → TLS handshake → HTTP/2.
Для HTTP/3: QUIC connection + TLS integration → HTTP/3.
Но пользователю не нужно выбирать эту схему вручную.
Браузер и сервер согласуют доступный вариант.
Почему браузеру вообще можно доверять корневым сертификатам
В браузере и операционной системе существует root trust store — набор доверенных корневых сертификатов.
Именно от него начинается Web PKI.
Это означает, что HTTPS опирается не только на математику.
Он также использует инфраструктуру доверия: Browser / OS → trusted root CAs → certificate chain → server certificate.
То есть даже здесь мы снова видим знакомую идею:
криптография не уничтожает доверие — она помогает формализовать и проверять его.
Это важный мост к криптовалютам
В обычном HTTPS браузер полагается, среди прочего, на: корневые CA; сертификаты; доменные имена; правила Web PKI.
В Bitcoin модель другая: нет TLS-сертификата, подтверждающего право распоряжаться bitcoin; право на транзакцию доказывается цифровой подписью соответствующего ключа.
Криптография используется в обоих случаях.
Но:
модель доверия и задача разные.
Где мы теперь
Наша цепочка стала такой: URL → Name resolution ✓ → IP address ✓ → Transport connection ✓ → TLS handshake ✓ → Protected connection ✓ → HTTP request.
Теперь браузер наконец готов попросить:
«Пришли мне нужную страницу».
И это уже задача HTTP.
Главное, что нужно запомнить
- HTTPS использует TLS для криптографической защиты веб-соединения.
- TLS обеспечивает конфиденциальность, целостность и аутентификацию сервера.
- TLS handshake происходит до обычного защищенного HTTP-обмена.
- Сервер предоставляет сертификат, связанный с доменным именем и публичным ключом.
- Браузер проверяет, подходит ли сертификат для запрошенного имени.
- Цепочка сертификатов должна приводить к доверенному корню.
- TLS-сертификат не доказывает, что владелец сайта честный.
- Мошеннический сайт может иметь совершенно действительный HTTPS-сертификат для собственного домена.
- Асимметричная криптография используется для аутентификации и согласования ключевого материала, а основной обмен защищается эффективными сеансовыми ключами.
- Сеансовые ключи не являются private key сервера или паролем пользователя.
- TLS защищает содержимое и позволяет обнаруживать недопустимое изменение данных.
- Проверка сервера по TLS и вход пользователя в аккаунт — разные процессы.
- Предупреждение браузера о проблеме сертификата нельзя автоматически игнорировать.
- HTTPS не делает сетевое соединение полностью невидимым.
- Точная видимость метаданных зависит от используемых технологий и конфигурации.
- Криптография формализует доверие, но не устраняет его полностью.
Что дальше
Защищенное соединение создано.
Теперь браузер наконец может сказать серверу:
«Мне нужен вот этот ресурс».
Но как выглядит такой запрос?
Что означает GET /course?
Что такое HTTP method; headers; status code; response body; cookie?
И почему 404 совсем не означает то же самое, что 500?
Продолжаем — в следующей части — «HTTP: запрос браузера и ответ сервера».
- HTTPS использует TLS для криптографической защиты веб-соединения.
- TLS обеспечивает конфиденциальность, целостность и аутентификацию сервера.
- TLS handshake происходит до обычного защищенного HTTP-обмена.
- Сервер предоставляет сертификат, связанный с доменным именем и публичным ключом.
- Браузер проверяет, подходит ли сертификат для запрошенного имени.
- Цепочка сертификатов должна приводить к доверенному корню.
- TLS-сертификат не доказывает, что владелец сайта честный.
- Мошеннический сайт может иметь совершенно действительный HTTPS-сертификат для собственного домена.
- Асимметричная криптография используется для аутентификации и согласования ключевого материала, а основной обмен защищается эффективными сеансовыми ключами.
- Сеансовые ключи не являются private key сервера или паролем пользователя.
- TLS защищает содержимое и позволяет обнаруживать недопустимое изменение данных.
- Проверка сервера по TLS и вход пользователя в аккаунт — разные процессы.
- Предупреждение браузера о проблеме сертификата нельзя автоматически игнорировать.
- HTTPS не делает сетевое соединение полностью невидимым.
- Точная видимость метаданных зависит от используемых технологий и конфигурации.
- Криптография формализует доверие, но не устраняет его полностью.
The connection exists. But who are we talking to?
In the previous part, Emma Lee's browser found the network address academy.example.com → 203.0.113.20 and established a transport-level interaction.
Now packets can travel between the parties.
But that's not enough.
Emma had typed https://academy.example.com.
So the browser needs to solve several tasks at once:
- Make sure the remote party has the right to represent the requested domain name.
- Agree on cryptographic parameters.
- Obtain keys for protected exchange.
- Protect the data from being read by outsiders along the way.
- Detect impermissible modification of the protected data.
This is what TLS does.
HTTPS is not just a letter S
Conceptually: HTTP → TLS → TCP → IP.
For HTTP/3 the stack arrangement is different: HTTP/3 → QUIC + TLS → UDP → IP.
But the idea is the same:
web data is transmitted over a cryptographically protected channel.
What TLS has to protect
TLS has three properties that are especially important for us.
Confidentiality: an outside participant on the network path should not simply be able to read the content of the protected exchange.
Integrity: if the protected data was impermissibly modified along the way, this should be detected.
Server authentication: the browser must verify that the server can cryptographically confirm the right to represent the requested name.
Confidentiality is not invisibility
Let's picture: Emma → ISP → Internet → Server.
After TLS is established, the content of the protected exchange is encrypted.
But that doesn't mean all network traces disappear.
Certain network information is still needed to deliver the packets.
For example, participants along the route can see: IP addresses; the timing of the exchange; traffic volumes; the very fact that a connection exists.
So:
an encrypted connection ≠ an invisible connection.
Where TLS begins
Simplified, the browser and the server carry out a TLS handshake.
Conceptually: the browser sends a ClientHello, the server responds with a ServerHello and a certificate, verification and key agreement take place, and the result is a protected connection.
There's no need to memorize every message yet.
What matters is understanding the sequence.
- 1ClientHello — the browser communicates the protection parameters it supports.
- 2ServerHello — the server picks a compatible option.
- 3Certificate — the server presents cryptographic proof for the domain name.
- 4Key agreement — the parties obtain shared secret material without simply sending a ready-made session key in the clear.
- 5Protected connection — further data is protected with efficient session keys.
ClientHello
The browser starts the cryptographic conversation.
In the ClientHello, it tells the server the information needed to choose TLS parameters.
For example, which protocol and cryptographic mechanism options it is able to use.
Simplified:
"I know how to protect the connection in these ways. What do you support?"
ServerHello
The server responds:
"Let's use this compatible option."
This is the ServerHello.
After this, the parties know which parameters will be used for the current connection.
But the server still needs to introduce itself
We know the IP: 203.0.113.20.
But Emma asked for academy.example.com.
So the server provides a TLS certificate.
In our case, it's important for the browser to check:
does the certificate match `academy.example.com`?
A certificate does not say "this site is good"
This is critically important.
A certificate can confirm:
the server has valid cryptographic authority to represent a certain domain.
But it does not claim: that the shop is honest; that the investment offer is reasonable; that the seller will refund the money; that the site isn't run by a scammer.
A scammer can register their own domain example-secure-login.com and obtain a perfectly valid TLS certificate for it.
HTTPS will work correctly.
The user simply ended up on the wrong domain.
That's why it's the name that gets checked
Emma wants academy.example.com.
If the server presents a certificate only for totally-different.example, the browser must notice the mismatch.
This is called hostname verification.
This is one of the reasons you can't thoughtlessly substitute an IP address for the domain name.
A certificate is normally verified specifically against the requested name.
Who signs the certificate
It's not enough for the browser to receive a file called certificate.pdf with the text:
"We honestly promise we're a real server."
A verifiable cryptographic chain of trust is needed.
This is what Certificate Authorities, CAs, are for.
The browser and operating system hold a set of trusted root certificates.
Certificate chain
A site's certificate may not be signed directly by a root CA.
Often there's a chain: Root CA → Intermediate CA → Server certificate.
The browser verifies this chain up to a trusted root.
This is called the certificate chain.
What the browser checks
At a basic level, it's important for the browser to make sure: the certificate applies to the correct name; its validity period is appropriate; the digital signatures in the chain are correct; the chain leads to a trusted root; the certificate is permitted for the required usage.
The actual verification contains more detail.
But it's already clear that:
the browser doesn't simply ask the server "are you real?" and trust the answer.
- 1Trusted Root CA — the trusted root that the browser and operating system trust from the start.
- 2Intermediate CA — validates the server's certificate, and is itself validated by the root CA.
- 3Server certificate (academy.example.com) — the browser checks that the requested name matches the name in the certificate; if the server presents a certificate for a different name, this is a NAME MISMATCH.
The certificate contains a public key
We already encountered the idea of a key pair in the cryptocurrency part of the course.
Here it's used for a different task.
The server has a public key associated with the certificate, and a corresponding private key, which the server must protect.
The public and private keys play different roles
In TLS, the server uses the private key to cryptographically prove possession of the corresponding authority.
The browser can verify this using public information.
But not all internet traffic is simply encrypted with the server's public key
This is a common oversimplification:
"The server gave a public key, and now all HTTPS is encrypted with that key."
Modern TLS is arranged differently.
Asymmetric cryptography is used primarily for: authentication; securely agreeing on key material.
The bulk of the data is then protected with symmetric encryption.
Why a separate connection key is needed
Symmetric cryptography is far more convenient for protecting a large volume of data.
In it, the parties use an agreed secret key.
Simplified: TLS handshake → key agreement → session keys → fast encrypted traffic.
They are not: the user's password; the server's private key; a permanent key for the whole site.
The parties need to obtain a shared secret
A question arises:
How do Emma and the server obtain a shared secret if there was no secure channel between them before?
For this, TLS uses a key agreement mechanism.
At the current state of the art, methods based on Diffie–Hellman and elliptic curves are often used.
We won't touch the math for now.
Conceptually: Browser contribution + Server contribution → shared secret → session keys.
The main idea:
the secret session key doesn't need to simply be sent over the network in the clear.
A very rough analogy
Imagine that Emma and the server publicly exchange some ingredients.
Each adds their own secret ingredient.
As a result, both parties end up with the same final secret.
An observer sees the public part of the process, but shouldn't be able to obtain the same secret.
The analogy quickly stops working if you try to turn it into real cryptography.
But the principle is fine for a first introduction.
After the handshake, the protected exchange begins
Once the TLS handshake completes successfully, the parties have the necessary keys.
Now the HTTP request can be sent inside the protected connection: GET /course.
To a network participant along the path, the content no longer looks like ordinary readable HTTP text.
TLS protects more than just confidentiality
Suppose an attacker along the path tries to change Amount: 100 to Amount: 900.
A properly established TLS connection should let the party detect the impermissible modification of the protected data.
In other words, TLS provides not only secrecy but also integrity.
This matters especially for: banking operations; accounts; APIs; crypto exchanges; any sensitive actions.
It's primarily the server that gets authenticated
In ordinary HTTPS, the browser normally verifies the server.
That is, the browser asks: does this certificate match academy.example.com?
But the server still doesn't know:
who Emma is.
That's a different level.
Later, the user may go through: login; password; passkey; 2FA.
In other words:
TLS server authentication
and:
user authentication into an account
— are different processes.
Sometimes the client can have a certificate too
There are mTLS systems — mutual TLS — where not only the server but also the client presents a certificate.
This is found, for example: in corporate systems; APIs; infrastructure services.
But the ordinary Web user is more familiar with the model where the browser verifies the server, and the user then separately logs into their account.
What Emma will see if the certificate is wrong
For example: the certificate has expired; the name doesn't match; the chain fails verification; the certificate is considered untrusted.
The browser may show a warning:
Your connection is not private
or a similar message.
This is no longer an ordinary informational notice.
It's a signal:
the browser was not able to properly confirm the protected connection.
You shouldn't mechanically click "Continue"
If a user sees a serious TLS warning on a banking site, an exchange, a wallet, or email, the correct reaction is not:
"the browser is getting in the way again, I'll click Advanced → Continue."
First you need to understand the cause.
It could be harmless.
Or it could signal a real problem.
But normal HTTPS doesn't make a site safe in every sense either
Let's compare.
The real domain exchange.example has a correct certificate.
The phishing domain exchange-example-login.com can also have a correct certificate — for its own name.
Both connections can be encrypted.
But the user only wanted to reach the first site.
So it's necessary to check:
exactly whom we've established the protected connection with.
- 1https://exchange.example — valid TLS, intended domain: the user really did end up where they wanted to.
- 2https://exchange-example-login.com — valid TLS, wrong domain for user's intention: this connection is encrypted too, but it's not the intended resource. Encryption answers the question of whether the connection is protected. Checking the domain answers the question of whether the user established a connection with the right resource at all.
This is exactly why the domain is critically important
Wrong thinking:
"There's a padlock — everything's fine."
Better: right domain? → is HTTPS set up correctly? → no warnings? → do I trust the service itself?
These are four separate questions.
What the provider can see
After HTTPS is established, the provider should not see the content of the protected HTTP data as plain text.
For example, it should not be able to obtain a readable password=EmmaSecret123 from a correctly protected HTTPS exchange.
But certain network-connection metadata remains necessary for routing it.
For example: Client IP ↕ Server IP.
So once again:
HTTPS protects the content of the connection, it does not make the very fact of the connection invisible.
Is the domain name always visible?
Here the answer is already more complicated.
Historically, the server name could be transmitted in the TLS ClientHello via the SNI mechanism in the clear.
Modern technologies are gradually developing protection for this information, for example with ECH — Encrypted ClientHello.
But support depends on: the browser; the server; DNS; the network; the configuration.
So you can't use the blanket statement:
"the provider always sees the exact domain name of the HTTPS site."
And you can't say the opposite either:
"HTTPS always completely hides the domain."
For our level, it's enough to say:
HTTPS protects the content of the web exchange well, but the visibility of metadata depends on the specific technologies and configuration in use.
HTTP/3 changes the sequence a little
For classic HTTP/2 over TCP, you can picture it as: TCP handshake → TLS handshake → HTTP/2.
For HTTP/3: QUIC connection + TLS integration → HTTP/3.
But the user doesn't need to choose this scheme manually.
The browser and the server negotiate the available option.
Why the browser can trust root certificates at all
The browser and the operating system have a root trust store — a set of trusted root certificates.
This is exactly where the Web PKI begins.
This means HTTPS relies not only on mathematics.
It also uses a trust infrastructure: Browser / OS → trusted root CAs → certificate chain → server certificate.
In other words, here too we again see the familiar idea:
cryptography doesn't eliminate trust — it helps formalize and verify it.
This is an important bridge to cryptocurrencies
In ordinary HTTPS, the browser relies, among other things, on: root CAs; certificates; domain names; Web PKI rules.
In Bitcoin, the model is different: there is no TLS certificate proving the right to spend bitcoin; the right to a transaction is proven by a digital signature from the relevant key.
Cryptography is used in both cases.
But:
the trust model and the problem being solved are different.
Where we are now
Our chain has become this: URL → Name resolution ✓ → IP address ✓ → Transport connection ✓ → TLS handshake ✓ → Protected connection ✓ → HTTP request.
Now the browser is finally ready to ask:
"Send me the page I need."
And that's already the job of HTTP.
The main thing to remember
- HTTPS uses TLS to cryptographically protect the web connection.
- TLS provides confidentiality, integrity, and server authentication.
- The TLS handshake happens before the regular protected HTTP exchange.
- The server provides a certificate tied to a domain name and a public key.
- The browser checks whether the certificate matches the requested name.
- The certificate chain must lead to a trusted root.
- A TLS certificate does not prove that the site's owner is honest.
- A fraudulent site can have a perfectly valid HTTPS certificate for its own domain.
- Asymmetric cryptography is used for authentication and agreeing on key material, while the main exchange is protected with efficient session keys.
- Session keys are not the server's private key or the user's password.
- TLS protects the content and makes it possible to detect impermissible modification of the data.
- Verifying the server via TLS and the user logging into their account are different processes.
- A browser warning about a certificate problem should not be automatically ignored.
- HTTPS does not make the network connection fully invisible.
- The exact visibility of metadata depends on the technologies and configuration in use.
- Cryptography formalizes trust, but does not fully eliminate it.
What's next
The protected connection has been created.
Now the browser can finally tell the server:
"I need this particular resource."
But what does such a request look like?
What does GET /course mean?
What are an HTTP method; headers; status code; response body; cookie?
And why doesn't 404 mean at all the same thing as 500?
Let's continue — in the next part — "HTTP: the browser's request and the server's response."
- HTTPS uses TLS to cryptographically protect a web connection.
- TLS provides confidentiality, integrity, and server authentication.
- The TLS handshake happens before the regular protected HTTP exchange.
- The server provides a certificate tied to a domain name and a public key.
- The browser checks whether the certificate covers the requested name.
- A certificate chain must lead to a trusted root.
- A TLS certificate doesn't prove the site's owner is honest.
- A scam site can have a perfectly valid HTTPS certificate for its own domain.
- Asymmetric cryptography is used for authentication and key agreement, while the main exchange is protected with efficient session keys.
- Session keys are not the server's private key or the user's password.
- TLS protects content and lets you detect unauthorized changes to data.
- Verifying the server via TLS and a user logging into an account are different processes.
- A browser warning about a certificate problem shouldn't be dismissed automatically.
- HTTPS doesn't make a network connection completely invisible.
- Exact metadata visibility depends on the technologies and configuration in use.
- Cryptography formalizes trust, but doesn't eliminate it entirely.
Η σύνδεση υπάρχει. Αλλά με ποιον μιλάμε;
Στο προηγούμενο μέρος, το πρόγραμμα περιήγησης της Emma Lee βρήκε τη διεύθυνση δικτύου academy.example.com → 203.0.113.20 και δημιούργησε τη μεταφορική σύνδεση.
Τώρα τα πακέτα μπορούν να κυκλοφορούν μεταξύ των δύο πλευρών.
Αλλά αυτό δεν αρκεί.
Η Emma είχε πληκτρολογήσει https://academy.example.com.
Επομένως το πρόγραμμα περιήγησης πρέπει να λύσει αμέσως αρκετά ζητήματα:
- Να βεβαιωθεί ότι η απομακρυσμένη πλευρά έχει το δικαίωμα να αντιπροσωπεύει το απαιτούμενο όνομα τομέα.
- Να συμφωνήσει σχετικά με τις κρυπτογραφικές παραμέτρους.
- Να αποκτήσει κλειδιά για προστατευμένη ανταλλαγή.
- Να προστατεύσει τα δεδομένα από ανάγνωση από τρίτους στη διαδρομή.
- Να εντοπίζει μη επιτρεπτή τροποποίηση των προστατευμένων δεδομένων.
Με αυτό ασχολείται το TLS.
Το HTTPS δεν είναι απλώς ένα γράμμα S
Εννοιολογικά: HTTP → TLS → TCP → IP.
Για το HTTP/3 η δομή της στοίβας είναι διαφορετική: HTTP/3 → QUIC + TLS → UDP → IP.
Αλλά η ιδέα είναι η ίδια:
τα δεδομένα ιστού μεταδίδονται μέσω ενός κρυπτογραφικά προστατευμένου καναλιού.
Τι πρέπει να προστατεύσει το TLS
Το TLS έχει τρεις ιδιότητες που είναι ιδιαίτερα σημαντικές για εμάς.
Εμπιστευτικότητα: ένας τρίτος συμμετέχων στη διαδρομή του δικτύου δεν πρέπει να μπορεί απλώς να διαβάσει το περιεχόμενο της προστατευμένης ανταλλαγής.
Ακεραιότητα: αν τα προστατευμένα δεδομένα τροποποιήθηκαν μη επιτρεπτά στη διαδρομή, αυτό πρέπει να εντοπιστεί.
Πιστοποίηση του διακομιστή: το πρόγραμμα περιήγησης πρέπει να επαληθεύσει ότι ο διακομιστής μπορεί να αποδείξει κρυπτογραφικά το δικαίωμα να αντιπροσωπεύει το ζητούμενο όνομα.
Η εμπιστευτικότητα δεν είναι αορατότητα
Ας φανταστούμε: Emma → ISP → Internet → Server.
Μετά την εγκαθίδρυση του TLS, το περιεχόμενο της προστατευμένης ανταλλαγής κρυπτογραφείται.
Αλλά αυτό δεν σημαίνει ότι εξαφανίζονται όλα τα ίχνη δικτύου.
Για την παράδοση των πακέτων εξακολουθούν να απαιτούνται ορισμένες πληροφορίες δικτύου.
Για παράδειγμα, οι συμμετέχοντες στη διαδρομή μπορούν να δουν: τις διευθύνσεις IP· τον χρόνο της ανταλλαγής· τον όγκο της κίνησης· το ίδιο το γεγονός ότι υπάρχει σύνδεση.
Επομένως:
κρυπτογραφημένη σύνδεση ≠ αόρατη σύνδεση.
Με τι ξεκινά το TLS
Απλοποιημένα, το πρόγραμμα περιήγησης και ο διακομιστής πραγματοποιούν ένα TLS handshake.
Εννοιολογικά: το πρόγραμμα περιήγησης στέλνει ClientHello, ο διακομιστής απαντά με ServerHello και πιστοποιητικό, πραγματοποιείται επαλήθευση και συμφωνία κλειδιών, και το αποτέλεσμα είναι μια προστατευμένη σύνδεση.
Δεν χρειάζεται προς το παρόν να απομνημονεύσουμε κάθε μήνυμα.
Το σημαντικό είναι να κατανοήσουμε την ακολουθία.
- 1ClientHello — το πρόγραμμα περιήγησης δηλώνει τις υποστηριζόμενες παραμέτρους προστασίας.
- 2ServerHello — ο διακομιστής επιλέγει μια συμβατή επιλογή.
- 3Certificate — ο διακομιστής παρουσιάζει κρυπτογραφική απόδειξη για το όνομα τομέα.
- 4Key agreement — οι πλευρές αποκτούν κοινό μυστικό υλικό χωρίς απλή μετάδοση ενός έτοιμου κλειδιού συνεδρίας σε καθαρό κείμενο.
- 5Protected connection — τα περαιτέρω δεδομένα προστατεύονται με αποτελεσματικά κλειδιά συνεδρίας.
ClientHello
Το πρόγραμμα περιήγησης ξεκινά την κρυπτογραφική «συνομιλία».
Στο ClientHello γνωστοποιεί στον διακομιστή τις πληροφορίες που χρειάζονται για την επιλογή των παραμέτρων TLS.
Για παράδειγμα, ποιες εκδοχές του πρωτοκόλλου και ποιους κρυπτογραφικούς μηχανισμούς μπορεί να χρησιμοποιήσει.
Απλοποιημένα:
«Ξέρω να προστατεύω τη σύνδεση με αυτούς τους τρόπους. Εσύ τι υποστηρίζεις;»
ServerHello
Ο διακομιστής απαντά:
«Ας χρησιμοποιήσουμε αυτή τη συμβατή επιλογή».
Αυτό είναι το ServerHello.
Μετά από αυτό, οι δύο πλευρές γνωρίζουν ποιες παράμετροι θα χρησιμοποιηθούν για την τρέχουσα σύνδεση.
Αλλά ο διακομιστής πρέπει ακόμη να συστηθεί
Γνωρίζουμε την IP: 203.0.113.20.
Αλλά η Emma ζήτησε το academy.example.com.
Επομένως ο διακομιστής παρέχει ένα TLS-πιστοποιητικό.
Στην περίπτωσή μας, για το πρόγραμμα περιήγησης είναι σημαντικό να ελέγξει:
το πιστοποιητικό ταιριάζει στο `academy.example.com`;
Το πιστοποιητικό δεν λέει: «αυτός ο ιστότοπος είναι καλός»
Αυτό είναι κρίσιμης σημασίας.
Το πιστοποιητικό μπορεί να επιβεβαιώνει:
ο διακομιστής διαθέτει έγκυρες κρυπτογραφικές εξουσίες να αντιπροσωπεύει έναν συγκεκριμένο τομέα.
Αλλά δεν βεβαιώνει: ότι το κατάστημα είναι έντιμο· ότι η επενδυτική προσφορά είναι λογική· ότι ο πωλητής θα επιστρέψει τα χρήματα· ότι ο ιστότοπος δεν ανήκει σε απατεώνα.
Ένας απατεώνας μπορεί να καταχωρίσει τον δικό του τομέα example-secure-login.com και να αποκτήσει για αυτόν ένα απολύτως έγκυρο TLS-πιστοποιητικό.
Το HTTPS θα λειτουργεί σωστά.
Απλώς ο χρήστης βρέθηκε σε λάθος τομέα.
Γι' αυτό ελέγχεται ακριβώς το όνομα
Η Emma θέλει το academy.example.com.
Αν ο διακομιστής παρουσιάσει πιστοποιητικό μόνο για το totally-different.example, το πρόγραμμα περιήγησης πρέπει να εντοπίσει την ασυμφωνία.
Αυτό ονομάζεται hostname verification, επαλήθευση ονόματος.
Αυτός είναι ένας από τους λόγους για τους οποίους δεν πρέπει να αντικαθιστούμε απερίσκεπτα το όνομα τομέα με μια διεύθυνση IP.
Το πιστοποιητικό συνήθως ελέγχεται ακριβώς σε σχέση με το ζητούμενο όνομα.
Ποιος υπογράφει το πιστοποιητικό
Δεν αρκεί για το πρόγραμμα περιήγησης να λάβει ένα αρχείο certificate.pdf με το κείμενο:
«Σας υποσχόμαστε ειλικρινά ότι είμαστε πραγματικός διακομιστής».
Χρειάζεται μια επαληθεύσιμη κρυπτογραφική αλυσίδα εμπιστοσύνης.
Για αυτό χρησιμοποιούνται οι Certificate Authorities, CA.
Το πρόγραμμα περιήγησης και το λειτουργικό σύστημα διαθέτουν ένα σύνολο έμπιστων ριζικών πιστοποιητικών.
Η αλυσίδα πιστοποιητικών
Το πιστοποιητικό ενός ιστότοπου μπορεί να μην είναι υπογεγραμμένο απευθείας από τη ριζική CA.
Συχνά υπάρχει μια αλυσίδα: Root CA → Intermediate CA → Server certificate.
Το πρόγραμμα περιήγησης ελέγχει αυτή την αλυσίδα μέχρι την έμπιστη ρίζα.
Αυτό ονομάζεται certificate chain.
Τι ελέγχει το πρόγραμμα περιήγησης
Σε βασικό επίπεδο, για το πρόγραμμα περιήγησης είναι σημαντικό να βεβαιωθεί: ότι το πιστοποιητικό αφορά το σωστό όνομα· ότι η περίοδος ισχύος του είναι κατάλληλη· ότι οι ψηφιακές υπογραφές στην αλυσίδα είναι σωστές· ότι η αλυσίδα οδηγεί σε έμπιστη ρίζα· ότι το πιστοποιητικό επιτρέπεται για την απαιτούμενη χρήση.
Ο πραγματικός έλεγχος περιέχει περισσότερες λεπτομέρειες.
Αλλά ήδη φαίνεται:
το πρόγραμμα περιήγησης δεν ρωτάει απλώς τον διακομιστή «είσαι πραγματικός;» και εμπιστεύεται την απάντηση.
- 1Trusted Root CA — η έμπιστη ρίζα, την οποία το πρόγραμμα περιήγησης και το λειτουργικό σύστημα εμπιστεύονται εξαρχής.
- 2Intermediate CA — επιβεβαιώνει το πιστοποιητικό του διακομιστή, ενώ η ίδια είναι επιβεβαιωμένη από τη ριζική CA.
- 3Server certificate (academy.example.com) — το πρόγραμμα περιήγησης ελέγχει ότι το ζητούμενο όνομα ταιριάζει με το όνομα στο πιστοποιητικό· αν ο διακομιστής παρουσιάσει πιστοποιητικό για διαφορετικό όνομα, αυτό είναι NAME MISMATCH.
Το πιστοποιητικό περιέχει δημόσιο κλειδί
Έχουμε ήδη συναντήσει την ιδέα του ζεύγους κλειδιών στο κρυπτονομισματικό μέρος του μαθήματος.
Εδώ χρησιμοποιείται για διαφορετικό σκοπό.
Ο διακομιστής διαθέτει ένα public key που συνδέεται με το πιστοποιητικό, και το αντίστοιχο private key, το οποίο ο διακομιστής πρέπει να προστατεύει.
Το δημόσιο και το ιδιωτικό κλειδί έχουν διαφορετικούς ρόλους
Στο TLS ο διακομιστής χρησιμοποιεί το ιδιωτικό κλειδί για να αποδείξει κρυπτογραφικά την κατοχή των αντίστοιχων εξουσιών.
Το πρόγραμμα περιήγησης μπορεί να το επαληθεύσει με τη βοήθεια δημόσιων πληροφοριών.
Αλλά δεν κρυπτογραφείται όλη η κίνηση του διαδικτύου απλώς με το δημόσιο κλειδί του διακομιστή
Αυτή είναι μια συχνή απλοποίηση:
«Ο διακομιστής έδωσε το δημόσιο κλειδί, και τώρα όλο το HTTPS είναι κρυπτογραφημένο με αυτό το κλειδί».
Το σύγχρονο TLS είναι δομημένο διαφορετικά.
Η ασύμμετρη κρυπτογραφία χρησιμοποιείται πρωτίστως για: την πιστοποίηση· την ασφαλή συμφωνία υλικού κλειδιών.
Ενώ ο κύριος όγκος των δεδομένων στη συνέχεια προστατεύεται με συμμετρική κρυπτογράφηση.
Γιατί χρειάζεται ξεχωριστό κλειδί σύνδεσης
Η συμμετρική κρυπτογραφία είναι πολύ πιο βολική για την προστασία μεγάλου όγκου δεδομένων.
Σε αυτήν οι πλευρές χρησιμοποιούν ένα συμφωνημένο μυστικό κλειδί.
Απλοποιημένα: TLS handshake → key agreement → session keys → fast encrypted traffic.
Δεν είναι: ο κωδικός πρόσβασης του χρήστη· το private key του διακομιστή· ένα αιώνιο κλειδί ολόκληρου του ιστότοπου.
Οι πλευρές πρέπει να αποκτήσουν ένα κοινό μυστικό
Προκύπτει το ερώτημα:
Πώς αποκτούν η Emma και ο διακομιστής ένα κοινό μυστικό, αν πριν δεν υπήρχε ασφαλές κανάλι μεταξύ τους;
Για αυτό το TLS χρησιμοποιεί τον μηχανισμό key agreement, συμφωνία κλειδιών.
Στο σύγχρονο επίπεδο εφαρμόζονται συχνά μέθοδοι βασισμένες στο Diffie–Hellman και σε ελλειπτικές καμπύλες.
Δεν θα ασχοληθούμε τώρα με τα μαθηματικά.
Εννοιολογικά: Browser contribution + Server contribution → shared secret → session keys.
Η κύρια ιδέα:
το μυστικό κλειδί συνεδρίας δεν χρειάζεται να αποστέλλεται απλώς μέσω δικτύου σε καθαρό κείμενο.
Μια πολύ πρόχειρη αναλογία
Ας φανταστούμε ότι η Emma και ο διακομιστής ανταλλάσσουν δημόσια κάποια «συστατικά».
Ο καθένας προσθέτει το δικό του μυστικό «συστατικό».
Ως αποτέλεσμα, και οι δύο πλευρές αποκτούν το ίδιο τελικό μυστικό.
Ένας παρατηρητής βλέπει το δημόσιο τμήμα της διαδικασίας, αλλά δεν πρέπει να μπορεί να αποκτήσει το ίδιο μυστικό.
Η αναλογία σταματά γρήγορα να λειτουργεί αν προσπαθήσουμε να φτιάξουμε από αυτήν πραγματική κρυπτογραφία.
Αλλά η αρχή είναι κατάλληλη για μια πρώτη γνωριμία.
Μετά το handshake αρχίζει η προστατευμένη ανταλλαγή
Όταν το TLS handshake ολοκληρωθεί επιτυχώς, οι πλευρές διαθέτουν τα απαραίτητα κλειδιά.
Τώρα το αίτημα HTTP μπορεί να μεταδοθεί μέσα στην προστατευμένη σύνδεση: GET /course.
Για έναν συμμετέχοντα του δικτύου στη διαδρομή, το περιεχόμενο δεν μοιάζει πλέον με συνηθισμένο αναγνώσιμο κείμενο HTTP.
Το TLS προστατεύει όχι μόνο την εμπιστευτικότητα
Ας υποθέσουμε ότι ένας κακόβουλος στη διαδρομή προσπαθεί να αλλάξει το Amount: 100 σε Amount: 900.
Ένα σωστά εγκατεστημένο TLS πρέπει να επιτρέπει στην πλευρά να εντοπίσει τη μη επιτρεπτή τροποποίηση των προστατευμένων δεδομένων.
Δηλαδή το TLS εξασφαλίζει όχι μόνο την μυστικότητα, αλλά και την ακεραιότητα.
Αυτό είναι ιδιαίτερα σημαντικό για: τραπεζικές συναλλαγές· λογαριασμούς· API· κρυπτονομισματικές πλατφόρμες συναλλαγών· κάθε ευαίσθητη ενέργεια.
Πρωτίστως πιστοποιείται ο διακομιστής
Στο συνηθισμένο HTTPS, το πρόγραμμα περιήγησης συνήθως ελέγχει τον διακομιστή.
Δηλαδή το πρόγραμμα περιήγησης ρωτά: ταιριάζει αυτό το πιστοποιητικό στο academy.example.com;
Αλλά ο διακομιστής δεν γνωρίζει ακόμη:
ποια είναι η Emma.
Αυτό είναι διαφορετικό επίπεδο.
Αργότερα ο χρήστης μπορεί να περάσει από: login· κωδικό πρόσβασης· passkey· 2FA.
Δηλαδή:
η πιστοποίηση του διακομιστή μέσω TLS
και:
η πιστοποίηση του χρήστη στον λογαριασμό
— είναι διαφορετικές διαδικασίες.
Μερικές φορές πιστοποιητικό μπορεί να έχει και ο πελάτης
Υπάρχουν συστήματα mTLS — mutual TLS, όπου πιστοποιητικό παρουσιάζει όχι μόνο ο διακομιστής, αλλά και ο πελάτης.
Κάτι τέτοιο συναντάται, για παράδειγμα: σε εταιρικά συστήματα· API· υπηρεσίες υποδομής.
Αλλά στον συνηθισμένο χρήστη του Web είναι πιο οικείο το μοντέλο όπου το πρόγραμμα περιήγησης ελέγχει τον διακομιστή, και ο χρήστης στη συνέχεια συνδέεται ξεχωριστά στον λογαριασμό του.
Τι θα δει η Emma αν το πιστοποιητικό είναι λανθασμένο
Για παράδειγμα: το πιστοποιητικό έχει λήξει· το όνομα δεν ταιριάζει· η αλυσίδα δεν περνά τον έλεγχο· το πιστοποιητικό θεωρείται μη έμπιστο.
Το πρόγραμμα περιήγησης μπορεί να εμφανίσει προειδοποίηση:
Your connection is not private
ή αντίστοιχο μήνυμα.
Αυτό δεν είναι πλέον μια συνηθισμένη ενημερωτική πινακίδα.
Αυτό είναι σήμα:
το πρόγραμμα περιήγησης δεν κατάφερε να επιβεβαιώσει κανονικά την προστατευμένη σύνδεση.
Δεν πρέπει να πατάμε μηχανικά «Συνέχεια»
Αν ο χρήστης δει σοβαρή προειδοποίηση TLS σε τραπεζικό ιστότοπο, πλατφόρμα συναλλαγών, πορτοφόλι, αλληλογραφία — η σωστή αντίδραση δεν είναι:
«το πρόγραμμα περιήγησης πάλι εμποδίζει, θα πατήσω Advanced → Continue».
Πρώτα πρέπει να κατανοήσουμε την αιτία.
Μπορεί να είναι αβλαβής.
Ή μπορεί να σημαίνει πραγματικό πρόβλημα.
Αλλά ούτε ένα κανονικό HTTPS κάνει τον ιστότοπο ασφαλή με κάθε έννοια
Ας συγκρίνουμε.
Ο πραγματικός τομέας exchange.example έχει σωστό πιστοποιητικό.
Ο τομέας phishing exchange-example-login.com μπορεί επίσης να έχει σωστό πιστοποιητικό — για το δικό του όνομα.
Και οι δύο συνδέσεις μπορεί να είναι κρυπτογραφημένες.
Αλλά ο χρήστης ήθελε να μπει μόνο στον πρώτο ιστότοπο.
Άρα πρέπει να ελέγχουμε:
με ποιον ακριβώς έχουμε δημιουργήσει την προστατευμένη σύνδεση.
- 1https://exchange.example — valid TLS, intended domain: ο χρήστης πράγματι έφτασε εκεί που ήθελε.
- 2https://exchange-example-login.com — valid TLS, wrong domain for user's intention: η σύνδεση είναι επίσης κρυπτογραφημένη, αλλά δεν είναι ο σωστός πόρος. Η κρυπτογράφηση απαντά στο ερώτημα της προστασίας της σύνδεσης. Ο έλεγχος του τομέα απαντά στο ερώτημα αν ο χρήστης δημιούργησε καν σύνδεση με τον σωστό πόρο.
Γι' αυτόν ακριβώς τον λόγο ο τομέας είναι κρίσιμης σημασίας
Λανθασμένη σκέψη:
«Υπάρχει το λουκετάκι — όλα καλά».
Καλύτερα: σωστός τομέας; → το HTTPS είναι εγκατεστημένο σωστά; → δεν υπάρχουν προειδοποιήσεις; → εμπιστεύομαι την ίδια την υπηρεσία;
Αυτά είναι τέσσερα διαφορετικά ερωτήματα.
Τι μπορεί να δει ο πάροχος
Μετά την εγκαθίδρυση του HTTPS, ο πάροχος δεν πρέπει να βλέπει το περιεχόμενο των προστατευμένων δεδομένων HTTP απλώς ως καθαρό κείμενο.
Για παράδειγμα, δεν πρέπει να λαμβάνει αναγνώσιμο password=EmmaSecret123 από μια σωστά προστατευμένη ανταλλαγή HTTPS.
Αλλά ορισμένα μεταδεδομένα της σύνδεσης δικτύου παραμένουν απαραίτητα για τη δρομολόγησή της.
Για παράδειγμα: Client IP ↕ Server IP.
Επομένως και πάλι:
το HTTPS προστατεύει το περιεχόμενο της σύνδεσης, αλλά δεν κάνει αόρατο το ίδιο το γεγονός της σύνδεσης.
Και το όνομα τομέα είναι πάντα ορατό;
Εδώ η απάντηση είναι ήδη πιο περίπλοκη.
Ιστορικά, το όνομα του διακομιστή μπορούσε να μεταδίδεται στο TLS ClientHello μέσω του μηχανισμού SNI σε ανοιχτή μορφή.
Οι σύγχρονες τεχνολογίες αναπτύσσουν σταδιακά την προστασία αυτής της πληροφορίας, για παράδειγμα με τη βοήθεια του ECH — Encrypted ClientHello.
Αλλά η υποστήριξη εξαρτάται από: το πρόγραμμα περιήγησης· τον διακομιστή· το DNS· το δίκτυο· τη ρύθμιση.
Επομένως δεν μπορούμε να χρησιμοποιήσουμε μια καθολική διατύπωση:
«ο πάροχος βλέπει πάντα το ακριβές όνομα τομέα του ιστότοπου HTTPS».
Και δεν μπορούμε να πούμε το αντίθετο:
«το HTTPS κρύβει πάντα πλήρως τον τομέα».
Για το επίπεδό μας αρκεί:
το HTTPS προστατεύει καλά το περιεχόμενο της ανταλλαγής ιστού, αλλά η ορατότητα των μεταδεδομένων εξαρτάται από τις συγκεκριμένες τεχνολογίες και τη ρύθμιση.
Το HTTP/3 αλλάζει λίγο την ακολουθία
Για το κλασικό HTTP/2 πάνω από TCP μπορούμε νοερά να το παραστήσουμε ως: TCP handshake → TLS handshake → HTTP/2.
Για το HTTP/3: QUIC connection + TLS integration → HTTP/3.
Αλλά ο χρήστης δεν χρειάζεται να επιλέξει αυτό το σχήμα χειροκίνητα.
Το πρόγραμμα περιήγησης και ο διακομιστής συμφωνούν τη διαθέσιμη επιλογή.
Γιατί γενικά μπορούμε να εμπιστευόμαστε τα ριζικά πιστοποιητικά του προγράμματος περιήγησης
Στο πρόγραμμα περιήγησης και στο λειτουργικό σύστημα υπάρχει ένα root trust store — ένα σύνολο έμπιστων ριζικών πιστοποιητικών.
Ακριβώς από αυτό ξεκινά το Web PKI.
Αυτό σημαίνει ότι το HTTPS δεν βασίζεται μόνο στα μαθηματικά.
Χρησιμοποιεί επίσης μια υποδομή εμπιστοσύνης: Browser / OS → trusted root CAs → certificate chain → server certificate.
Δηλαδή και εδώ βλέπουμε ξανά μια γνώριμη ιδέα:
η κρυπτογραφία δεν καταργεί την εμπιστοσύνη — βοηθά να την τυποποιήσουμε και να την επαληθεύσουμε.
Αυτή είναι μια σημαντική γέφυρα προς τα κρυπτονομίσματα
Στο συνηθισμένο HTTPS, το πρόγραμμα περιήγησης βασίζεται, μεταξύ άλλων, σε: τις ριζικές CA· τα πιστοποιητικά· τα ονόματα τομέα· τους κανόνες του Web PKI.
Στο Bitcoin το μοντέλο είναι διαφορετικό: δεν υπάρχει TLS-πιστοποιητικό που να επιβεβαιώνει το δικαίωμα διάθεσης bitcoin· το δικαίωμα για τη συναλλαγή αποδεικνύεται με την ψηφιακή υπογραφή του αντίστοιχου κλειδιού.
Η κρυπτογραφία χρησιμοποιείται και στις δύο περιπτώσεις.
Αλλά:
το μοντέλο εμπιστοσύνης και το πρόβλημα είναι διαφορετικά.
Πού βρισκόμαστε τώρα
Η αλυσίδα μας έγινε: URL → Name resolution ✓ → IP address ✓ → Transport connection ✓ → TLS handshake ✓ → Protected connection ✓ → HTTP request.
Τώρα το πρόγραμμα περιήγησης είναι επιτέλους έτοιμο να ζητήσει:
«Στείλε μου τη σελίδα που χρειάζομαι».
Και αυτό είναι πλέον έργο του HTTP.
Τι πρέπει κυρίως να θυμόμαστε
- Το HTTPS χρησιμοποιεί το TLS για την κρυπτογραφική προστασία της σύνδεσης ιστού.
- Το TLS εξασφαλίζει την εμπιστευτικότητα, την ακεραιότητα και την πιστοποίηση του διακομιστή.
- Το TLS handshake πραγματοποιείται πριν από τη συνηθισμένη προστατευμένη ανταλλαγή HTTP.
- Ο διακομιστής παρέχει πιστοποιητικό συνδεδεμένο με το όνομα τομέα και το δημόσιο κλειδί.
- Το πρόγραμμα περιήγησης ελέγχει αν το πιστοποιητικό ταιριάζει στο ζητούμενο όνομα.
- Η αλυσίδα πιστοποιητικών πρέπει να οδηγεί σε έμπιστη ρίζα.
- Το TLS-πιστοποιητικό δεν αποδεικνύει ότι ο ιδιοκτήτης του ιστότοπου είναι έντιμος.
- Ένας ιστότοπος απάτης μπορεί να έχει ένα απολύτως έγκυρο HTTPS-πιστοποιητικό για τον δικό του τομέα.
- Η ασύμμετρη κρυπτογραφία χρησιμοποιείται για την πιστοποίηση και τη συμφωνία υλικού κλειδιών, ενώ η κύρια ανταλλαγή προστατεύεται με αποτελεσματικά κλειδιά συνεδρίας.
- Τα κλειδιά συνεδρίας δεν είναι το private key του διακομιστή ούτε ο κωδικός πρόσβασης του χρήστη.
- Το TLS προστατεύει το περιεχόμενο και επιτρέπει τον εντοπισμό μη επιτρεπτής τροποποίησης δεδομένων.
- Ο έλεγχος του διακομιστή μέσω TLS και η σύνδεση του χρήστη στον λογαριασμό είναι διαφορετικές διαδικασίες.
- Η προειδοποίηση του προγράμματος περιήγησης για πρόβλημα πιστοποιητικού δεν πρέπει να αγνοείται αυτόματα.
- Το HTTPS δεν κάνει τη σύνδεση δικτύου εντελώς αόρατη.
- Η ακριβής ορατότητα των μεταδεδομένων εξαρτάται από τις χρησιμοποιούμενες τεχνολογίες και τη ρύθμιση.
- Η κρυπτογραφία τυποποιεί την εμπιστοσύνη, αλλά δεν την εξαλείφει πλήρως.
Τι ακολουθεί
Η προστατευμένη σύνδεση έχει δημιουργηθεί.
Τώρα το πρόγραμμα περιήγησης μπορεί επιτέλους να πει στον διακομιστή:
«Χρειάζομαι αυτόν εδώ τον πόρο».
Αλλά πώς μοιάζει ένα τέτοιο αίτημα;
Τι σημαίνει GET /course;
Τι είναι το HTTP method· headers· status code· response body· cookie;
Και γιατί το 404 δεν σημαίνει καθόλου το ίδιο με το 500;
Συνεχίζουμε — στο επόμενο μέρος — «HTTP: το αίτημα του προγράμματος περιήγησης και η απάντηση του διακομιστή».
- Το HTTPS χρησιμοποιεί το TLS για την κρυπτογραφική προστασία μιας σύνδεσης web.
- Το TLS παρέχει εμπιστευτικότητα, ακεραιότητα και πιστοποίηση του server.
- Το TLS handshake συμβαίνει πριν από τη συνήθη προστατευμένη ανταλλαγή HTTP.
- Ο server παρέχει ένα πιστοποιητικό συνδεδεμένο με ένα όνομα τομέα και ένα δημόσιο κλειδί.
- Το πρόγραμμα περιήγησης ελέγχει αν το πιστοποιητικό καλύπτει το αιτούμενο όνομα.
- Μια αλυσίδα πιστοποιητικών πρέπει να οδηγεί σε μια έμπιστη ρίζα.
- Ένα πιστοποιητικό TLS δεν αποδεικνύει ότι ο κάτοχος του ιστότοπου είναι έντιμος.
- Ένας απατηλός ιστότοπος μπορεί να έχει ένα απολύτως έγκυρο πιστοποιητικό HTTPS για το δικό του domain.
- Η ασύμμετρη κρυπτογραφία χρησιμοποιείται για πιστοποίηση και συμφωνία κλειδιών, ενώ η κύρια ανταλλαγή προστατεύεται με αποδοτικά κλειδιά συνεδρίας.
- Τα κλειδιά συνεδρίας δεν είναι το ιδιωτικό κλειδί του server ούτε ο κωδικός πρόσβασης του χρήστη.
- Το TLS προστατεύει το περιεχόμενο και επιτρέπει τον εντοπισμό μη επιτρεπόμενων αλλαγών στα δεδομένα.
- Η επαλήθευση του server μέσω TLS και η σύνδεση του χρήστη σε έναν λογαριασμό είναι διαφορετικές διαδικασίες.
- Μια προειδοποίηση του προγράμματος περιήγησης για πρόβλημα πιστοποιητικού δεν πρέπει να αγνοείται αυτόματα.
- Το HTTPS δεν καθιστά μια δικτυακή σύνδεση εντελώς αόρατη.
- Η ακριβής ορατότητα των μεταδεδομένων εξαρτάται από τις τεχνολογίες και τη διαμόρφωση που χρησιμοποιούνται.
- Η κρυπτογραφία διαμορφώνει την εμπιστοσύνη, αλλά δεν την εξαλείφει εντελώς.