Данная статья написана для общего понимания принципов устройства современного WEB, и почему то, чем мы пользуемся сейчас – сложилось именно так. В ней достаточно много упрощений. Просьба не использовать данный материал как учебное пособие, а лишь понять общие принципы. В общем, относитесь к статье как к генерации нейросети: выглядит правдоподобно, но есть нюанс.

Глава 1. С чего всё начиналось

Сначала всё было просто. Настолько просто, что даже хорошо. У двух закадычных друзей (пусть будут Джон и Иван) появилось по компьютеру. Иван, будучи деятельным человеком, быстро нашел применение проводу типа «витая пара», который уже несколько лет валялся в гараже без дела после ремонта электроники в любимом запорожце: этим незамысловатым проводом компьютеры незамедлительно были соединены. Что-то типа такого:

Чтобы понимать, кто есть кто – назначили этим компьютерам адреса: 192.168.0.1 Джону и 192.168.0.2 Ивану. И назвали эти адреса «IP». Получилась простая сеть из двух компьютеров.

Иван, в поисках хоть какого-то полезного применения своему современному (на тот момент) ПК, решил не просто записывать в него заметки, а вести блог: оформлять свои мысли в виде сайта, на который Джон мог зайти по адресу его компьютера. Даже логотип красивый сделал, в котором на картинке, поиграв со шрифтами, нафотошопил надпись «HABRAHABR». В тот момент так просто красиво показалось. И остроумно.

Выглядело это так: когда компьютер Ивана включен – Джон в адресной строке браузера вводит 192.168.0.2, его компьютер отправляет запрос по указанному адресу (на компьютер Ивана), тот, в свою очередь, отвечает страничкой блога с заметками.

И все были довольны. Но шло время, компьютерная техника развивалась, становилась более доступной, и к Джону с Иваном пришли друзья с требованием подключить к сети и их компьютеры тоже. Иван, не растерявшись, заказал на маркетплейсе коммутатор. Получилось вот так:

Теперь блог Ивана могли читать уже три человека.

А так как блог был доступен только пока компьютер включен – Иван решил продать свой запорожец и поставить на его место сервер, который работал круглосуточно и показывал его блог всем желающим. Получилось так:

И тут пришла проблема, откуда не ждали: раньше пользователи заходили блог почитать по 192.168.0.2, а теперь он переехал на 192.168.0.5, и многие (точнее, все три) путались в адресах. Иван незамедлительно купил второй гараж и решил провернуть ту же схему: поставить в него сервер. И назвать его Domain Name Service.

Идея была проста: пусть друзья в адресную строку браузера вводят не IP-адрес (192.168.0.5), а название сайта (название взял прямо из логотипа блога, немного для удобства сократив – habr.com). Получилась многоходовочка:

1. браузер сначала пойдет к DNS-серверу, скажет ему название сайта, DNS-сервер в ответ сообщит, на каком IP-адресе этот сайт расположен;

2. браузер уже привычным старым способом обратится к серверу по IP.

Тогда можно будет один раз добавить в настройки компьютера IP-адрес DNS-сервера, а затем вводить название сайта и попадать в блог к Ивану. А если сайт опять переедет – исправить его адрес в DNS, и все продолжат заходить привычным способом по названию (к тому времени название сайта в DNS уже стали именовать не иначе, как «доменное имя»).

А еще спустя какое-то время обнаружилось, что в других компаниях друзей эволюция пошла по тому же пути, и у всех этих компаний своя маленькая сеть есть, и интересно бы им всем друг друга блоги читать. Вот только адреса в сетях все себе разные установили (не сговариваясь), и неплохо бы маршрутизатор поставить, чтобы между сетями трафик передавать. И DNS сервер общий для всех сделать, чтобы удобнее было.

А еще надежнее будет – серверы с блогами в дата-центр перевезти(к тому времени Иван уже продал гаражи и купил ангар с небольшой атомной электростанцией неподалеку), да маршрутизаторов добавить для отказоустойчивости (а заодно назвать это «интернет-провайдером»). Получилось что-то, уже походящее на современный интернет. И новых участников подключать легко:

На маршрутизаторах указали направления(маршруты): где какая сеть находится, чтобы маршрутизатор понимал, куда отправлять запрос каждого пользователя.

Теперь, когда один из пользователей вводил в строку браузера habr.com, происходило следующее:

1. браузер отправляет по заранее известному адресу DNS-сервера 8.8.8.8 вопрос: «какой ip у habr.com?»;

