Pull to refresh
30
0
Send message

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

https://ofac.treasury.gov/media/931621/download?inline

"А вы, друзья, как ни садитесь, всё в музыканты не годитесь"

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

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

В статье Scott'а Helme предложен интересный метод обойти проблему для совсем старых версий OpenSSL (начиная с версии 0.9.8m). Метод основан на том, что OpenSSL не проверяет сигнатуру сертификатов, хранящихся в локальном защищенном хранилище. Таким образом, можно изменить время действия сертификата в защищенном хранилище, при этом модифицированный сертификат будет по-прежнему восприниматься OpenSSL как валидный, несмотря на то, что целостность сертификата нарушена. Добавил этот метод в статью.

Похоже тогда есть еще какой-то влияющий фактор, который мы не учитываем... Федоры нет под рукой для экспериментов. А на debian jessie openssl 1.0.1k (не fips правда) при наличии доверенного самоподписного ISRG Root X1 и исключенном DST Root CA X3 получается "unable to get local issuer certificate".

Может сам бинарник 1.0.1k, а либы более свежие стоят? Например, все корректно работает при таком вот выводе openssl version:

OpenSSL 1.0.1k 8 Jan 2015 (Library: OpenSSL 1.0.1t 3 May 2016)

Насколько я понимаю, сопоставление идёт по издателю (issuer) сертификата на шаг дальше по цепочке. Т.е. сервер отдает цепочку ISRG Root X1 (issuer: IdenTrust’s DST Root CA X3) -> Let's Encrypt R3 (issuer: ISRG Root X1) -> Конечный сертификат (issuer: Let's Encrypt R3), в trusted store у нас на клиенте ISRG Root X1 (issuer: ISRG Root X1). При проверке на клиенте openssl видит в цепочке Let's Encrypt R3 (issuer: ISRG Root X1), ищет в своем trusted store сертификат с Subject, совпадающим с полем issuer сертификата Let's Encrypt R3 (issuer: ISRG Root X1). И находит ISRG Root X1(issuer: ISRG Root X1) - альтернативная цепочка найдена, доверие подтверждено. Коммит, где добавлена эта логика. До 1.0.1p этого не было.

Вам придется обновиться минимум до openssl 1.0.1p. Дело в том, что в trusted store хранится самоподписанный корневой сертификат ISRG Root X1. А сервер в цепочке предоставляет другую его версию - ISRG Root X1, подписанный DST Root CA X3. Не смотря на одинаковые CN, это РАЗНЫЕ сертификаты. Openssl до 1.0.1p видит в цепочке ISRG Root X1, подписанный DST Root CA X3, и не может соотнести его с самоподписанным ISRG Root X1 в trusted store - отсюда сообщение об ошибке. А начиная с версии 1.0.1p openssl соотносит сертифкат с CN=ISRG Root X1 в trusted store и в цепочке, предоставляемой сервером, поэтому верификация проходит.
PS. Есть еще одна идея, как обойтись без обновления - проверю, напишу

Какая версия openssl? Столкнулся с тем, что, например, openssl 1.0.1k в debian jessie при наличии в доверенных ISRG Root X1 и удаленном из доверия DST Root CA X3 как раз выдает ошибку "unable to get local issuer certificate". А вот openssl 1.0.1t при тех же условиях работает корректно.

Включить и установить обновления. Возможно, что хватит одного этого: https://www.microsoft.com/ru-RU/download/details.aspx?id=45633

Параметр добавлен в версии Certbot 1.6.0

Поясните, пожалуйста, свою мысль про проверку времени на сервере.

Нет, Let's Encrypt бесплатен при любом числе продлений.

Использую OpenMptcpRouter уже второе лето на даче (агрегирую в один канал 5 каналов от сотовых операторов). В целом, очень выручает, но решением с Zero Administration его пока не назовешь - в вебинтерфейс надо периодически заглядывать (смотреть, что никакой канал не отвалился и т.п.)

Так и задумано, основная цепочка останется IdenTrust’s DST Root CA X3 -> ISRG Root X1 -> Let's Encrypt R3 -> Конечный сертификат пользователя. Это сделано для того, чтобы сохранить совместимость со старыми Android (версии < 7.1.1), которые не знают про ISRG Root X1, но продолжат доверять DST Root CA X3 даже после его истечения (особенность работы с корневыми сертификатами в Android).

Спасибо, важное дополнение. Добавил в статью.

Скажем так, если у вас в Windows установлены обновления (а конкретно, обновления корневых сертификатов), то практически наверняка проблема не должна вас коснуться. Если только вы не пользователь чего-либо более старого, чем Windows XP SP3. Но в последнем случае современный HTTPS в любом случае не для вас, т.к. тогда у вас просто не будет поддержки кучи используемых сейчас в HTTPS шифров и т.п.

Тем не менее, если есть желание проверить и убедиться, то есть программа RunAsDate, аналог faketime для Windows.

Судя по тому, как горело и как расположены здания — реально повезло, что не распространилось дальше: image twitter.com/xgarreau/status/1369559995491172354?s=20

Да, иногда мне звонят не на "банковский" номер и правильно называют не только имя и отчество, но и фамилию. Номер как раз во всяких доставках используется. Так что похоже да, там сливают тоже.

1

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity