Тупо форсят (неподдерживаемый) TLSv1.3:

Нет, всё несколько сложнее ...

Можно подключиться и с TLS 1.2:

> curl --tls-max 1.2 --http1.1 --ca-native -vI https://www.fandom.com/
* Host www.fandom.com:443 was resolved.
* IPv6: (none)
* IPv4: 199.232.208.194, 199.232.212.194
*   Trying 199.232.208.194:443...
* Connected to www.fandom.com (199.232.208.194) port 443
* ALPN: curl offers http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* successfully imported Windows ROOT store
* successfully imported Windows CA store
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 / [blank] / UNDEF
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=*.fandom.com
*  start date: Jan 19 18:13:29 2024 GMT
*  expire date: Feb 19 18:13:28 2025 GMT
*  subjectAltName: host "www.fandom.com" matched cert's "*.fandom.com"
*  issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign Atlas R3 DV TLS CA 2024 Q1
*  SSL certificate verify ok.
*   Certificate level 0: Public key type ? (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type ? (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type ? (2048/112 Bits/secBits), signed using sha256WithRSAEncryption

но "в перехвате" это всё равно не работает:

> "bin/curl" --tls-max 1.2 --http1.1 --ca-native -vI https://www.fandom.com/
* Host www.fandom.com:443 was resolved.
* IPv6: (none)
* IPv4: 199.232.212.194, 199.232.208.194
*   Trying 199.232.212.194:443...
* Connected to www.fandom.com (199.232.212.194) port 443
* ALPN: curl offers http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* successfully imported Windows ROOT store
* successfully imported Windows CA store
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.fandom.com:443
* Closing connection
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.fandom.com:443

Очередной раз озвучу простую мысль: плевать на "новые протоколы" и вот это вот всё.
Сейчас включение проверки защищённого трафика требует муторной работы с исключениями.
Поэтому, раз уж исключения всё равно необходимы, то делаться они должны в автоматическом режиме: подключились к серверу в режиме перехвата и, если не нашли совместимых вариантов - подключились ещё раз, но без перехвата. Как это сделано в Chromium-ГОСТ.

Если бы можно было настроить так, чтобы приложения в данном контексте доверяли сертификату от доктора, но не доверяли другим сертификатам...

Около года назад добавлял системное хранилище и в собственное хранилище Seamonkey сертификаты Минцифры.

И, что характерно, в обоих этих хранилищах имелись сертификаты десятков УЦ о добросовестности которых лично у меня не имеется сведений. В одном случае я вынужден доверять компании MicroSoft, в другом - компании Mozilla.

Имеете в виду извлечение ключей из памяти на лету?

Нет, конечно. У хрома, насколько я знаю, есть режим, при котором ключи "сбрасываются" через специальный канал (pipe).

Второй вариант - "доверенный локальный прокси", который бы работал с шифрованным трафиком, оставляя "в расшифровке" для браузера только сведения о сертификатах. Аналог криптоакселераторов в инфраструктуре веб-серверов: "фронт" расшировывает, "бэк" работает с "чистым" http.

Ещё раз повторяю для людей, имеющих эквивалентную Вашей квалификацию - использование своего сертификата посередине между источником и получателем информации является нарушением секурности.

И честь и хвала тем ресурсам, которые борются с этим.

В данном конкретном вопросе - категорически несогласен.

Невозможно "бороться с MiTM" не имея стороннего канала, связывающего доменное имя с конкретным сертификатом (сервера) или удостоверяющим центром. Такие каналы имеются, но не в этом суть. Если я доверяю антивирусу защиту информации, то почему, собственно, я не доверяю сертификатам, которые выдаёт этот антивирус для сугубо ограниченных целей? Тут можно оценивать надёжность конкретной схемы выдачи таких сертификатов, но это требует квалификации, выходящей за рамки "обычной" для квалифицированных айтишников.

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

Чтобы понимать, какие деньги крутятся в этом бизнесе - достаточно вспомнить о капитализации гугла и периодических (регулярных) инцидентах взлома отдельных серверов или целых сегментов инфраструктуры.

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

P.S.

Мне, конечно, хотелось бы менее ресурсоёмкого механизма, чем "перешифровка" и, в принципе, такой механизм имеется, но не является ни распространённым ни общепринятым.

Молодцы указанные Вами ресурсы, борются с атакой типа MITM.

Побольше бы таких.

Тупо форсят (неподдерживаемый) TLSv1.3:

* Connected to www.fandom.com (199.232.208.194) port 443
* ALPN: curl offers http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / [blank] / UNDEF

С чего вы взяли, что "тот же самый", если у них, наверняка, разные настройки???

Никто, но для того что бы вернутся на релиз, придется удалять/использовать dr web remover, т.е. чистить от настроек.

Вы бета-тестер или где? Бета-версия может фризить, BSOD-ить и делать массу (не)мелких неприятностей.

Можно было бы сделать для домашних пользователей и продуктов DR WEB Security Space на Windows, канал обновления бета, в самом продукте.

Никто не запрещает вам установить бету и зарегистрировать её обычным ключом.

Зачем вы задаёте вопросы, если вам не нравятся ответы?

Раз уж вы сами всё решили, то сами действуйте дальше.

Долго работал в госконторах и как-то не помню технических проблем установить не то, что "на верхах решают", а то, что актуально.

Хотя, конечно, аттестованные рабочие места и сертифицированное ПО - отдельная песня.

Если "у меня взломанный роутер, допустим операционная система вся взломана, и взломана прошивка на роутере", то проще напрямую атаковать устройство, выходящее в Интернет, не ограничиваясь подменой DNS.

P.S.

Поздно, доктор, пить боржоми, когда почки отлетели.

09 воспринимается как восьмеричное?

В отдел кадров?

Проверка защищённого трафика может блокировать доступ тех или иных приложений к тем или иным ресурсам.

Когда это происходит надо исключать из проверки конкретный ресурс для конкретного приложения.

А Thunderbird надо настроить по его справке.

Ну или натренировать встроенный спам-фильтр.

Подскажите как настроить правильно антиспам доктор веб

"Файлы и сеть", "Проверка электронной почты", Параметры Антиспама - в конце есть разделы "Обработка писем спам-фильтром" и "Исправление ошибок распознавания". Первый используется для настройки фильтрации спама в почтовой программе.
Разумеется, всё это есть и во встроенной справке, доступной из агента по клавише F1.

P.S.

Без включения проверки защищённого трафика, в современных реалиях, это всё почти не работает.

Включение проверки защищённого трафика потребует (ежегодного) импорта сертификата Dr.Web в Thunderbird/Firefox и настройки некоторых других исключений.

Ну или можно совсем исключить конкретное приложение (браузер) из проверки защищённого трафика.

Первый (ваш) скриншот - "Поддержка". Будет информация о дате/времени последней проверки обновлений.

Кнопка "Подробнее" (там же) - список программных модулей и баз.

В исключения внести - вообще никак?

а посылаете людей "в пешее эротическое путешствие". Это как-то не нормально по отношению к тем кто вам деньги платит за лицензию.

Если вы, вдруг, не в курсе, то "пешее эротическое" - это был я. Я точно такой же пользователь как и вы и точно так же "деньги платит за лицензию". Последние годы даже в бета-тестировании никак не участвую.

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

Если пользователей волнуют чиселки в наименовании, то самый правильный вариант - отправить их в пешее эротическое путешствие - всё равно не успокоются и будут ныть, какие бы чиселки не рисовались.

Когда-то сертификат был на конкретную версию, потому при выходе следующей нужна была сертификация с нуля, потом убрали из сертификата упоминание версии – каждая следующая версия проходила только через инспекционный контроль, а не сертификацию с нуля.

Всё равно плохо выпускать "регулярные новые версии": если надо внести существенные изменения, то это придётся или делать в рамках текущей версии или "нарушать распорядок", а при выпуске новой - придётся "высасывать из пальца" новшества, которые будут "оправдывать" её появление

Насколько я понимаю, "rolling release" вы замумукаетесь сертифицировать.

Использовать Enterprise Suite или что?

"При переходе по таким ссылкам" необязательно что-нибудь красть - гораздо проще подписать очередного халявщика на какую-нибудь платную услугу.