Мне здесь не нравится только pathLen=4 в критической секции - оно означает, что ниже по PKI должны быть два уровня subCA. Это даёт довольно широкие возможности по созданию динамических subCA и их инвалидации без влияния на остальную PKI, и ограничивает выпуск сертификатов не-subCA для первого уровня подчинения этих subCA. Но по делу - сертификаты как таковые ничем не отличаются от "обычных" корневых центров сертификации.
Токарному станку не очень важно время на раскрутку, а в блендерах требуют чтобы "вжжик и готово", поэтому мощность там задирают. Рабочая нагрузка у токарного станка - резец (один) шириной 1-2 см (дерево же) и глубиной десятки три (вроде до трёх мм можно), где-то на столько мощности и рассчитан - тут нужны полноценные расчёты, а не наколенные, с сопроматом и ТММ. У блендера же ножик во-первых центрального монтирования, а не радиального, во-вторых напрочь отсутствует маховик, в-третьих ножик в среднем двухлопастной и длиной до 40 мм, плюс не режет стружкой, а рубит пополам. На такую рубку больше энергии требуется, вот и нужна мощность.
"при условии впахивания как папа карло" - там столько предлагают за две полных ставки, то есть даже не 996, а прямо-таки 997. Как говорится, и нафига тогда такая зарплата, если тратить тупо некогда? Ну и "при условии выплаты премий" - отдельная мулька, в расчеты входит, а выплачивается никогда.
Странно, что не упоминается хотя бы Purple Screen of Death - с таким падает ESXi. А то "каких ещё цветов бывают экраны смерти", а этого-то как раз и нет в статье.
Тогда получатель не сможет расшифровать сообщение, так как его зашифровали не его собственным публичным ключом. Или там описан полноценный MitM, который держит две пары ключей для перешифрования сообщений? От такого защиту при ровно двух участниках криптообмена и нуле доверенных каналов в самом деле не построить... а я ещё и взъелся на автора.
Думаю, "подмес" ржавчины со стенок этой трубы вполне реален. Но да, дыры в самих трубах особо влиять не должны, разве что с обратной стороны какая-то структура, которая давление держит, но при этом размывается водой, тогда её элементы в трубу попадают.
У них была ещё система Jaz - 2GB на диск, вроде как несовместимая с Zip. У меня были 100МБ диски, но это было уже после того, как на день варенья мне подарили флэшку на 256МБ, которая кстати жива до сих пор (просто на неё класть стало нечего, всё настолько потолстело, что ужас), и мы поигрались и забили.
Например, отправка конфига с вшитым приватным ключом по электронной почте. В самих алгоритмах TLS естественно приватные ключи не передаются. Если используется "взрослый" ЦС, там есть и возможность сгенерировать серт по шаблону, и возможность подать CSR, сгенерировав ключевую пару на клиенте, а в обычной работе с easyrsa все действия с ключевой информацией выполняются на сервере ЦС и приватный ключ как-то надо выдать клиенту, кому делается сертификат.
Ну они же написали small setups. Две-три сотни это уже large setup, и там надо регулярно что-то делать с доступом - кого-то блокировать, кому-то новый делать, и для него такой подход становится непрактичным.
Поддерживать список фингерпринтов - маета, и кажется, без рестарта сервера не подправить. Куда проще crl-verify по выпуску заданным ЦС. Правда, при работе по фингерпринтам клиент себе сам сможет создать серт, то есть приватные ключи не передаются по сети, что есть плюс. Но доверие фингерпринту меньше, чем сертификату, SHA collision теоретически может быть (хотя не слышал про коллизию на SHA256 или выше).
Loved похоже наследник серии SHIFT, рекомендую её побольше. За 15 минут пройти каждую вроде бы можно, там было или 3 или 4 игры в серии, давность 2009-2013, платформа Flash.
1 - получается, переизобрели easyrsa, но на другой кодовой базе. 2 - интересная идея, при работе со стандартным ЦС такой опции не предусмотрено. 3 - а на сколько, и почему? 4 - вот это поддерживать надо, и зависит от конфига. Не пойму пока что, что туда кидать, за исключением одного клиента, у которого за openvpn-клиентом подсеть, куда нужен доступ из сети за сервером - у меня там конфиг с iroute. 5 - классно) 6 - тоже хорошо. Однако easyrsa можно докрутить до того, что его ЦС будет работать именно с эллиптической криптографией (set_var EASYRSA_ALGO ec; set_var EASYRSA_CURVE secp384r1)
Управление CA - хотя и неприятно, но можно сделать на вменяемом уровне. То же создание CRL и подсовывание его серверу вполне себе автоматизируется на уровне крона. Обновление сертификатов - удобство vs безопасность, либо у тебя потерянные SSH-ключи на wg, либо забытые сертификаты на easyrsa, что технически одно и то же. Но если серт рано или поздно истечёт, то ключ - нет.
Userspace vs kernel space - грабли валидные, может наткнёмся со временем, но оверхэд там для нас не критичен настолько, чтобы решало. (Вот будь у нас 40Гбит/с снаружи, могло бы влиять по идее)
Спорные грабли. Да, wireguard меньше в виде кода, но статические (и динамические) анализаторы решают проблему аудита в поисках багов довольно эффективно. Ну и никто не застрахован от бага в либах, который можно проэксплойтить даже через идеальный код использующего приложения.
Насколько у вас сложные правила для OpenVPN, что вам надо поддерживать кастомные скрипты OpenVPN на стороне клиентов? А также, насколько часто у вас меняется конфигурация локальной сети "за" сервером OpenVPN, что надо лазать в конфиг и править там push route или ещё какие-то параметры? Один раз заточил, и оно "просто" работает. Про частые проблемы:
"Не могу зайти в VPN" - ну, штатная ситуация, можно лечить скриптами автоматического перевыпуска сертификатов, условно раз в месяц, и превентивно рассылать новые конфиги. По сравнению со статическими SSH-ключами Wireguard - удобство vs безопасность, плюс защита от забывчивости в случае увольнения кого-то, если сразу не сделали отзыв. По мне, так или иначе доступ к VPN админить надо, ваше решение не хуже многих.
OpenVPN прекрасно умеет работать по UDP - что мешает/мешало перенастроить сервер (поднять второй инстанс, начать перевозить клиентов по инструкции, ещё как) на использование UDP в качестве транспортного протокола? Проблема разрыва соединений и переподключения в мобильном роуминге решается параметром auth-gen-token (время в секундах) в конфиге сервера или CCD клиента, если нельзя на весь сервер включить.
А что это у вас кто попало лазает в easyrsa кривыми руками? Он, кстати, по логике должен жить отдельно от OpenVPN, в идеале на нормально выключенной ВМ, и бэкапаться регулярно, как центр доверия системы VPN. И при нормальной безопасности разрешение на вход по VPN должно выдаваться администраторами, кривых рук там быть не должно (как есть - смотрите сами, кто там вам ломал ЦС, какими действиями, почему и зачем, и насколько сильно его за это бить - тоже). Про альтернативы:
Какая такая проблема сложности PKI? Сложно создать CRL и добросить его до сервера? Сложно мониторить истечение сертификатов? (openssl x509 -enddate) Сложно держать его несломанным? Грубо говоря, семь бед - один backup.
"Голый" IPsec?! Он хорош для перманентных подключений через белые IP, и неизменяемых настройках пробрасываемых сетей. Применять его для подключения бегающих клиентов как минимум нелогично. L2TP/IPsec - вариант, но наши "доблестные" РКП его режут нещадно. Да, не вариант, но то, что он вообще тут появился, не подходит под описываемый сценарий использования VPN. 3, 4 - да, инфраструктура VPN должна быть "своей" вместе с центром доверия - но задачи управления им с вас не снимаются.
Проблемы настройки WG vs OpenVPN:
Firewall - смешно. Вы же проверяете подключение до того, как выставить сервер в прод, да? (ДА?!)
IPv4 forwarding - вообще аксиома, VPN-сервер, любой, является роутером и форвардить IPv4 обязан. (IPv6 не забудьте, кстати, если настраивали, он отдельно включается)
Ну, keepalive есть и в OpenVPN, но да, нужен.
Добавление - ну ОК, а удаление?
Итого: Можно было обойтись перенастройкой OpenVPN с тем же эффектом (ну, минус оверхэд, от него не уйти).
"не только ели, но и пили" (ц)
Мне здесь не нравится только pathLen=4 в критической секции - оно означает, что ниже по PKI должны быть два уровня subCA. Это даёт довольно широкие возможности по созданию динамических subCA и их инвалидации без влияния на остальную PKI, и ограничивает выпуск сертификатов не-subCA для первого уровня подчинения этих subCA. Но по делу - сертификаты как таковые ничем не отличаются от "обычных" корневых центров сертификации.
"Цитируем мятежника Цурэна?" (с)
В дистиллированной воде и при отсутствии возмущений - ну ОК. А в реальности звуковым каналом быстрее будет.
Токарному станку не очень важно время на раскрутку, а в блендерах требуют чтобы "вжжик и готово", поэтому мощность там задирают. Рабочая нагрузка у токарного станка - резец (один) шириной 1-2 см (дерево же) и глубиной десятки три (вроде до трёх мм можно), где-то на столько мощности и рассчитан - тут нужны полноценные расчёты, а не наколенные, с сопроматом и ТММ. У блендера же ножик во-первых центрального монтирования, а не радиального, во-вторых напрочь отсутствует маховик, в-третьих ножик в среднем двухлопастной и длиной до 40 мм, плюс не режет стружкой, а рубит пополам. На такую рубку больше энергии требуется, вот и нужна мощность.
"при условии впахивания как папа карло" - там столько предлагают за две полных ставки, то есть даже не 996, а прямо-таки 997. Как говорится, и нафига тогда такая зарплата, если тратить тупо некогда? Ну и "при условии выплаты премий" - отдельная мулька, в расчеты входит, а выплачивается никогда.
ADinf смотрит на вас с одобрением :)
Странно, что не упоминается хотя бы Purple Screen of Death - с таким падает ESXi. А то "каких ещё цветов бывают экраны смерти", а этого-то как раз и нет в статье.
Тогда получатель не сможет расшифровать сообщение, так как его зашифровали не его собственным публичным ключом. Или там описан полноценный MitM, который держит две пары ключей для перешифрования сообщений? От такого защиту при ровно двух участниках криптообмена и нуле доверенных каналов в самом деле не построить... а я ещё и взъелся на автора.
А из-за чего вообще взялись rust coreutils? Мейнтейнеры разучились писать на Си?
Думаю, "подмес" ржавчины со стенок этой трубы вполне реален. Но да, дыры в самих трубах особо влиять не должны, разве что с обратной стороны какая-то структура, которая давление держит, но при этом размывается водой, тогда её элементы в трубу попадают.
У них была ещё система Jaz - 2GB на диск, вроде как несовместимая с Zip.
У меня были 100МБ диски, но это было уже после того, как на день варенья мне подарили флэшку на 256МБ, которая кстати жива до сих пор (просто на неё класть стало нечего, всё настолько потолстело, что ужас), и мы поигрались и забили.
Например, отправка конфига с вшитым приватным ключом по электронной почте. В самих алгоритмах TLS естественно приватные ключи не передаются.
Если используется "взрослый" ЦС, там есть и возможность сгенерировать серт по шаблону, и возможность подать CSR, сгенерировав ключевую пару на клиенте, а в обычной работе с easyrsa все действия с ключевой информацией выполняются на сервере ЦС и приватный ключ как-то надо выдать клиенту, кому делается сертификат.
Ну они же написали small setups. Две-три сотни это уже large setup, и там надо регулярно что-то делать с доступом - кого-то блокировать, кому-то новый делать, и для него такой подход становится непрактичным.
Поддерживать список фингерпринтов - маета, и кажется, без рестарта сервера не подправить. Куда проще crl-verify по выпуску заданным ЦС. Правда, при работе по фингерпринтам клиент себе сам сможет создать серт, то есть приватные ключи не передаются по сети, что есть плюс. Но доверие фингерпринту меньше, чем сертификату, SHA collision теоретически может быть (хотя не слышал про коллизию на SHA256 или выше).
Loved похоже наследник серии SHIFT, рекомендую её побольше. За 15 минут пройти каждую вроде бы можно, там было или 3 или 4 игры в серии, давность 2009-2013, платформа Flash.
Интересно, как боксёр ухитрялся вовремя реагировать, если мозги у него были не в голове.
1 - получается, переизобрели easyrsa, но на другой кодовой базе.
2 - интересная идея, при работе со стандартным ЦС такой опции не предусмотрено.
3 - а на сколько, и почему?
4 - вот это поддерживать надо, и зависит от конфига. Не пойму пока что, что туда кидать, за исключением одного клиента, у которого за openvpn-клиентом подсеть, куда нужен доступ из сети за сервером - у меня там конфиг с iroute.
5 - классно)
6 - тоже хорошо. Однако easyrsa можно докрутить до того, что его ЦС будет работать именно с эллиптической криптографией (set_var EASYRSA_ALGO ec; set_var EASYRSA_CURVE secp384r1)
Хмм. Про грабли:
Управление CA - хотя и неприятно, но можно сделать на вменяемом уровне. То же создание CRL и подсовывание его серверу вполне себе автоматизируется на уровне крона. Обновление сертификатов - удобство vs безопасность, либо у тебя потерянные SSH-ключи на wg, либо забытые сертификаты на easyrsa, что технически одно и то же. Но если серт рано или поздно истечёт, то ключ - нет.
Userspace vs kernel space - грабли валидные, может наткнёмся со временем, но оверхэд там для нас не критичен настолько, чтобы решало. (Вот будь у нас 40Гбит/с снаружи, могло бы влиять по идее)
Спорные грабли. Да, wireguard меньше в виде кода, но статические (и динамические) анализаторы решают проблему аудита в поисках багов довольно эффективно. Ну и никто не застрахован от бага в либах, который можно проэксплойтить даже через идеальный код использующего приложения.
Насколько у вас сложные правила для OpenVPN, что вам надо поддерживать кастомные скрипты OpenVPN на стороне клиентов? А также, насколько часто у вас меняется конфигурация локальной сети "за" сервером OpenVPN, что надо лазать в конфиг и править там push route или ещё какие-то параметры? Один раз заточил, и оно "просто" работает. Про частые проблемы:
"Не могу зайти в VPN" - ну, штатная ситуация, можно лечить скриптами автоматического перевыпуска сертификатов, условно раз в месяц, и превентивно рассылать новые конфиги. По сравнению со статическими SSH-ключами Wireguard - удобство vs безопасность, плюс защита от забывчивости в случае увольнения кого-то, если сразу не сделали отзыв. По мне, так или иначе доступ к VPN админить надо, ваше решение не хуже многих.
OpenVPN прекрасно умеет работать по UDP - что мешает/мешало перенастроить сервер (поднять второй инстанс, начать перевозить клиентов по инструкции, ещё как) на использование UDP в качестве транспортного протокола? Проблема разрыва соединений и переподключения в мобильном роуминге решается параметром auth-gen-token (время в секундах) в конфиге сервера или CCD клиента, если нельзя на весь сервер включить.
А что это у вас кто попало лазает в easyrsa кривыми руками? Он, кстати, по логике должен жить отдельно от OpenVPN, в идеале на нормально выключенной ВМ, и бэкапаться регулярно, как центр доверия системы VPN. И при нормальной безопасности разрешение на вход по VPN должно выдаваться администраторами, кривых рук там быть не должно (как есть - смотрите сами, кто там вам ломал ЦС, какими действиями, почему и зачем, и насколько сильно его за это бить - тоже). Про альтернативы:
Какая такая проблема сложности PKI? Сложно создать CRL и добросить его до сервера? Сложно мониторить истечение сертификатов? (openssl x509 -enddate) Сложно держать его несломанным? Грубо говоря, семь бед - один backup.
"Голый" IPsec?! Он хорош для перманентных подключений через белые IP, и неизменяемых настройках пробрасываемых сетей. Применять его для подключения бегающих клиентов как минимум нелогично. L2TP/IPsec - вариант, но наши "доблестные" РКП его режут нещадно. Да, не вариант, но то, что он вообще тут появился, не подходит под описываемый сценарий использования VPN. 3, 4 - да, инфраструктура VPN должна быть "своей" вместе с центром доверия - но задачи управления им с вас не снимаются.
Проблемы настройки WG vs OpenVPN:
Firewall - смешно. Вы же проверяете подключение до того, как выставить сервер в прод, да? (ДА?!)
IPv4 forwarding - вообще аксиома, VPN-сервер, любой, является роутером и форвардить IPv4 обязан. (IPv6 не забудьте, кстати, если настраивали, он отдельно включается)
Ну, keepalive есть и в OpenVPN, но да, нужен.
Добавление - ну ОК, а удаление?
Итого: Можно было обойтись перенастройкой OpenVPN с тем же эффектом (ну, минус оверхэд, от него не уйти).