2. запрос проходит через сеть, маршрутизаторы передают его друг другу, в итоге доходит до DNS-сервера и тот отвечает: «178.248.237.68»;

3. браузер спрашивает у сервера по адресу 178.248.237.68, в заголовке запроса на всякий случай уточняя: «хочу habr.com»;

4. маршрутизаторы передают трафик по цепочке, сервер отвечает страничкой с блогом.

В натуральном виде процесс выглядит как-то так:

Красота, да и только.

Глава 2. Закрались смутные сомнения…

Интернет — штука децентрализованная. То есть нет единого управляющего центра. Кто с кем договорился соединиться — такие маршруты и получились. В конечном итоге это вылилось в небольшой, но контролируемый определенными правилами хаос:

Чтобы пользователю добраться до сервера — есть сразу несколько маршрутов. Притом от разных провайдеров. Маршрут эти провайдеры выбирают сами, по желанию левой пятки: какой короче, какой менее загружен, какой вообще доступен в данный момент.

И тут какой-нибудь скучающий хакер, сидя в столовой и бесстрастно разглядывая солонку, думает: а не организовать ли мне своего провайдера, да не направлять ли запросы пользователя не к месту назначения, а на свой личный сервер? Технически ведь ничего не мешает. Да что там личный сервер поднимать — буду просто читать все, что люди пересылают, да номера банковских карточек из потока информации выуживать! Или прям тут, в этой столовой, достану свой большой и толстый ноутбук, да буду из открытого WiFi сессии пользователей от сайтов воровать. И все-таки с этой солонкой что-то не так…

Когда Джон с Иваном свою маленькую уютную сеть проектировали — такой проблемы еще не существовало. Все друг друга в лицо знали и за подобные шутки могли отвезти в гараж и заставить сервер перезагружать, когда тот зависает. В качестве наказания. А теперь сеть стала большой, пользователей много, поставщиков услуг интернета — еще больше, данные по открытому WiFi летают — за всем не уследишь.

Векторов атак определили аж целых две штуки:

1. передаваемые в открытом виде данные по всему маршруту следования могут видеть все;

2. кто угодно по пути может подменить место назначения.

На удивление, решений тоже придумали два:

1. все передаваемые данные должны быть зашифрованы;

2. необходимо убедиться, что на той стороне отвечает именно тот сервер, на который отправлен запрос.

К реализации решений подошли со всей ответственностью.

Для начала определили доверенное лицо. Централизованное. Одно. Больше — никаких распределенных систем (на ошибках ведь учатся). Так как у Ивана уже был блог, дата-центр и небольшая атомная электростанция – забот хватало, поэтому ответственность на себя взял Джон, организовав компанию… назовем ее вымышленным именем Sectigo.

Компания придумала невиданную до тех времен технологию: сертификат. Работать эта технология должна следующим образом:

1. Есть компания Джона, которой все доверяют. У нее есть самый главный сертификат — корневой.

2. Джон этим корневым сертификатом может удостоверять (гарантировать достоверность) других сертификатов, уровнем пониже.

3. Сертификаты уровнем пониже, в свою очередь, могут удостоверять сертификаты уровнем еще пониже, и так далее по цепочке, сколько угодно раз. Назвали все эти последовательные удостоверения “цепочкой сертификатов”.

Для понимания происходящего далее нужно уточнить, из чего этот самый сертификат состоит:

1. Два связанных между собой ключа. Обычно их называют «ключевая пара». Создается эта «ключевая пара» следующим образом: генерируется набор случайных данных, затем специальным алгоритмом на основе этих данных генерируется первый ключ; зная, на каких исходных данных он сгенерирован – генерируется второй. После чего набор заложенных в основу случайных данных уничтожается, и остается только два сгенерированных ключа. Это чтобы никто не смог украсть те данные и таких же ключей нагенерировать. Ключевая пара обладает следующими свойствами: если что-то зашифровать одним (любым) ключом — это можно расшифровать только вторым из этой пары. То есть зашифровать одним ключом, и этим же самым ключом расшифровать — не получится.

   • Один из ключей будем называть «Открытый» — пусть его знают все. Хранить будем прямо в сертификате в открытом виде.

   • Второй, соответственно — «Закрытый». Его знает только владелец сертификата. Который ключевую пару сам генерировал. Хранить будем на флешке в сейфе. И доставать только по праздникам по острой необходимости.

