ACME внутри интранета
Apr. 30th, 2025 09:57 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerТут некоторое время назад jno писал мне в комментариях что локальный CA внутри закрытой от внешнего мира локальной сети должен бы обновлять сертификаты по протколоу ACME.
Тогда я с этим не соглалсился.
Потому что считаю надежное хранение пассфразы от приватного ключа CA (что предполагает невозможность автоматизированного выпуска сертификатов без участия человека) куда более полезным для безопасности сети в целом, чем сокращение срока жизни сертификатов.
А вот сегодня читаю очередной выпуск Feisty Duck и там пишут что Apple Google и прочие киты индустрии строят коварные планы сократить максимальный срок жизни сертификата до полутора месяцев. Если так дело пойдет и браузеры просто не будут признавать сертификаты, выпущенные более полутора месяцев назад, то действительно админам интранетов придется так или иначе автоматизировать выпуск сертификатов для локальных сайтов. Что, безусловно, снизит в общем случае безопасность локальных сетей.
Хотя, конечно можно будет сделать выпуск сертификтаов для всех сайтов локальной сети ручной операцией, выполняемой раз в полтора месяца с автоматическим распихиванием новых ключей и сертификатов по сайтам с помощью какого-нибудь инструмента удаленного администрирования. (на самом деле просто ssh с scp достаточно).
Тогда можно будет хранить пассфразу (а то и сам приватный ключ) локального CA безопасно.
Впрочем там еще crl-и по расписанию выпускать надо. И на том же мастер-ключе подписывать.
no subject
Date: 2025-04-30 07:58 pm (UTC)Лучше не раз в полтора месяца, а раз в три-четыре недели, чтобы оставить запас на непредвиденные случаи всё-таки.
Что касается CRL - те же Let's Encrypt в своих недавних постах про короткоживущие сертификаты утверждают, что ревокация в реальных условиях работает плохо и отозванные сертификаты по факту могут работать до окончания срока действия. Собственно, насколько я понимаю, по умолчанию ни Firefox, ни Chrome не проверяют CRL-и уже достаточно давно. Собственно, переход на короткоживущие сертификаты в значительной мере мотивирован как раз тем, что средства отзыва ненадёжны и по факту короткий срок действия сертификатов (в новой итерации 6 дней) будет работать в качестве защиты лучше.
Что касается вопроса того, повышает ли безопасность интранета использование внутреннего ACME-сервера... вопрос интересный. С одной стороны, приватный ключ CA - это определённо более серьёзная добыча, чем приватный ключ случайного сервера. С другой стороны, у него и защита должна быть лучше - если противник может получить доступ к одному из самых защищённых узлов сети, следует ли считать другие узлы сети находящимися в безопасности?
И да, в теории что мешает скомпенсировать дополнительные угрозы корню CA за счёт использования промежуточного сертификата? В порядке доведения до абсурда можно свести модель к существующей, выпустив по долгоживущему промежуточному сертификату на каждый сервер (со сферой применения, ограниченной его доменным именем), храня его приватный ключ на этом самом сервере и выпуская новые сертификаты локальным крон-джобом, не выходя за пределы сервера, хоть каждый час.
no subject
Date: 2025-04-30 09:59 pm (UTC)С другой стороны, зачем вообще как-то по особому защищать CA? Если злоумышленник может получить доступ к хранилищам корневых сертификатов на конечном устройстве, то никакого доступа к CA ему не понадобится.
Если он получит доступ к секретным ключам (или даже просто возможность конфигурации, с возможностью указания своего серта и ключа) серверного ПО, а в клиентском будет те сотни корневых CA, которые там лежат изначально, то опять же толку в такой защите мало.
no subject
Date: 2025-05-01 06:45 am (UTC)Не обязательно хост. Главное, чтобы носитель информации с приватным ключом CA лежал в сейфе. Желательно чтобы это был крипографический токен, извлечь ключ с которого невозможно, а можно только выдавать туда запросы на подпись.
Именно этим-то и плох протокол ACME, который подразумевает инициирвование запроса на сертификат со стороны клиента (будущего владельца сертификата) и реалтаймовый ответ на этот запрос. Не предусмотрено там места для человека, который открывает сейф и достает носитель.
С другой стороны, HSM(токен) постоянно подключенный к сереверу CA несколько безопаснее, чем ключик, лежащий в в файлике на том же сервере. Ключик можно унести зайдя на сервер удаленно. Токен можно унести только физически (и он при этом исчезнет со штатного места, что будет заметно). Поэтому в случае взлома сервера CA можно подписать несколько заявок, пока подозрительную активность не засекли, но не более того.
На конечном устройстве злоумышленник получает доступ только к конечному устройству. То есть как макнсимум к аутентификационной информации, которая позволяет получить доступ к корпоративным серверам от имени владельца этого устройства. Устроив поддельный сервер, который перенаправляет запросы на настоящий, злоумышленник в течение короткого времени может собрать пароли всех сотрудников конторы.
Собственно, HTTPS в корпоративной сети служит только двум целям
Если бы эти самые производители бразуеров нормально поддерижвали digest authentication, (или существовали попуярные frontend-библиотеки для digest или scram authentication, которые можно было бы прикрутить ко всем корпоративным веб-сервисам, то https была бы исключительно театром безопасности.
Правда, в корпоративной сети обычно есть и другие сервисы, кроме web. И вот там могут вполне использоваться клиентские сертификаты от безопасности которых действительно что-то зависит. В Postgres Pro в свое время не сумели наладить нормальную работу с клиентскими сертифкатами openvpn и перешли с аутентификации по спертификатам на аутентификацию по OTP.
no subject
Date: 2025-05-01 09:03 am (UTC)Следует отметить, что в протоколе ACME не написано про реалтаймовый ответ - про фазу между получением CSR и выдачей сертификата там написано "The certificate is being issued. Send a POST-as-GET request after the time given in the Retry-After header field of the response, if any." То есть в теории я не вижу причины, по которой сервер не мог бы проверять запросы клиентов и собирать их CSR-ы до того момента, когда приходит человек и использует токен. Другое дело, что многие клиенты могут быть не готовы к задержкам в пару недель (привет, новогодние праздники).
no subject
Date: 2025-05-01 09:52 am (UTC)Какие, нафиг "клиенты, которые не готовы"? Мы тут рассуждаем про CA для локальных сетей. У которых и сервер получающий сертификат, и CA, выдающий сертификат, находятся под общим административным контролем.
У корпоративных сисадминов в праздники и выходные, как я погляжую - самая работа. Поскольку не работают все остальные сотрудники, и можно спокойно останавливать внутренние, не торчащие во внешний мир, сервера для апгрейда или еще какого обслуживания.
И усовершенствовать скрипт для acme, чтобы он знал про существование разнообразных праздников, и начинал слать запросы когда до окончания срока дейсвтия сертификата оставалось требуемое количество РАБОЧИХ дней вполне можно. (у меня сейчас начинает слать за 7 календарных).
no subject
Date: 2025-05-01 10:11 am (UTC)"находятся под общим административным контролем" не эквивалентно "написаны местным сисадмином". Подозреваю, что в наши дни вполне может оказаться, что клиент ACME сидит где-то в дереве контейнеров, отвечающих за нужное ПО, и его замена на другой - операция нетривиальная и требующая повторения при обновлении ПО.
no subject
Date: 2025-05-03 05:46 am (UTC)У тех же Synology в их DSM штатный клиент Let's Encrypt(именно Let's Encrypt с жесткой завязкой, свой CA нельзя выбрать) то есть но он кривой и не умеет в DNS-проверки. Нужно внешний костыль использовать, у которого свои проблемы. При этом там не контейнеры даже.
Один из вариантов хоть как то нормально решить проблему - свой CA + внешний доступ через Cloudflare(!)(Cloudflare можно сказать что у origin server - будет сертификат от вот этого конкретного CA, он будет перешифровать трафик). Другое дело что Cloudflare...отдельный набор проблем
no subject
Date: 2025-05-03 05:59 am (UTC)НУ Synology это вообще не для средних умов. Мне в позапрошлом году пришлось потратить неделю на пересоздание заново кучи всего, потому что наши админы не сумели восстаовить бэкап, аккуратно сделанный на эту самую Synology. Причем именно "Не сумели". Потом выяснилось что если бы все делали как положено, а не как они поняли, все бы восстановилось.
А тут мы рассматриваем вопрос как жить, если светить внутреннюю структуру локальной сети заграничным фирмам нельзя. Ни lets encrypt-у, ни CloudFlare. Никто за пределами нашей сети не должен вообще знать что внутри у нас есть хосты с такими, таким и такими именами.
(правда, это пожалуй будет несовместимо с BYOD, потому что там внезапно окажется если не DNS over HTTPS, то прописанный где-то в локальный резолвер 8.8.8.8)
no subject
Date: 2025-05-01 09:45 am (UTC)И да, большинство современных усилий по защите направлено на защиту в т.ч. от инсайдера (злоумышленника или жертву злоумышленника).
И тут, КМК, нужно не останавливаться и стремиться организовать такую среду, где даже root не может получить доступ к конфиденциальным данным. В systemd-creds пошли по половинчатому пути и защищают только хранение, а в расшифрованном виде данные просто лежат в ram-диске. Тогда как правильнее было бы передавать данные через stdin.
no subject
Date: 2025-05-01 10:04 am (UTC)Так потому и не распространены защищенные пароли, поскольку все хотят данные тоже защищать. А если защищен весь канал, зачем напрягаться с дополнительной защитой паролей?
Идея что чем меньше данных мы защищаем, тем легче их защитить, в голову не приходит.
Хотя, конечно существует и проитивоположная идея - что лист надо прятать в лесу, и среди большого объема зашифрованного траффика который в общем-то содержит контент, доступный и так, легитимным образом, легко замаскировать по-настоящему ценные данные.
Системы мандатного доступа, в которых рут практически никто. и не имеет доступа к данным - весьма распространены. Но какой же гемморой их правильно администировать!
Самое главное что в большинсве случаев это не нужно. Не так уж много у типичной коммерческой фирмы конфиденциальных данноых с одной стороны, С другой стороны, если у юзера, имеющего право доступа к данным, что-то не работает, и придет админ фиксить его проблему, то юзер ему сам все расскажет и покажет.
Скрывать от админа данные это все равно что скрывать существенно важную информацию от врача или юриста.
Другое дело, что врачей и юристов специально учать работать с конфиденциальной информацией пациентов и клиентов, у них есть определенные профессиональные традиции и даже защита от необходимости делиться этой информацией на уровне законодательства. А у сисадминов это всё пока не отросло. Но отрастить придется.
no subject
Date: 2025-05-01 11:48 am (UTC)Но при этом совершенно необязательно любому врачу рассказывать о состоянии своего счёта, а любому юристу (банку и т.п.) - о состоянии своего здоровья.
Моё мнение таково, что root в production системе может читать и менять любой файл в файловой системе (во всяком случае, в системной - не пользовательской - области) - ему это нужно для прямых обязанностей - системного администрирования. Но ему совершенно необязательно иметь возможность посмотреть любой байт в оперативке или получить иным способом прямой доступ к секретам, уже обрабатывающимся в системе.
Если хочет поменять, например, серверный ключ sshd - пусть меняет контейнер этого секрета (а тот уже может быть защищен чем-то ещё, кроме одиночного пароля админа).
А какие системы мандатного доступа могут такое реализовать со стандартными инструментами (с тем же systemd)? LLM пишет, что можно скрестить инструменты типа systemd-creds с selinux или apparmor. Но для каждого защищаемого сервиса придётся отдельно "приседать".
no subject
Date: 2025-05-01 10:06 am (UTC)no subject
Date: 2025-05-01 06:29 am (UTC)Ну если с CRL дела обстоят так, как обстоят, то жизнь упрощается. Не надо регулярно генерировать CRL-и. Вообще CRL-и в мпервую очередь интересны не для серверных, а для клиентских сертификатов. Вероятность компрометации клиентских сертификатов в эпоху BYOD (например путеи утери девайса) куда выше, чем вероятность копмпрометации серверного сертифпката.
Опять же легче гарантировать что на сервере будет актуальный crl, чем что он будет у всех клиентов.
Компенчировать дополнителные угрозы путем усложнения ситемыы это вообще плохая идея. Безопасность - это цепь. Чем больше в ней звеньев, тем больше шансов что одно из них оборвется.
В данном случае введение такой сущности как промеждуточные сертификаты, выдвигает дополнительные требования к кавлификации админов локальной сети. Они должны понимать чем чревата компрометация каждого из используемых типов сертификатов, и какие регламентные меры нужно принмиать в каких случаях. Их и для простого случая-то этому обучить непросто.
no subject
Date: 2025-05-01 09:52 am (UTC)no subject
Date: 2025-05-02 07:41 pm (UTC)За постинг ссылок без комментария как минимум на несколько строк что это такое, и почпему я должен на него посмотреть, в моем журнале полагается бан.
За постинг оффтопичных ссылок тоже.