Comments 29
решает задачи TLS-шифрования для сервисов, где домен отсутствует (например, IoT-устройства, серверы внутри сети или тестовые стенды).
Лол, ага. На тестовые стенды внутри сети. Ещё допишите – в оффлайне.
На локалхост!
Ну так-то да, и внутри сеть по https куда удобнее ходить.
Хотя бы потому, что браузеры нынче http не очень уважают.
Да и не везде http даже внутри сети по политикам компаний разрешен.
Удобнее. Вы как проверку внутреннего IP сервером LetsEncrypt осуществлять собираетесь?
Чтобы вам выдали сертификат, lets encrypt должен убедиться, что вы владеете ресурсом, на который сертификат выдается, для этого делает запрос на этот ресурс и ожидает определенный ответ от него. Если в качестве ресурса вы предоставите ip адрес вашей внутренней сети, куда уйдет проверяющий запрос lets encrypt?
при использовании ipv6 запрос может спокойно уйти на конечное устройство.
Тут конечно вопрос к переводу/LE что считать "внутренней сетью" - то что закрыто NATом? То что закрыто файволлом? пулл-адресов выданных конечному пользователю?
Непубличные диапазоны адресов, неадминистрируемые?
неадминистрируемые
с ipv6 все становится сильно сложнее и проще. Вот SLAAC выдаст всем устройствам вашего дома по публичному ipv6-адресу - все, можете подключаться к своему водонагревателю с любой точки мира. Звучит не очень секьюрно, надо сходить и настроить файрволл. Это как, считать администрируемым или нет?
Непубличные диапазоны адресов
Это сильно противоречит логике ipv6 - смысл в том чтобы отказаться от NATa. Да, есть Unique-Local и Link-Logical, но основная идея чтобы каждое устройство имело публичный IPv6 адрес из назначенной вам(выданной провайдером) сети.
Ну странно, да, что кто-то решил, что речь о частных адресах)
Плевое дело, надо всего-то реверс прокси развернуть на внешний ip
Может подразумевалось, что внутри одной автономной системы (AS), у которой реальные адреса, но как бы это с точки зрения хозяина AS всё же внутренняя сеть? 🤔
Let’s Encrypt не делает короткоживущие сертификаты стандартом по умолчанию
Пока что.
Short-lived certificates are opt-in and we have no plan to make them the default at this time.
В общем, тенденция такая себе, особенно для тех, кто не хочет идти "в ногу со временем", интегрироваться в парадигму "все зависят от всех". Ранее, в обсуждениях SSL я задавался вопросом, почему бы не сделать выдачу сертификата синхронно с покупкой-продлением доменного имени. Плюс, связать систему центров сертификации с регистраторами (а корневым для домена будет заправлять его организатор, для национальных доменов - администратор такого домена).
А тут вон оно как, пройдет несколько лет и каждую неделю менять придется... К счастью, браузеры пока все еще допускают работу без SSL или с просроченным.
Но я не удивлен, что в итоге все устроено именно так. Сертификаты - это не только благо повышения безопасности, но и одна из возможностей контроля и оказания давления при необходимости (а уменьшение сроков выдачи усиливает не только безопасность, но и такой контроль). Пример этого применения: "03.2022 У попавших под санкции банков и Центробанка отозвали SSL-сертификаты". Стоит помнить, что на данный момент все признаваемые корневые сертификаты (и соответственно по умолчанию функционирующие в браузерах) выпускаются только западными компаниями.
Это я к чему: мир все больше деглобализируется, и в реальности и онлайн. И что станет с ИТ системами, всё плотнее завязываемыми на принципы взаимозависимости..? По крайней мере, в том же DNS есть механизмы компенсации нарушения связности. Но все равно, это не здорово, когда обслуживание посещения пользователем некого местного сайта зависит от все большего числа посредников (с потенциальным рубильником в руках у каждого). Вопрос не только в SSL, это относится и к случаям, когда на веб-проектах из соображений удобства включают чужое содержимое, различные библиотеки функций, стили и графику с глобальных cdn. Даже на хабре, первое что вижу в исходнике страницы "...src: url(httрs://fonts.gstatic.com/s...", "...script async src="httрs://www.googletagmanager.com/gtag/js...". А ведь правильнее было бы кешировать таковое у себя (вон, ссылки на пользовательские картинки хабр давно так обрабатывает).
Вот когда-то рубанут связность, с той или этой стороны, не важно по каким причинам, и...
src: url(httрs://fonts.gstatic.com/s это вообще треш. Раньше, изначально, это обьяснялось так: скорость связи с крупными CDN выше, плюс в браузерах было ограничение на 5 запросов на 1 домен (некоторые еще размещали статику на субдоменах по этой причине), поэтому такой фокус со сторонними CDN ускорял первоначальную загрузку сайта. Но это давно в прошлом, сейчас уже не 2000-е годы, зачем сейчас так делать...
О да, ох уж эти внешние ресурсы. Случайно оставил в работе так ссылку на этапе разработке, потом соображал откуда вдруг тормоза...
почему бы не сделать выдачу сертификата синхронно с покупкой-продлением доменного имени
но вы ведь не предлагаете покупать сертификаты на сабдомены?
А что мешает выдать по-настоящему wildcard сертификаты? По сути только жадность.
Распространенная практика получать сертификаты на каждый поддомен отдельно тоже не очень хороша. Зря что-ли были придуманы wildcard-сертификаты?
Я понимаю, что ничего не изменится в существующей системе. Но повсеместное SSL внедрилось бы гораздо раньше и красивее, если бы этот wildcard сертификат предоставлялся автоматически, без отрыва от процедуры регистрации/продления, в комплекте с каждым доменом. А также существовал стандартный (всеобще принятый) механизм/протокол обновления такого сертификата взаимодействием с администратором зоны.
Впрочем, что удивляться, с организационными вопросами и процессом внедрения того же ipv6 умудрились напортачить еще больше.
Вы предлагаете каждого хостера наделить ещё и полномочиями УЦ?
Во-первых, это серьёзно повысит порог входа в бизнес для хостеров (к УЦ предъявляются серьёзные требования), во-вторых, ещё только и не хватало, чтобы всякие мусорные хостеры могли сертификаты штамповать, у нас и так полно УЦ, доверие к которым не столь сильно, как хотелось бы, давайте ещё и каждому хостеру делегируем право выписать сертификат, что же может пойти не так.
Не хостера, а каждого регистратора доменов наделить полномочиями промежуточного центра сертификации. Или статус регистратора домена недостаточно доверителен?
Регистратор доменов ведь технически имеет доступ к ns записям домена любого своего пользователя. Неужели это менее важно, чем SSL?
И да, я соглашусь, что доверие к некоторым регистраторам доменов не столь высоко и такого не должно быть. Они должны проходить столь же строгие процедуры, как УЦ.
А организатор (администратор) доменов национальной зоны обязан соответствовать уровню организации ИБ, как у корневого УЦ.
По факту сейчас мы имеем две похожие, но изолированные цепочки - по управлению доменом и по его сертификации. И они обе одинаково важны с точки зрения безопасности (домен даже чуть важнее будет, ибо первичен). Их раздельность только понижает общую безопасность. Что толку с наличия SSL, если бывает угоняют сами домены?
Хостер может управлять доменом, так что уже может выписать сертификат на него.
Хрен с ним, можно хотя бы предоставить хостерам АПИ к УЦ.
Ранее, в обсуждениях SSL я задавался вопросом, почему бы не сделать выдачу сертификата синхронно с покупкой-продлением доменного имени.
Теоретически, у нас есть DANE, построенный на DNS. Но, увы, в браузерах он не взлетел. Это могла бы быть хорошая, децентрализованная альтернатива CA.
Большая часть децентрализованных проектов не взлетает, увы. Всем нужна иерархия, рычаги влияния/власть в конечном итоге. С теми же браузерами у нас осталась лишь фикция независимости - Google Chrome, владелец которого никогда не одобрит такое и формально свободный Firefox, основным спонсором которого является... Google (и делает он этот щедрый жест в основном, чтобы не залететь под законы США о монополизме или чекать отзывы на обкатку сомнительных фич). Конечно, команда разрабов Firefox типа независима и честна (хотя там было мутновато с космическими суммами выплат гендиру), но спонсор есть спонсор. Я просто уверен, что в ключевых вопросах Google недвусмысленно намекает, что бы он видеть в FF не хотел.
Ещё один рычаг давления. Это точно.
Эх порылся в документации, но так и не нашел примера команды на получение этого 6 дневного сертификата... :-(
Let’s Encrypt: Стали общедоступны короткоживущие сертификаты и поддержка IP-адресов вместо доменов