2. Данные о домене, для которого он выпущен.

3. Данные о том, кто его подписал (или удостоверил; иными словами – гарантирует его подлинность).

4. Криптографическая подпись.

   • Подписывает его какой-то другой («родительский») сертификат.

   • Подпись делается очень просто: «родительский» сертификат считает хеш «дочернего» сертификата и шифрует его своим закрытым ключом. И дочерний сертификат хранит этот зашифрованный хеш в себе.

   • Для того, чтобы проверить, что дочерний сертификат действительно подписан родительским – выполняем обратную процедуру: необходимо посчитать хеш дочернего, взять открытый ключ родительского, расшифровать этим ключом подпись дочернего, и сравнить расшифрованное с посчитанным нами хешем. Если совпали – значит, подпись действительна.

Решает сертификат сразу несколько проблем:

1. Видно, кому сертификат принадлежит.

2. Видно, кто приложил свою подпись к выпуску этого сертификата — т.е. кто несёт ответственность за его достоверность.

3. Можно подписывать сертификаты «по цепочке»: распределять нагрузку между доверенными лицами и перекладывать ответственность ниже по иерархии.

4. Можно использовать ключевую пару для чего-то еще (например, для шифрования произвольных данных при передаче через интернет – это нам ниже пригодится для https соединения).

Теперь вернемся к Джону и его компании Sectigo. Что они сделали:

1. Sectigo выпустила для себя сертификат и гордо внесла в него свое имя. Получилось название владельца сертификата — Sectigo Public Server Authentication Root E46. Так как других сертификатов еще не существовало и «родительским» подписать его нельзя – подписала своим собственным закрытым ключом. И назвала это «самоподписанный корневой сертификат» (CA Root Certificate). Наделила этот сертификат правом подписи других сертификатов. И обязала всех производителей компьютеров, ноутбуков, планшетов, телефонов, холодильников, чайников и кроссовок с WiFi устанавливать этот сертификат сразу при выпуске устройства.

2. Использовать напрямую корневой сертификат для выпуска других сертификатов — опасно: если закрытый ключ украдут — будет катастрофа (потому что смогут навыпускать каких угодно сертификатов). Придется отзывать корневой сертификат, выпускать новый — а с ним уже столько чайников и холодильников продано… Везде заменить – нереально. Поэтому выпустила промежуточный — назовем его для примера Sectigo Public Server Authentication CA DV E36. Если его ключ украдут — отзовем сертификат и выпустим новый ему на замену. Беда, но не таких масштабов, как с корневым.

3. И открыли свои двери для всех желающих: приходите к нам с паспортом, показывайте выписку из ЕРДДЦ (единого реестра доменов в дата-центре) что доменное имя принадлежит именно вам, приносите свой Certificate Signing Request (это созданный вами сертификат, который отличается от полноценного только отсутствием подписи) — и если в нем все правильно (название и домен как в выписке ЕРДДЦ), мы его подпишем своим закрытым ключом, и будет у вас свой сертификат на свой домен. С ключевой парой, которую вы сами у себя в тайне от всех сгенерировали — мы только подписали сертификат, сами ключи не видели.

Обрадованный Иван сгенерировал CSR, указав в нем домен (сразу, на всякий случай, с возможностью использования на всех поддоменах) — «*.habr.com», пришел с ним, паспортом и выпиской к Джону, и получил подписанный Джоном сертификат для своего домена.

В итоге у Ивана на руках есть:

1. Ключевая пара, которую он сам сгенерировал (когда готовил CSR-запрос для выпуска сертификата; один из ключей — закрытый — он никому не показывает).

2. Подписанный Джоном сертификат для его домена.

Иван устанавливает сертификат на свой сервер с блогом, и в адресной строке браузера отображается красивое слово: «https://».

Что теперь происходит, когда пользователь заходит на https://habr.com:

1. Браузер отправляет запрос к DNS-серверу, получает IP-адрес, на котором располагается домен;

2. Браузер отправляет запрос на IP-адрес, уточняя в заголовке: «хочу habr.com»;

3. Сервер, видя домен и наличие у себя ключевой пары и сертификата для этого домена, отправляет браузеру в ответ свой сертификат и цепочку всех сертификатов между своим и корневым.

