🅴🆁🆄🅰 🇷🇺

🅴🆁🆄🅰 🇷🇺

erua@hub.hubzilla.de

This channel has not added a profile description yet

2026-08-07 11:16:10

🅴🆁🆄🅰 🇷🇺

erua@hub.hubzilla.de

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

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

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

Сценарий №2
Это когда веб-сайт предъявляет цепочку заверенную «нормальным» корневым сертификатом.
Т.е. таким корневым, который изначально размещён в специализированном хранилище на устройства, сформированном ещё вендором устройства (платформы или операционной системы).

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

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

Как работает 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 #chromium #chrome #lang_ru @Russia

криптография

2026-08-06 17:44:16

🅴🆁🆄🅰 🇷🇺

erua@hub.hubzilla.de

О чем не пишут в лентах новостей про массовый отзыв 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

криптография

2026-08-03 23:51:43

🅴🆁🆄🅰 🇷🇺

erua@hub.hubzilla.de

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

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

криптография

2024-07-25 19:41:21

🅴🆁🆄🅰 🇷🇺

erua@hub.hubzilla.de

Есть альтернативная прошивка для раций и радиостанций — OpenGD77 (цифровых, #DMR они же DMRA)
И очень комично наблюдать, как народ утверждает, что функции шифрование нет и не будет в этой прошивке, поскольку это якобы не законно. И приводят в пример ту же Австралию, где всё сквозное шифрование теперь обязано иметь бэкдоры.
Т.е. люди увидели в рациях #STM -контроллеры и решили сделать «открытую прошивку», но при этом не удосужились посмотреть как и с каким шифрованием живёт #open-source мир т. н. #free-software

В чём проблема с шифрованием в рациях? Реализация #AES имеется не во всех моделях, а если имеется, то порой это AES 128, вместо AES 256. И даже если у двух раций имеется AES 256, то не факт, что они совместимы — смогут между собой общаться имея одинаковые ключи шифрования. Потому что IV (вектор инициализации) у них почти всегда и постоянный, и у каждого производителя свой собственный. Только лишь #Motorola и кое-кто из вендоров реализовали в своих DMR-рациях динамически изменяемый IV, да и то не известно по какому принципу.

Подозрительно тем, что ранее эта самая Моторола использовала явный backdoor в более простом режиме шифрования для DMR — который ARC4:

The Motorola ARC4 DMRA should by design provide at least 4 billion different IVs, so there should be 4 billion superframes with a different IV (2^32-bits possible IVs).
But one user discovered that Motorola uses a non-primitive LFSR for the ARC4 to generate the IVs. Instead of 4 billion different IVs, there are only 294,903 different IVs. So instead of a 32-bit IV, you get an 18-bit IV, which is much shorter than the 24-bit WEP Wi-Fi IV.

Чем угрожает и чем плоха ситуация со статическими векторами инициализации:
1) Неизменный или постоянный IV (вектор инициализации) это дырень в безопасности любого режима шифрования блочным шифром (#CBC, #OFB, #CFB, #GCM & etc). В одних режимах IV должен быть априори непредсказуем, в других всегда уникален и никогда не повторяться. Иначе будет: «ой, нас взломали».

2) Когда взломали, то это не только возможность расшифровывать записи переговоров, это ещё и возможность рассылать поддельные сообщения повторяя какие-то из перехваченных ранее, даже ещё не расшифрованные (не зломанные). Как на уровне служебного протокола, так и банальных текстовых сообщений (которыми умеют обмениваться #DMR рации).

Однако, известно, что ребята в зоне СВО уже гоняют рации со своей альтернативной прошивкой, изменяющей не только шифрование, но и устраняющую всю ту утечку мета-данных на уровне протокола DMR, из-за которых он не пригоден для военного использования в пределах 20-30 км от ЛБС. Обывателям же эту прошивку не выдают, а устанавливают на рации лишь после проверки запросившего по каналам МО РФ.

Т.е. очень может быть, что скоро в широком доступе по миру появится российский аналог OpenGD77, но с нормальным шифрованием — реализация AES 256 + качественный подход к генерации IV.

#связь #рации #радиосвязь #криптография #crypto #opengd77 #lang_ru @Russia

связь радио криптография

- - -

2023-07-02 15:22:47

🅴🆁🆄🅰 🇷🇺

erua@hub.hubzilla.de

Отказался от #OTR, потому как нравится использование #OMEMO в мессенджерах на базе #XMPP, очень «доставляет», в положительном плане.
Де-факто, выходит децентрализованная система — довольно много различных xmpp-серверов, а тот же Conversations на ведройдах даёт фактически тоже самое, что и эти ваши WhatsApp, Telegram, Viber & etc.

Понятно, что OMEMO сделан на базе протокола #Signal ( https://signal.org), понятно что автором являются те же, кто #Conversations делает ( https://conversations.im/omemo/)
Но оно работает и весьма стабильно, предоставляя и «Future and Forward Secrecy» и позволяя прозрачно управлять ключами.
При необходимости, меняешь xmpp-сервак, меняется JID, но собеседники опознают по отпечаткам ключей на разных устройствах.

Приходится констатировать закат эры OTR в мессенджерах и очень скоро он может уйти со сцены в мире IRC, вероятно уступив OMEMO.

Ненаглядный Signal выигрывает лишь за счёт анонимности сообщений для серверов https://signal.org/blog/sealed-sender/ когда сервер не знает, кто и с кем из пользователей переписывается — когда и как часто.
Но при этом проигрывает в децентрализованности, от того связка XMPP + OMEMO оказывается весьма удачной комбинацией.

#связь #crypto #криптография #jabber #lang_ru @Russia @ru

криптография