home.social

#pki — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #pki, aggregated by home.social.

fetched live
  1. От Root CA до User Authorization в nginx+apache. Часть 3. Вход по клиентскому сертификату: прокси или приложение

    В первой части я обещал беспарольный вход в админку. Здесь он наконец заработал. Что внутри: — mTLS в nginx и apache: все директивы, все переменные $ssl_client_* и SSL_CLIENT_* , семь справочников на 309 параметров, сверенных с документацией; — вход по кнопке вместо диалога выбора сертификата на первом же заходе — с отдельным хостом, одноразовым пропуском и защитой от login CSRF; — выпуск сертификата в один клик: ключ рождается в браузере и не уезжает на сервер; — свой web-УЦ на Go без единой зависимости, где ключ УЦ отделён от веба сетевой границей. И честная часть: три дефекта, которые вылезли только на живом стенде, окно версий nginx между CVE и регрессией, и дыра, которую состязательная проверка нашла в уже работавшем коде.

    habr.com/ru/articles/1073162/

    #mtls #nginx #apache #openssl #клиентские_сертификаты #авторизация_без_паролей #pki #удостоверяющий_центр #go #tls

  2. От Root CA до User Authorization в nginx+apache. Часть 3. Вход по клиентскому сертификату: прокси или приложение

    В первой части я обещал беспарольный вход в админку. Здесь он наконец заработал. Что внутри: — mTLS в nginx и apache: все директивы, все переменные $ssl_client_* и SSL_CLIENT_* , семь справочников на 309 параметров, сверенных с документацией; — вход по кнопке вместо диалога выбора сертификата на первом же заходе — с отдельным хостом, одноразовым пропуском и защитой от login CSRF; — выпуск сертификата в один клик: ключ рождается в браузере и не уезжает на сервер; — свой web-УЦ на Go без единой зависимости, где ключ УЦ отделён от веба сетевой границей. И честная часть: три дефекта, которые вылезли только на живом стенде, окно версий nginx между CVE и регрессией, и дыра, которую состязательная проверка нашла в уже работавшем коде.

    habr.com/ru/articles/1073162/

    #mtls #nginx #apache #openssl #клиентские_сертификаты #авторизация_без_паролей #pki #удостоверяющий_центр #go #tls

  3. От Root CA до User Authorization в nginx+apache. Часть 3. Вход по клиентскому сертификату: прокси или приложение

    В первой части я обещал беспарольный вход в админку. Здесь он наконец заработал. Что внутри: — mTLS в nginx и apache: все директивы, все переменные $ssl_client_* и SSL_CLIENT_* , семь справочников на 309 параметров, сверенных с документацией; — вход по кнопке вместо диалога выбора сертификата на первом же заходе — с отдельным хостом, одноразовым пропуском и защитой от login CSRF; — выпуск сертификата в один клик: ключ рождается в браузере и не уезжает на сервер; — свой web-УЦ на Go без единой зависимости, где ключ УЦ отделён от веба сетевой границей. И честная часть: три дефекта, которые вылезли только на живом стенде, окно версий nginx между CVE и регрессией, и дыра, которую состязательная проверка нашла в уже работавшем коде.

    habr.com/ru/articles/1073162/

    #mtls #nginx #apache #openssl #клиентские_сертификаты #авторизация_без_паролей #pki #удостоверяющий_центр #go #tls

  4. Агрегируем практики по харденингу Active Directory Domain Services

    Служба каталогов Active Directory Domain Services, к сожалению, достаточно часто недооценивается бизнесом или ИТ-персоналом с точки зрения её критичности. Она представляет из себя не просто базу данных пользователей - а целый набор информационных систем, компрометация которых даёт злоумышленникам полный контроль над всеми сервисами, интегрированными в доменную среду (файловые и веб-сервера, СУБД, иногда среды управления виртуализацией, резервным копированием, сетевым оборудованием и т.д.), позволяя беспрепятственно эскалировать привилегии и осуществлять горизонтальное перемещение в сети. Именно поэтому сегодня я постараюсь агрегировать в данном материале релевантную информацию касательно харденинга AD DS для нашего профессионального сообщества.

    habr.com/ru/articles/975480/

    #информационная_безопасность #activedirectory #pki

  5. Агрегируем практики по харденингу Active Directory Domain Services

    Служба каталогов Active Directory Domain Services, к сожалению, достаточно часто недооценивается бизнесом или ИТ-персоналом с точки зрения её критичности. Она представляет из себя не просто базу данных пользователей - а целый набор информационных систем, компрометация которых даёт злоумышленникам полный контроль над всеми сервисами, интегрированными в доменную среду (файловые и веб-сервера, СУБД, иногда среды управления виртуализацией, резервным копированием, сетевым оборудованием и т.д.), позволяя беспрепятственно эскалировать привилегии и осуществлять горизонтальное перемещение в сети. Именно поэтому сегодня я постараюсь агрегировать в данном материале релевантную информацию касательно харденинга AD DS для нашего профессионального сообщества.

    habr.com/ru/articles/975480/

    #информационная_безопасность #activedirectory #pki

  6. Агрегируем практики по харденингу Active Directory Domain Services

    Служба каталогов Active Directory Domain Services, к сожалению, достаточно часто недооценивается бизнесом или ИТ-персоналом с точки зрения её критичности. Она представляет из себя не просто базу данных пользователей - а целый набор информационных систем, компрометация которых даёт злоумышленникам полный контроль над всеми сервисами, интегрированными в доменную среду (файловые и веб-сервера, СУБД, иногда среды управления виртуализацией, резервным копированием, сетевым оборудованием и т.д.), позволяя беспрепятственно эскалировать привилегии и осуществлять горизонтальное перемещение в сети. Именно поэтому сегодня я постараюсь агрегировать в данном материале релевантную информацию касательно харденинга AD DS для нашего профессионального сообщества.

    habr.com/ru/articles/975480/

    #информационная_безопасность #activedirectory #pki

  7. When people say that #PKI should work "offline", I am always thinking about The Meadow. Opus and Steve should be able to bring up a secure link (over BT or #6lowpan or adhoc wifi) without having to go online.

  8. When people say that #PKI should work "offline", I am always thinking about The Meadow. Opus and Steve should be able to bring up a secure link (over BT or #6lowpan or adhoc wifi) without having to go online.

  9. When people say that #PKI should work "offline", I am always thinking about The Meadow. Opus and Steve should be able to bring up a secure link (over BT or #6lowpan or adhoc wifi) without having to go online.

  10. When people say that #PKI should work "offline", I am always thinking about The Meadow. Opus and Steve should be able to bring up a secure link (over BT or #6lowpan or adhoc wifi) without having to go online.

  11. When people say that #PKI should work "offline", I am always thinking about The Meadow. Opus and Steve should be able to bring up a secure link (over BT or #6lowpan or adhoc wifi) without having to go online.

  12. I searched our own domain in the public certificate transparency logs.

    Three dev servers and four vendors, named. Nobody scanned us. We published it ourselves by getting SSL certificates.

    certkit.io/blog/somebody-is-ke

    #PKI

  13. I searched our own domain in the public certificate transparency logs.

    Three dev servers and four vendors, named. Nobody scanned us. We published it ourselves by getting SSL certificates.

    certkit.io/blog/somebody-is-ke

    #PKI

  14. I searched our own domain in the public certificate transparency logs.

    Three dev servers and four vendors, named. Nobody scanned us. We published it ourselves by getting SSL certificates.

    certkit.io/blog/somebody-is-ke

    #PKI

  15. RFC 10015 (July 2026) makes RSA key exchange and finite-field DH MUST NOT in TLS 1.2.

    Both ship enabled in nginx, Apache and Windows Server defaults. You never turned them on.

    ECDHE is untouched.

    certkit.io/blog/tls-1-2-end-of

    #TLS #PKI

  16. RFC 10015 (July 2026) makes RSA key exchange and finite-field DH MUST NOT in TLS 1.2.

    Both ship enabled in nginx, Apache and Windows Server defaults. You never turned them on.

    ECDHE is untouched.

    certkit.io/blog/tls-1-2-end-of

    #TLS #PKI

  17. RFC 10015 (July 2026) makes RSA key exchange and finite-field DH MUST NOT in TLS 1.2.

    Both ship enabled in nginx, Apache and Windows Server defaults. You never turned them on.

    ECDHE is untouched.

    certkit.io/blog/tls-1-2-end-of

    #TLS #PKI

  18. With PKI you have two options:
    For a small setup like a home lab you can self-sign a few certs or create your own little CA and add it to the trusted store of a couple devices.

    For a global, billion user, multi-agency setup with frequent nation-state attacks and national security level data classifications. Much enterprise class software and good practice exists to establish a secure Chain of Authority, cross verify it, issue certs, revoke certs, identify leaks etc etc probably managed by some dedicated PKI team who's finances, hobbies, vices and family are under 24/7 surveillance by government operatives.

    For anything in between you can get absolutely fucked, fuck you.
    #PKI #security

  19. With PKI you have two options:
    For a small setup like a home lab you can self-sign a few certs or create your own little CA and add it to the trusted store of a couple devices.

    For a global, billion user, multi-agency setup with frequent nation-state attacks and national security level data classifications. Much enterprise class software and good practice exists to establish a secure Chain of Authority, cross verify it, issue certs, revoke certs, identify leaks etc etc probably managed by some dedicated PKI team who's finances, hobbies, vices and family are under 24/7 surveillance by government operatives.

    For anything in between you can get absolutely fucked, fuck you.
    #PKI #security

  20. i travel around quite a bit and there are some really rural areas that have tons of fiber, the rollout is hit and miss, there is a lot of rural america #bead program #qkd #pki #mkt penetration #shentel #glofiber

  21. i travel around quite a bit and there are some really rural areas that have tons of fiber, the rollout is hit and miss, there is a lot of rural america #bead program #qkd #pki #mkt penetration #shentel #glofiber

  22. i travel around quite a bit and there are some really rural areas that have tons of fiber, the rollout is hit and miss, there is a lot of rural america #bead program #qkd #pki #mkt penetration #shentel #glofiber

  23. i travel around quite a bit and there are some really rural areas that have tons of fiber, the rollout is hit and miss, there is a lot of rural america #bead program #qkd #pki #mkt penetration #shentel #glofiber

  24. Google Cloud published a dated PQC migration roadmap on 11 Aug. Nineteen dated entries against named services, which is more resolution than AWS or Microsoft has published.

    Domain 1 covers store-now-decrypt-later mitigation - end of 2027. Domain 2 covers integrity and non-repudiation, Domain 3 foundations and key management, and both for 2028. Everything converges on 2029.

    Google's March post said it had adjusted its threat model to prioritize authentication and digital signatures. The roadmap now puts signatures a year behind confidentiality anyway.

    So I try to explain the change.

    postquantum.com/security-pqc/g

    #PQC #postquantum #cryptography #infosec #TLS #PKI #cloudsecurity

  25. Google Cloud published a dated PQC migration roadmap on 11 Aug. Nineteen dated entries against named services, which is more resolution than AWS or Microsoft has published.

    Domain 1 covers store-now-decrypt-later mitigation - end of 2027. Domain 2 covers integrity and non-repudiation, Domain 3 foundations and key management, and both for 2028. Everything converges on 2029.

    Google's March post said it had adjusted its threat model to prioritize authentication and digital signatures. The roadmap now puts signatures a year behind confidentiality anyway.

    So I try to explain the change.

    postquantum.com/security-pqc/g

    #PQC #postquantum #cryptography #infosec #TLS #PKI #cloudsecurity

  26. Google Cloud published a dated PQC migration roadmap on 11 Aug. Nineteen dated entries against named services, which is more resolution than AWS or Microsoft has published.

    Domain 1 covers store-now-decrypt-later mitigation - end of 2027. Domain 2 covers integrity and non-repudiation, Domain 3 foundations and key management, and both for 2028. Everything converges on 2029.

    Google's March post said it had adjusted its threat model to prioritize authentication and digital signatures. The roadmap now puts signatures a year behind confidentiality anyway.

    So I try to explain the change.

    postquantum.com/security-pqc/g

    #PQC #postquantum #cryptography #infosec #TLS #PKI #cloudsecurity

  27. Google Cloud published a dated PQC migration roadmap on 11 Aug. Nineteen dated entries against named services, which is more resolution than AWS or Microsoft has published.

    Domain 1 covers store-now-decrypt-later mitigation - end of 2027. Domain 2 covers integrity and non-repudiation, Domain 3 foundations and key management, and both for 2028. Everything converges on 2029.

    Google's March post said it had adjusted its threat model to prioritize authentication and digital signatures. The roadmap now puts signatures a year behind confidentiality anyway.

    So I try to explain the change.

    postquantum.com/security-pqc/g

    #PQC #postquantum #cryptography #infosec #TLS #PKI #cloudsecurity

  28. Grupa staje się "Zweryfikowana" – nikt z zewnątrz (nawet administrator serwera) nie może dopisać do niej trzeciej osoby.

    Więcej informacji 👉 lttr.ai/At4zI

    #Security #OpenSource #Pki

  29. Grupa staje się "Zweryfikowana" – nikt z zewnątrz (nawet administrator serwera) nie może dopisać do niej trzeciej osoby.

    Więcej informacji 👉 lttr.ai/At4zI

    #Security #OpenSource #Pki

  30. Grupa staje się "Zweryfikowana" – nikt z zewnątrz (nawet administrator serwera) nie może dopisać do niej trzeciej osoby.

    Więcej informacji 👉 lttr.ai/At4zI

    #Security #OpenSource #Pki

  31. Исходя из чего браузер доверяет или нет конкретному сертификату?
    У сайта в публичном интернете сертификат должен быть не просто заверен корневым (root'овым), но так же содержать и записи SCT (Signed Certificate Timestamp). Однако, в первую очередь, важно каким из корневых сертификатов заверена цепочка — учитывается откуда именно взялся этот корневой сертификат.

    Сценарий №1
    Самый простой случай — использован сертификат установленный пользователем или администратором устройства. Тогда браузер всего лишь проверяет подписи до такого корневого сертификата, включительно.
    Этот сценарий полагается не публичным интернетом, а использованием веб-ресурсов в локальных сетях или специализированных порталов корпоративной инфраструктуры. И потому браузер особо не мудрствует, а ориентируется на те флаги, по которым можно понять, откуда в хранилище сертификатов взялся корневой сертификат.

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

    Сценарий №2
    Это когда веб-сайт предъявляет цепочку заверенную «нормальным» корневым сертификатом.
    Таким корневым, который из множества изначально размещённого в специализированном хранилище на устройства (сформировано вендором устройства/платформы или операционной системы).
    Однако, современный веб-браузер не доверяет специализированному хранилищу и смотрит в своё собственное. Фактически браузер использует эпизодически обновляемый список отозванных сертификатов.
    Например, в 2020-2021 годах Правительство Казахстана пыталось внедрить слежку за гражданами, обязывая всех внедрять корневой сертификат на продаваемые устройства и компьютеры. Бывали случае и другого толка, от различных вендоров устройств, ради подглядывания за трафиком с целью сбора данных для рекламы.
    В таких раскладах Chrome и остальные на базе Chromium (Vivaldi, Brave & etc.) стремились оградить пользователей и нивелировали эту злонамеренную активность с сертификатами. Т.е. браузер исходит лишь из своей собственный модели доверия к сертификатам, опираясь на своё хранилище, используя системное централизованное лишь на вторичных ролях.

    Если веб-браузер убедился, что с корневым сертификатом всё нормально, тогда наступает вторая фаза — а имеются ли SCT (Signed Certificate Timestamp) записи в той цепочке сертификатов, которую предъявляет загружаемый веб-сайт. Если нет двух-трёх записей SCT, то и доверия к сертификату сайта не будет.
    Это часть инициативы Certificate Transparency (CT), благодаря которой в современных реалиях удостоверяющие центры не могут выпускать втихоря по несколько сертификатов для одного и того же сайта. Например, исходя из мошеннических побуждений, давления или сговора с правоохранительными, силовыми или правительственными структурами.
    Как это работает, в процессе выпуска сертификата удостоверяющий центр обращается к нескольким независимым друг от друга CT-реестрам и регистрирует там факт выдачи конкретного сертификата для конкретного домена — получая от каждого SCT (Signed Certificate Timestamp) запись, которая и добавляется в сертификат.
    Владельцы и пользователи онлайн-ресурса могут отслеживать по CT-реестрам факт неожиданной выдачи сертификатов на определённые доменные имена. Собственники CT-реестра не заинтересованы мухлевать и сговариваться с удостоверяющими центрами, поскольку SCT-записи заверяются цифровой подписью CT-реестра. Все записи о выданных сертификатах в CT-реестре являются деревом Меркла — фактически это блокчейн, когда цепочка блоков сшита хеш-суммами.

    Выписывая квиточек — SCT (Signed Certificate Timestamp) запись — реестр обязуется включить запись о данном сертификате не моментально, а с некоторой задержкой по времени, порой и до 24 часов.

    Свой PKI, без монополий корпораций
    Изложенное здесь и ранее определяет ситуацию, что государствам надо развивать свои веб-браузеры. Поскольку вся эта игра со списками отозванных сертификатов находится прямо в кодовой базе open source того же Chromium и неизвестно как будет использоваться корпорациями (политически ангажированными и весьма одиозными).
    На данный момент разнообразие в РФ не блещет и не радует, это или Яндекс или Атом — каждый из которых напичкан супер-плотной интеграцией либо с Яндекс-сервисами, либо ВК-сервисами, соответственно. Нормальному человеку такое сложно вручать, даже при условии использования сугубо лишь для походов по ресурсам государственных услуг, здравоохранения и кредитно финансовых учреждений. В любом случае, придётся держать на устройствах несколько веб-браузеров с разделением обязанностей.

    Однако, помимо суеты с веб-браузером так же был поднят и свой Certificate Transparency (CT) реестр, о чём громко заявлял Яндекс в районе 2022 года. Поскольку никакой иностранный не будет принимать данные-записи о выдачи сертификатов заверенных Минцифры РФ и соответственно не будет SCT-квиточки формировать для включения в сертификаты.
    А всяких разных Certificate Transparency (CT) реестров должно быть сразу несколько, желательно в разных юрисдикциях, во избежание подозрений в инсинуациях и пустых упрёков. Вероятно работающих не только с российскими удостоверяющими центрами, но и стран БРИКС, СНГ и оставшихся семи миллиардов, в противовес тем, что обслуживают интересы «золотого миллиарда» (население планеты уже более 8 миллиардов).

    #https #certificate-transparency #crypto #криптография #tls #PKI #pki #google #apple #lang_ru @Russia
  32. "Oferujemy wdrożenie w pełni wyizolowanego, bezpiecznego środowiska komunikacji biznesowej w oparciu o system Delta Chat – w 100% niezależny od algorytmów Zuckerberga, CBA, FBI, CIA, Google czy Microsoftu." lttr.ai/At29g

    #Security #OpenSource #Pki

  33. "Oferujemy wdrożenie w pełni wyizolowanego, bezpiecznego środowiska komunikacji biznesowej w oparciu o system Delta Chat – w 100% niezależny od algorytmów Zuckerberga, CBA, FBI, CIA, Google czy Microsoftu." lttr.ai/At29g

    #Security #OpenSource #Pki

  34. "Oferujemy wdrożenie w pełni wyizolowanego, bezpiecznego środowiska komunikacji biznesowej w oparciu o system Delta Chat – w 100% niezależny od algorytmów Zuckerberga, CBA, FBI, CIA, Google czy Microsoftu." lttr.ai/At29g

    #Security #OpenSource #Pki

  35. О чем не пишут в лентах новостей про массовый отзыв TLS-сертификатов у российских организаций.
    Фактически дело в Google & Apple, а точнее в их подданстве (США) — именно эти компании подпадают под Strict Liability в вопросах нацибеза и санкционного режима (OFAC & BIS). Когда госрегулятор приходит не с предписаниями, а уже со штрафами и уголовными делами для топ-менеджеров, за ненадлежащую проверку контрагентов по SDN (список рестрикций в США).
    Изменение регламента в «CA/Browser Forum» инициирован этими компаниями, чтобы избежать подобного сценария преследования и разбирательств с Минюстом США.

    Если какой-то из удостоверяющий центров продолжит выписывать сертификаты для российских «подсанкционных» юрлиц, то вообще все сертификаты выданные этим центром перестанут работать в платформах Google & Apple. И речь не только про Android, но и браузер Chrome на какой бы ОС таковый ни выполнялся. Поскольку техническая сторона вопроса такова, что Chrome самостоятельно решает каким корневым (root'овым) сертификатам доверять (от каких удостоверяющих центров).
    Это вшито в кодовую базу и затрагивает махом сразу все браузеры на базе Chromium'а — как Vivaldi, Brave и т.п.

    Установка сертификаты Минцифры РФ пользователем самостоятельно трактуется как доверенный, но будет работать лишь до тех пор, пока тот же Google не решит запретить использование такового на своих устройствах и в экосистеме Chrome & Chromium.

    Почему не отозван сертификат у Госуслуг?
    У этого ресурса сертификат DV (Domain Validation) типа, когда неизвестно какая организация стоит за доменом, а выдача сертификата производится лишь по факту автоматической проверки контроля за доменом. Т.е. в отличии от OV/EV типа сертификатов не производится никакой проверки юрлица стоящего за онлайн-ресурсом.
    Да и угрожать GlobalSign отменой корневого сертификата ни Google ни Apple не могут, т.к. это накроет медным тазом огромное количество ресурсов — фактически это миллионы ресурсов (как банковских, так и государственных порталов во многих странах).
    Далее, всегда в любых санкционных-рестрикциях прописывается исключение для критической гражданской инфраструктуры. Поскольку война официально не объявлена, то госрегуляторы не вправе требовать чинить препятствия работе того, что может повлиять на связь (телеком), здравоохранение и базовые государственные сервисы.

    Отдельно про техническую сторону вопроса работы системы PKI в плане сертификатов для веб-сайтов (и SCT-записи, и CT-логи и как пользовательские сертификаты ущемляются, а так же какой цифровой суверенитет в РФ из-за этого разворачивается).

    #https #crypto #криптография #tls #PKI #pki #google #apple #lang_ru @Russia
  36. О чем не пишут в лентах новостей про массовый отзыв TLS-сертификатов у российских организаций.
    Фактически дело в Google & Apple, а точнее в их подданстве (США) — именно эти компании подпадают под Strict Liability в вопросах нацибеза и санкционного режима (OFAC & BIS). Когда госрегулятор приходит не с предписаниями, а уже со штрафами и уголовными делами для топ-менеджеров, за ненадлежащую проверку контрагентов по SDN (список рестрикций в США).
    Изменение регламента в «CA/Browser Forum» инициирован этими компаниями, чтобы избежать подобного сценария преследования и разбирательств с Минюстом США.

    Если какой-то из удостоверяющий центров продолжит выписывать сертификаты для российских «подсанкционных» юрлиц, то вообще все сертификаты выданные этим центром перестанут работать в платформах Google & Apple. И речь не только про Android, но и браузер Chrome на какой бы ОС таковый ни выполнялся. Поскольку техническая сторона вопроса такова, что Chrome самостоятельно решает каким корневым (root'овым) сертификатам доверять (от каких удостоверяющих центров).
    Это вшито в кодовую базу и затрагивает махом сразу все браузеры на базе Chromium'а — как Vivaldi, Brave и т.п.

    Установка сертификаты Минцифры РФ пользователем самостоятельно трактуется как доверенный, но будет работать лишь до тех пор, пока тот же Google не решит запретить использование такового на своих устройствах и в экосистеме Chrome & Chromium.

    Почему не отозван сертификат у Госуслуг?
    У этого ресурса сертификат DV (Domain Validation) типа, когда неизвестно какая организация стоит за доменом, а выдача сертификата производится лишь по факту автоматической проверки контроля за доменом. Т.е. в отличии от OV/EV типа сертификатов не производится никакой проверки юрлица стоящего за онлайн-ресурсом.
    Да и угрожать GlobalSign отменой корневого сертификата ни Google ни Apple не могут, т.к. это накроет медным тазом огромное количество ресурсов — фактически это миллионы ресурсов (как банковских, так и государственных порталов во многих странах).
    Далее, всегда в любых санкционных-рестрикциях прописывается исключение для критической гражданской инфраструктуры. Поскольку война официально не объявлена, то госрегуляторы не вправе требовать чинить препятствия работе того, что может повлиять на связь (телеком), здравоохранение и базовые государственные сервисы.

    Техническая сторона вопроса работы системы PKI в плане сертификатов для веб-сайтов является TL;DR и будет позднее отдельно с деталями и нюансами. И про SCT, и CT-логи и как пользовательские сертификаты ущемляются, а так же какой цифровой суверенитет в РФ из-за этого разворачивается.

    #crypto #криптография #tls #PKI #pki #google #apple #lang_ru @Russia
  37. For the PKI/TLS people here: Chrome's MTC test-operator program is now receiving external applications.

    TrustAsia filed Chromium Issue 538260165 ("Test MTC CA Operator: [TrustAsia]") on July 24. Geomys followed on July 31. PKI standards expert Corey Bonnell surfaced the TrustAsia filing publicly and identified it as the first such application he could find in the tracker.

    The technical details: TrustAsia's filing uses unsigned CA trust-anchor certificates per RFC 9925 (the general-purpose profile for X.509 certificates without cryptographic signatures, finalized Feb 2026) and the critical id-pe-mtcCertificationAuthority extension from draft-ietf-plants-merkle-tree-certs-05. The extension carries four fields — log hash algorithm, cosigner signature algorithm, and separate min/max serial number bounds. The critical marking prevents conventional path validators from misinterpreting the certificate as an ordinary intermediate.

    TrustAsia qualifies for Chrome's Phase 2 (Q1 2027) through its CT log history — Chrome-qualified since 2021, with current log2026a/b shards carrying usable status, clearing the "usable log before Feb 1, 2026" threshold.

    Chrome's quantum-resistant root store (CQRS) is targeted for Q3 2027. The current Chrome-Cloudflare experiment covers ~1,000 domains with classical signatures and X.509 failsafe. Production post-quantum authentication via MTC is still a 2027 target, not current reality.

    My full analysis covers the web PKI fork implications for PQC migration, the RFC 9925 mechanics, Chrome's three-phase plan, and what DigiCert, Let's Encrypt, and now TrustAsia/Geomys activity means for the MTC deployment timeline:

    postquantum.com/security-pqc/t

    #infosec #cybersecurity #cryptography #PQC #postquantum #TLS #PKI #quantum

  38. For the PKI/TLS people here: Chrome's MTC test-operator program is now receiving external applications.

    TrustAsia filed Chromium Issue 538260165 ("Test MTC CA Operator: [TrustAsia]") on July 24. Geomys followed on July 31. PKI standards expert Corey Bonnell surfaced the TrustAsia filing publicly and identified it as the first such application he could find in the tracker.

    The technical details: TrustAsia's filing uses unsigned CA trust-anchor certificates per RFC 9925 (the general-purpose profile for X.509 certificates without cryptographic signatures, finalized Feb 2026) and the critical id-pe-mtcCertificationAuthority extension from draft-ietf-plants-merkle-tree-certs-05. The extension carries four fields — log hash algorithm, cosigner signature algorithm, and separate min/max serial number bounds. The critical marking prevents conventional path validators from misinterpreting the certificate as an ordinary intermediate.

    TrustAsia qualifies for Chrome's Phase 2 (Q1 2027) through its CT log history — Chrome-qualified since 2021, with current log2026a/b shards carrying usable status, clearing the "usable log before Feb 1, 2026" threshold.

    Chrome's quantum-resistant root store (CQRS) is targeted for Q3 2027. The current Chrome-Cloudflare experiment covers ~1,000 domains with classical signatures and X.509 failsafe. Production post-quantum authentication via MTC is still a 2027 target, not current reality.

    My full analysis covers the web PKI fork implications for PQC migration, the RFC 9925 mechanics, Chrome's three-phase plan, and what DigiCert, Let's Encrypt, and now TrustAsia/Geomys activity means for the MTC deployment timeline:

    postquantum.com/security-pqc/t

    #infosec #cybersecurity #cryptography #PQC #postquantum #TLS #PKI #quantum

  39. For the PKI/TLS people here: Chrome's MTC test-operator program is now receiving external applications.

    TrustAsia filed Chromium Issue 538260165 ("Test MTC CA Operator: [TrustAsia]") on July 24. Geomys followed on July 31. PKI standards expert Corey Bonnell surfaced the TrustAsia filing publicly and identified it as the first such application he could find in the tracker.

    The technical details: TrustAsia's filing uses unsigned CA trust-anchor certificates per RFC 9925 (the general-purpose profile for X.509 certificates without cryptographic signatures, finalized Feb 2026) and the critical id-pe-mtcCertificationAuthority extension from draft-ietf-plants-merkle-tree-certs-05. The extension carries four fields — log hash algorithm, cosigner signature algorithm, and separate min/max serial number bounds. The critical marking prevents conventional path validators from misinterpreting the certificate as an ordinary intermediate.

    TrustAsia qualifies for Chrome's Phase 2 (Q1 2027) through its CT log history — Chrome-qualified since 2021, with current log2026a/b shards carrying usable status, clearing the "usable log before Feb 1, 2026" threshold.

    Chrome's quantum-resistant root store (CQRS) is targeted for Q3 2027. The current Chrome-Cloudflare experiment covers ~1,000 domains with classical signatures and X.509 failsafe. Production post-quantum authentication via MTC is still a 2027 target, not current reality.

    My full analysis covers the web PKI fork implications for PQC migration, the RFC 9925 mechanics, Chrome's three-phase plan, and what DigiCert, Let's Encrypt, and now TrustAsia/Geomys activity means for the MTC deployment timeline:

    postquantum.com/security-pqc/t

    #infosec #cybersecurity #cryptography #PQC #postquantum #TLS #PKI #quantum

  40. For the PKI/TLS people here: Chrome's MTC test-operator program is now receiving external applications.

    TrustAsia filed Chromium Issue 538260165 ("Test MTC CA Operator: [TrustAsia]") on July 24. Geomys followed on July 31. PKI standards expert Corey Bonnell surfaced the TrustAsia filing publicly and identified it as the first such application he could find in the tracker.

    The technical details: TrustAsia's filing uses unsigned CA trust-anchor certificates per RFC 9925 (the general-purpose profile for X.509 certificates without cryptographic signatures, finalized Feb 2026) and the critical id-pe-mtcCertificationAuthority extension from draft-ietf-plants-merkle-tree-certs-05. The extension carries four fields — log hash algorithm, cosigner signature algorithm, and separate min/max serial number bounds. The critical marking prevents conventional path validators from misinterpreting the certificate as an ordinary intermediate.

    TrustAsia qualifies for Chrome's Phase 2 (Q1 2027) through its CT log history — Chrome-qualified since 2021, with current log2026a/b shards carrying usable status, clearing the "usable log before Feb 1, 2026" threshold.

    Chrome's quantum-resistant root store (CQRS) is targeted for Q3 2027. The current Chrome-Cloudflare experiment covers ~1,000 domains with classical signatures and X.509 failsafe. Production post-quantum authentication via MTC is still a 2027 target, not current reality.

    My full analysis covers the web PKI fork implications for PQC migration, the RFC 9925 mechanics, Chrome's three-phase plan, and what DigiCert, Let's Encrypt, and now TrustAsia/Geomys activity means for the MTC deployment timeline:

    postquantum.com/security-pqc/t

    #infosec #cybersecurity #cryptography #PQC #postquantum #TLS #PKI #quantum

  41. Ну что, понеслось? С началом цифрового суверенитета?
    Что ж, берём сертификаты на ГосУслугах и на всякий случай отключаем на время DNS-over-HTTPS в браузере. И добавляем корневой сертификат через импорт в том веб-браузере, который используется для онлайн-банкинга.

    Identity: Russian Trusted Root CA
    Verified by: Russian Trusted Root CA
    Expires: 27.02.2032
    Certificate Fingerprints
    SHA1:    8F F9 15 CC AB 7B C1 6F 8C 5C 80 99 D5 3E 0E 11 5B 3A EC 2F

    Выпускающие сертификаты можно и не импортировать (файлы «russian_trusted_sub_*.crt») — должно заработать за счёт импорта лишь корневого (root'ового).
    Зачем нужны «выпускающие»?
    При каждом открытии сайта по https от сервера браузеру высылается цепочка сертификатов — и данного онлайн-ресурса, и «промежуточные» («выпускающий»). Иначе браузер будет вынужден где-то искать один из недостающих в цепочке сертификат и, возможно, это будет не всегда успешно AIA (Authority Information Access).

    Так же два файла «*_gost_2025_pem.crt» точно не пригодятся совершенно в массах — это для того софта, который в российскую криптографию умеет:
    • Key Algorithm: GOST R 34.10-2012 512-bit curve
    • Signature Algorithm: GOST R 34.11-2012/512 with GOST R 34.10-2012 512-bit curve


    В системе может быть сразу несколько веб-браузеров и такие вещи лучше ставить лишь в один из нескольких браузеров, используя разделение пространств. Не вынуждать свою систему на компьютере целиком и полностью доверять корневому сертификату от Минцифры.

    А в остальном, дурачьё возомнившее себя «золотым миллиардом» отгораживается от страшных русских?! Или же банально срёт на коврик перед дверью?
    Оказалось и текущий DoH-сервер (поставщик DNS-over-HTTPS) тоже решил в санкции-рестрикции поиграть — без решений ООН, но через сутки одумался и снова резолвит. Это тот, который Quad9 — под зонтиком от компании IBM и юридически швейцарский.

    #dns #online-banking #crypto #pki #онлайн-банкинг #санкции #рестрикции #импортозамещение #криптография #lang_ru @Russia
  42. Ну что, понеслось? С началом цифрового суверенитета?
    Что ж, берём сертификаты на ГосУслугах и отключаем в браузере DNS-over-HTTPS.
    И добавляем через импорт в том веб-браузере, из нескольких в системе, который используется для онлайн-банкинга:

    Identity: Russian Trusted Root CA
    Verified by: Russian Trusted Root CA
    Expires: 27.02.2032
    Certificate Fingerprints
    SHA1:    8F F9 15 CC AB 7B C1 6F 8C 5C 80 99 D5 3E 0E 11 5B 3A EC 2F

    Выпускающие сертификаты, файлы вида: «russian_trusted_sub_*.crt», можно и не импортировать, должно заработать и без них за счёт импорта корневого (root'ового).
    Однако браузер при каждом открытии сайта будет вынужден где-то искать один из двух выпускающих сертификатов и, возможно, это будет не всегда успешно. Надёжнее положить рядом с корневым.

    А вот два файла «*_gost_2025_pem.crt» пока массам не пригодятся — это для того софта, который в российскую криптографию умеет:
    • Key Algorithm: GOST R 34.10-2012 512-bit curve
    • Signature Algorithm: GOST R 34.11-2012/512 with GOST R 34.10-2012 512-bit curve


    Дурачьё возомнившее себя «золотым миллиардом» отгораживается от страшных русских?! Или же просто срёт на коврик перед дверью.
    Потому как придётся ещё DoH-провайдера менять, ныне используемый поставщик DNS-over-HTTPS тоже решил в санкции-рестрикции поиграть без решений ООН и в интернетиках вокруг DNS-запросов.

    #dns #online-banking #crypto #pki #онлайн-банкинг #санкции #рестрикции #импортозамещение #криптография #lang_ru @Russia
  43. I spent months telling people not to run their own CA.

    Today CertKit ships Private PKI. Running a CA is a job, so we took the job. SSL certs for mTLS, IPs, and internal names, root auto-installed on deploy.

    certkit.io/blog/certkit-privat

    #PKI

  44. I spent months telling people not to run their own CA.

    Today CertKit ships Private PKI. Running a CA is a job, so we took the job. SSL certs for mTLS, IPs, and internal names, root auto-installed on deploy.

    certkit.io/blog/certkit-privat

    #PKI

  45. What's in the box:

    QKD Engine - BB84, CV-QKD, and DI-QKD ready. Physical-layer key distribution that detects eavesdroppers in real-time via QBER monitoring. Eavesdrop? We measure it.

    Hardened Debian - Minimal attack surface. Kernel locked. Audit-ready. Runs on secure enclave with measured boot.

    10G Fiber NIC - Low-latency quantum-safe key exchange at wire speed. Plug into existing dark fiber or dedicated QKD links.

    QRNG Core - Hardware quantum random number generator feeding /dev/random. Real entropy from vacuum fluctuations. No pseudo-random guesswork.

    REST & gRPC APIs - Expose QRNG streams and QKD key material to your apps. Consume fresh quantum keys via simple GET requests. Integrate in minutes.

    Port Knocking + SPA - Single Packet Authorization with port knocking closes all public ports until a cryptographically signed knock sequence unlocks access. Invisible unless you know the knock.

    Post-Quantum Crypto Stack - liboqs, OpenSSL 3.x with QKD engine, hybrid PQC+QKD modes. Future-proofed.

    Small business? Enterprise edge?
    Deploy one. Deploy a mesh. The Black Box auto-discovers peers, negotiates QKD sessions, and delivers fresh symmetric keys for IPsec, TLS, or your own crypto.

    Compliance-ready. Information-theoretic security. No backdoors. No math to factor. Just physics.

    Random Oracle not included—but with this box, you generate your own.

    $2499. Debian's first quantum edge. Deploy today. Secure forever.
    #reproducible builds #rolling keys #bb84 #shor #dh..qdh? #device independent #pki #oqc ready #compliance #hybrid PQC key exchange #qssh

    github.com/QuantumUPB/qssh

  46. What's in the box:

    QKD Engine - BB84, CV-QKD, and DI-QKD ready. Physical-layer key distribution that detects eavesdroppers in real-time via QBER monitoring. Eavesdrop? We measure it.

    Hardened Debian - Minimal attack surface. Kernel locked. Audit-ready. Runs on secure enclave with measured boot.

    10G Fiber NIC - Low-latency quantum-safe key exchange at wire speed. Plug into existing dark fiber or dedicated QKD links.

    QRNG Core - Hardware quantum random number generator feeding /dev/random. Real entropy from vacuum fluctuations. No pseudo-random guesswork.

    REST & gRPC APIs - Expose QRNG streams and QKD key material to your apps. Consume fresh quantum keys via simple GET requests. Integrate in minutes.

    Port Knocking + SPA - Single Packet Authorization with port knocking closes all public ports until a cryptographically signed knock sequence unlocks access. Invisible unless you know the knock.

    Post-Quantum Crypto Stack - liboqs, OpenSSL 3.x with QKD engine, hybrid PQC+QKD modes. Future-proofed.

    Small business? Enterprise edge?
    Deploy one. Deploy a mesh. The Black Box auto-discovers peers, negotiates QKD sessions, and delivers fresh symmetric keys for IPsec, TLS, or your own crypto.

    Compliance-ready. Information-theoretic security. No backdoors. No math to factor. Just physics.

    Random Oracle not included—but with this box, you generate your own.

    $2499. Debian's first quantum edge. Deploy today. Secure forever.
    #reproducible builds #rolling keys #bb84 #shor #dh..qdh? #device independent #pki #oqc ready #compliance #hybrid PQC key exchange #qssh

    github.com/QuantumUPB/qssh

  47. What's in the box:

    QKD Engine - BB84, CV-QKD, and DI-QKD ready. Physical-layer key distribution that detects eavesdroppers in real-time via QBER monitoring. Eavesdrop? We measure it.

    Hardened Debian - Minimal attack surface. Kernel locked. Audit-ready. Runs on secure enclave with measured boot.

    10G Fiber NIC - Low-latency quantum-safe key exchange at wire speed. Plug into existing dark fiber or dedicated QKD links.

    QRNG Core - Hardware quantum random number generator feeding /dev/random. Real entropy from vacuum fluctuations. No pseudo-random guesswork.

    REST & gRPC APIs - Expose QRNG streams and QKD key material to your apps. Consume fresh quantum keys via simple GET requests. Integrate in minutes.

    Port Knocking + SPA - Single Packet Authorization with port knocking closes all public ports until a cryptographically signed knock sequence unlocks access. Invisible unless you know the knock.

    Post-Quantum Crypto Stack - liboqs, OpenSSL 3.x with QKD engine, hybrid PQC+QKD modes. Future-proofed.

    Small business? Enterprise edge?
    Deploy one. Deploy a mesh. The Black Box auto-discovers peers, negotiates QKD sessions, and delivers fresh symmetric keys for IPsec, TLS, or your own crypto.

    Compliance-ready. Information-theoretic security. No backdoors. No math to factor. Just physics.

    Random Oracle not included—but with this box, you generate your own.

    $2499. Debian's first quantum edge. Deploy today. Secure forever.
    #reproducible builds #rolling keys #bb84 #shor #dh..qdh? #device independent #pki #oqc ready #compliance #hybrid PQC key exchange #qssh

    github.com/QuantumUPB/qssh

  48. What's in the box:

    QKD Engine - BB84, CV-QKD, and DI-QKD ready. Physical-layer key distribution that detects eavesdroppers in real-time via QBER monitoring. Eavesdrop? We measure it.

    Hardened Debian - Minimal attack surface. Kernel locked. Audit-ready. Runs on secure enclave with measured boot.

    10G Fiber NIC - Low-latency quantum-safe key exchange at wire speed. Plug into existing dark fiber or dedicated QKD links.

    QRNG Core - Hardware quantum random number generator feeding /dev/random. Real entropy from vacuum fluctuations. No pseudo-random guesswork.

    REST & gRPC APIs - Expose QRNG streams and QKD key material to your apps. Consume fresh quantum keys via simple GET requests. Integrate in minutes.

    Port Knocking + SPA - Single Packet Authorization with port knocking closes all public ports until a cryptographically signed knock sequence unlocks access. Invisible unless you know the knock.

    Post-Quantum Crypto Stack - liboqs, OpenSSL 3.x with QKD engine, hybrid PQC+QKD modes. Future-proofed.

    Small business? Enterprise edge?
    Deploy one. Deploy a mesh. The Black Box auto-discovers peers, negotiates QKD sessions, and delivers fresh symmetric keys for IPsec, TLS, or your own crypto.

    Compliance-ready. Information-theoretic security. No backdoors. No math to factor. Just physics.

    Random Oracle not included—but with this box, you generate your own.

    $2499. Debian's first quantum edge. Deploy today. Secure forever.
    #reproducible builds #rolling keys #bb84 #shor #dh..qdh? #device independent #pki #oqc ready #compliance #hybrid PQC key exchange #qssh

    github.com/QuantumUPB/qssh

  49. One SSL cert, three servers. Which one generates the private key?

    Generate-where-used breaks once a cert is shared. The key moves anyway. Design that, or it becomes scp in a cron job.

    certkit.io/blog/ssl-certificat

    #SSL #PKI