4. Браузер, получив сертификат и всю цепочку посредников сертификатов, производит следующие манипуляции:

   • Проверяет, что пришедший к нему сертификат подписан «родительским» из пришедшей же цепочки;

   • Для «родительского» снова проверяет подпись уже его «родительским», и так пока не дойдет до корневого;

   • Когда видит корневой — смотрит у себя в системе: есть такой в списке доверенных корневых? Если есть, и все подписи по цепочке сошлись — значит, сертификат настоящий. Если корневой сертификат не находится в списке доверенных — браузер прервет соединение и выдаст ошибку. Что-то типа «Не удалось проверить подлинность сертификата. Продолжайте на свой страх и риск. Там вот даже кнопочка снизу есть — все равно продолжить».

   • Придумывает случайный ключ шифрования (назовем его «сессионный ключ шифрования», именно им будет зашифрован потом весь трафик); этот сессионный ключ шифрует открытым ключом сертификата домена, и отправляет серверу;

5. Сервер, имея закрытый ключ сертификата, который знает только он, расшифровывает сообщение браузера и достает оттуда сессионный ключ, придуманный браузером.

   • А что, если другой (поддельный) сервер попробует выступить в качестве настоящего и отправит настоящий сертификат? Сертификат-то всем доступен. Ни к чему толковому это не приведет: получив зашифрованный открытым ключом сертификата сессионный ключ шифрования от браузера — не имея закрытого ключа — поддельный сервер просто не сможет его расшифровать, и соединение с браузером поддерживать не сможет.

6. Теперь у сервера и клиента есть одинаковый сессионный ключ шифрования, созданный для этой сессии обмена данными, и они используют его для шифрования всех данных, передаваемых друг другу далее в этом соединении.

Как видим, все закончилось хорошо. Опасную децентрализованную инфраструктуру маршрутизации через много случайных (ну, почти случайных) провайдеров спасли end-to-end шифрованием от компьютера пользователя до сервера с доменом назначения с использованием сертификатов и ключей к ним. Браузеры помогали переходу на защищенные соединения, как могли – стали выдавать предупреждения о небезопасном соединении на всех сайтах, где нет https. Владельцам сайтов просто пришлось устанавливать сертификаты.

Глава 3. Не тут-то было!..

…воскликнул обрадованный хакер, отводя взгляд от осточертевшей солонки.

 — У вас вот как раньше было? Весь трафик в открытом виде, все видно: я сайт с вирусами — вы в ответ антивирусом пищите, как свинья резаная. А сейчас что? Трафик весь от браузера и дальше зашифрован. Я сейчас вредоносных сайтов насоздаю – все скамеры обзавидуются! И ни один антивирус не предупредит: трафик-то не видно. А у меня — и XSS в арсенале, и плагины нехорошие в наличии, и эксплоитов вчера из даркнета накачал…
 — Справедливо. — ответили разработчики антивирусов и безопасники предприятий, у которых с приходом https перестали работать DPI системы на границах защищенного периметра.

Над решением новой проблемы долго колдовать не стали: не можешь победить — возглавь.

Идея простая:

1. Нужно направить трафик пользователя через контролируемый нами ресурс (назовем его «сервер с DPI-системой»);

2. Соединение между пользователем и сайтом на этом нашем сервере разорвать и превратить в два разных защищенных соединения: «пользователь — наш сервер» и «наш сервер — сайт» (а пока данные находятся в открытом виде – их можно читать и анализировать).

Реализация тоже получилась несложная (на примере организации; у антивируса схема такая же, но все реализовано в пределах компьютера пользователя):

1. Местному сисадмину на коленке сгенерировать для нашего DPI-сервера корневой сертификат и установить его как доверенный на компьютер сотрудникам фирмы;

2. Сетевому инженеру пустить весь трафик сотрудников через этот сервер с системой DPI;

3. DPI сервер принимает соединение от сотрудника на себя, и:

   • смотрит, куда пользователь хочет пойти (домен habr.com в заголовке запроса видно);

   • для запрашиваемого домена выпускает от своего имени (DPI-сервера) сертификат и отвечает им сотруднику;

   • теперь с сотрудником установлено защищенное соединение — между его компьютером и сервером DPI, выступающим в качестве сайта habr.com. Браузер видит такое соединение как защищенное. Если не посмотреть, кем выдан сертификат на домен — не узнаешь, что вместо настоящего habr.com общаешься с DPI-сервером;

4. DPI сервер уже от своего имени устанавливает новое соединение с habr.com;

