Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
Сайты под “чистыми” IP-адресами
В продолжение предыдущей записки: можно ли вообще обойтись без доменного имени для веб-сайта? Можно, но это доставит некоторых дополнительных проблем, да и “игра” получается с другими правилами. В принципе, сейчас уже можно автоматом заказывать и выпускать TLS-сертификаты для IP-адресов от хорошо известного (доверенного в “коробочных” браузерах) УЦ – это сертификаты от Let’s Encrypt, на шесть дней валидности.
Наличие TLS-сертификата и выделенного IP-адреса позволяет поднять веб-сервер с доверенным TLS прямо по IP-адресу, без использования доменного имени. Вот, посмотрите, я сделал для примера – должно работать в любом распространённом веб-браузере:
Этот URL – использует https, но указан просто IPv4-адрес, а не имя хоста/доменное имя. Сертификат я за несколько секунд выпустил при помощи утилиты certbot и профиля shortlived, всё при nginx в качестве веб-сервера, вот так:
certbot certonly \ --preferred-profile shortlived \ --ip-address 185.39.19.199 \ --webroot --webroot-path /var/www/html/
Да, конечно, нужен выделенный IP-адрес. На одном адресе, в такой схеме, может отвечать только один веб-ресурс (ну, если не использовать хитростей, напоминающих ECH). IP-адрес принадлежит тому или иному оператору, и оператор может его забрать, поменять, перенаправить трафик. Всё то же самое верно и при использовании доменного имени: с той лишь разницей, что, в случае доменного имени, поменять/забрать/перенаправить – касется и домена, и IP-адреса (адресов). Но при прямом использовании IP-адресации не нужна поддержка DNS для соединения с конкретным сайтом из браузера (тут речь именно про конкретный процесс из области веба, так-то, без DNS, не работает и IP тоже).
В принципе, не являясь оператором связи, блок IP-адресов можно приобрести в собственное управление, а потом разрешить анонсировать в Интернет тому или иному оператору, заведя нужные адреса на свой сервер, но вот только это сильно другая история, чем регистрация обычного доменного имени второго уровня; другая история – и технически, и административно, и финансово.
Понятно, что главная-то проблема с таким использованием IP-адресов – это то, что пользователю сложно запомнить обычный адрес. А адресов вида 1.1.1.1 или 8.8.8.8 – очень мало по определению. Кроме того, наверняка будут проблемы с ПО для веба, которое ПО может быть заточено под имена хостов. (Точно будут проблемы с почтовым ПО, но это не веб.)
И всё же, хотя бы возможность простого выпуска TLS-сертификатов для IP-адресов может тут оказаться полезной.
(Но я пока что не планирую переводить dxdt.blog на “чистую” IP-адресацию. Хотя, кто знает.)
Адрес записки: https://dxdt.blog/2026/04/22/18012/
Похожие записки:
- Домены и адреса
- Техническое: локальный корневой сертификат с кросс-подписью и nameConstraints
- Квантовые компьютеры, АНБ и битовые строки
- Серверы Gmail и 3DES
- Заметки за июнь 2024 года
- Реплика: ещё раз про "ключи на клиенте" и DH
- Многобайтовые постквантовые ключи и TLS
- Странные особенности Golang: комментарии и ассемблер
- Реплика: атака посредника в TLS и проблема доверия сертификатам
- Новые уровни для Quake
- SSL.com и TLS-сертификаты для непроверенных имён
Новый
Написать комментарий