5. DPI принимает данные от пользователи, расшифровывает как легитимный получатель (сам же сертификат только что сгенерировал), затем шифрует в контексте соединения с настоящим habr.com и отправляет туда; ответ расшифровывает, шифрует для соединения с сотрудником и передает на устройство сотрудника.

Таким образом весь трафик сотрудника DPI сервер видит в открытом виде и может анализировать.

В народе такой способ перехвата трафика прижился под названием «Man in the Middle» (MITM).

Для реализации должны выполняться одновременно два условия:

1. Пропустить трафик через себя;

2. Чтобы у пользователя был установлен наш корневой сертификат как доверенный.

Пропустить трафик через себя можно несколькими путями:

1. Если пользователь использует классический DNS — его ответы можно подменять;

2. Если пользователь получает сетевые настройки по DHCP — можем указать любой DNS-сервер на наш вкус (настроить свой DNS-сервер умеет кто угодно, даже ваш домашний роутер);

3. Если есть доступ к маршрутизации трафика — можем направлять не по реальному назначению, а в наш сегмент сети с таким же ip-адресом, как у настоящего DNS-сервера, и отвечать от его имени (от такой атаки защитит использование DNS over HTTPS / DNS over TLS).

Установить наш сертификат пользователю чуть сложнее — либо мы ставим руками (если это сотрудник нашей организации), либо упрашиваем уговорами, либо заставляем фишингом, либо вирусным ПО.

Глава 4. И вот мы здесь

Если маршрутизация трафика в интернете — штука децентрализованная и нарушить ее работоспособность сложно, то сертификаты безопасности — система централизованная. Удостоверяющий центр, который выдал кому-то сертификат — может этот сертификат так же просто отозвать. Именно с этой проблемой столкнулись банки в августе 2026 года.

Решение очевидное: нам не хотят давать сертификат в этом удостоверяющем центре — пойдем к другому. И в качестве «другого» выступил удостоверяющий центр Минцифры.

Проблема лишь в том, что корневой сертификат Минцифры разработчики операционных систем не добавляют в список доверенных по-умолчанию (при выпуске операционной системы на рынок). Поэтому пользователям приходится производить процедуру установки их корневого сертификата руками — в систему, в конкретный браузер, в профиль браузера.

Глава последняя. Вопросы, которые могли возникнуть после прочтения

Так весь интернет видит, куда я хожу?

Во времена массового использования HTTPS интернет видит домены, к которым вы обращаетесь, и только в трех случаях:

1. использование DNS в его классическом виде (без DoH/DoT);

2. обращение к сайту по http вместо https; сайт переадресует на https, но первый запрос раскроет домен и запрашиваемую страницу;

3. в заголовках TLS-соединения, если не используется TLS 1.3 с расширением Encrypted Client Hello; совсем новая фича, но ее активно блокируют многие провайдеры. Антивирусы и DPI системы между устройством и собой тоже блокируют, но далее трафик могут отправлять уже TLS 1.3 ECH, т.е. видеть будут только они, но не весь интернет.

Подключение к DNS небезопасно и его ответы могут читать/подменять?

В классическом виде – да. Используйте DoH/DoT (DNS over HTTPS, DNS over TLS).

Установить корневой сертификат доверенным – какие могут быть последствия?

Сертификаты бывают с разными правами. Какими-то подписывают программы, какими-то – домены при интернет-соединениях. Опасность возникает, когда злоумышленник может реализовать одновременно две угрозы:

1. выпустить сертификат, который на устройстве пользователя пройдет проверку подлинности (цепочка подписей доведет до доверенного корневого сертификата);

2. направить трафик пользователя на/через свой сервер с поддельным доменом, для которого сам выпустит сертификат, или дать пользователю exe-файл, который подпишет своим сертификатом.

А можно не устанавливать корневой сертификат доверенным, а я самостоятельно глазами каждый раз при входе на сайт сертификат проверять буду? И нажимать кнопку «все равно продолжить»?

Можно. Для этого необходимо выполнить два шага:

1. Убедиться, что сертификат сайта содержит в списке доменов адрес сайта;

2. Убедиться, что корневой сертификат действительно настоящий.

Первый пункт можно посмотреть в параметре сертификата сайта «Subject Alternative Name».

Второй пункт чуть сложнее. У сертификата два уникальных параметра: открытый ключ (Public Key) и отпечаток (Thumbprint). Нужно запомнить один из них, посмотрев в настоящем корневом сертификате, и по памяти сравнивать. Открытый ключ длинный и некрасивый – его запоминать неудобно, поэтому смотрят обычно на отпечаток.

Стоит уточнить: некоторые сайты технически устроены так, что нажатие кнопки «все равно продолжить» не сработает. А еще некоторые браузеры обрабатывают это нажатие специфически: на iOS в Safari нужно нажать «продолжить» — после этого ничего не произойдет, будто ссылка не нажалась — обновить страницу, и доступ к сайту появится.

Уже практикую проверку сертификатов взглядом, но всегда сверяю по серийному номеру!

Серийный номер не является уникальным и может быть указан любым при выпуске сертификата. То есть можно выпустить несколько разных сертификатов с одинаковым серийным номером. Серийный номер нужен удостоверяющему центру для своих внутренних задач.

В статье написано, что Джон владеет одновременно и интернет-провайдером, и удостоверяющим центром — разве это безопасно?

Разумеется, это художественный вымысел — в реальном мире такое невозможно. Потому что доверия к такому удостоверяющему центру не будет (см. предыдущий абзац).

Почему столько изобретений с изоляцией сертификатов Минцифры?

От безграмотности. Минцифры является лишь удостоверяющим центром, который не заинтересован и не может влиять на маршрутизацию трафика, его перехват или подмену. Например, ТСПУ, через которые проходит наш трафик — принадлежат Роскомнадзору. Вы можете самостоятельно найти в интернете информацию про оба ведомства. Поэтому устанавливать корневой сертификат Минцифры в качестве доверенного — совершенно безопасно.

История помнит случай с одним из государств бывшего СССР, в котором решили: весь интернет — только с государственным сертификатом через серверы государства, чтобы могли расшифровать и посмотреть, что там внутри. Браузеры, недолго думая, добавили этот сертификат в черный список, страна осталась без интернета и эксперимент досрочно прекратился.

У меня в налоговой есть сертификат, которым я подписываю декларации; но я не генерировал никаких ключей, не создавал CSR и не подписывал сертификат. Почему?

За вас это все сделали самостоятельно на сервере налоговой. У них хранятся ваши ключи и они сами подписывают вашим закрытым ключом ваши документы. В момент подписания спрашивают пароль от закрытого ключа, который вы указывали при создании сертификата.

Я — юридическое лицо, и у меня тоже есть сертификат для налоговой. К нему в комплекте идет программный комплекс КриптоПРО и флешка. К чему такие сложности?

Сначала сертификаты появились в Америках. У них свои стандарты FIPS для описания криптографии и есть открытая (в плане исходного кода) реализация OpenSSL.

Потом сертификаты пришли к нам. У нас свои стандарты ГОСТ для описания криптографии и популярность приобрела закрытая реализация в КриптоПРО.

Флешка же — не совсем флешка. Там есть небольшая операционная система, генерируется ключевая пара и выполняется подписание документа.

• Генерация ключевой пары: КриптоПРО просит водить мышкой по экрану — создает набор случайных данных; их отправляет на «флешку», а та генерирует ключевую пару. Закрытый ключ сохраняет себе и никому никогда не выдает, открытый возвращает КриптоПРО. КриптоПРО создает сертификат, отправляет его на подпись в удостоверяющий центр, тот подписывает, после чего сертификат записывается на «флешку». Для сохранности.

• Подписание документа: КриптоПРО считает хеш документа, отправляет его на «флешку», та шифрует хеш закрытым ключом и возвращает результат. КриптоПРО добавляет этот зашифрованный хеш (иными словами — подпись) к документу. Для проверки подписи нужен только открытый ключ, который во всех сертификатах лежит в открытом виде, поэтому «флешка» для проверки подписи не требуется.

Это эталонная реализация, как должно быть. Сам я внутрь не заглядывал.

А для IP-адреса сертификат можно?

Можно. Но не все удостоверяющие центры готовы подписывать такие сертификаты. И не всем подряд.

А может домен выглядеть как IP-адрес?

Технически — да. В лабораторной среде можно сделать домен 8.8.8.8, который возвращает IP-адрес 1.1.1.1. Но в большом интернете такой домен создать не получится (максимум – что-то типа 8.8.8.com).

Я установил себе на телефон приложение для VPN. Что может пойти не так?

Если это приложение установит в телефон свой корневой сертификат — см. главу 3.

Что в итоге сделал тот хакер из столовой?

О нем писали. Погуглите по ключевым словам «хакер столовая».