LINUX.ORG.RU
Новости — Red Hat  

В Fedora Linux 39 планируют по умолчанию отключить поддержку подписей на основе SHA-1

 


1

1

Разработчики проекта Fedora наметили план отключения поддержки цифровых подписей на основе алгоритма SHA-1 в Fedora Linux 39. Отключение предполагает прекращение доверия к подписям, в которых используются хэши SHA-1 (в качестве минимально поддерживаемого в цифровых подписях будет заявлен SHA-224), но сохранение поддержки HMAC с SHA-1 и предоставлении возможности включить LEGACY-профиль с SHA-1. После применения изменений библиотека OpenSSL по умолчанию начнёт блокировать генерацию и проверку подписей с SHA-1.

Отключение планируется провести в несколько этапов: В Fedora Linux 36 подписи на основе SHA-1 будут исключены из политики «FUTURE», предоставлена тестовая политика TEST-FEDORA39 для отключения SHA-1 по желанию пользователя (update-crypto-policies –set TEST-FEDORA39), при создании и верификации подписей на основе SHA-1 в логе будут отображаться предупреждения. В процессе подготовки выпуска Fedora Linux 38 до формирования бета-версии в репозитории rawhide будет применена политика, запрещающая использование подписей на основе SHA-1, но в бета-выпуске и релизе Fedora Linux 38 это изменение применяться не будет. В выпуске Fedora Linux 39 политика с прекращением поддержки подписей на основе SHA-1 будет применена по умолчанию.

Предложенный план пока не рассмотрен комитетом FESCo (Fedora Engineering Steering Committee), отвечающим за техническую часть разработки дистрибутива Fedora. Прекращение поддержки подписей на основе SHA-1 обусловлено повышением эффективности коллизионных атак с заданным префиксом (стоимость подбора коллизии оценивается в несколько десятков тысяч долларов). В браузерах сертификаты, заверенные с использованием алгоритма SHA-1, помечаются как незащищённые с середины 2016 года.

>>> Подробности на сайте Fedora



Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 1)

 ← 1 2 →
Ответ на: комментарий от windows10

И каждый пользователь компьютера обязательно перед тем как зайти на любой сайт в сети проверяет whois после чего nslookup'ом обращается именно к неймсерверу, держащему зону, а не к тому, который получил, например, по dhcp. 

└─> grep -E '^address' /etc/dnsmasq.conf 
address=/microsoft.com/10.20.30.40
└─> nslookup microsoft.com 127.0.0.1
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   microsoft.com
Address: 10.20.30.40

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

… через зашифрованный и свободный от MITM DNS и whois, ага. Построение зашифрованных свободных от MITM DNS и whois оставляется читателю в качестве упражнения.

@windows10, у тебя если действительно есть практически реализуемое решение, как аутентифицировать вторую сторону по незащищенному каналу при условии первого с ней контакта, ты не томи, иди сразу получай медаль Тьюринга и спасай человечество от страдания фигнёй с PKI.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от windows10

Что значит провайдер выдал ?

Провайдер может прозрачно завернуть и ns запросы и http/https трафик и даже whois запросы. Да любой трафик. Неожиданно, да?

qwe ★★★
()
Ответ на: комментарий от shell-script

И каждый пользователь компьютера обязательно перед тем как зайти на любой сайт в сети проверяет whois после чего nslookup'ом обращается именно к неймсерверу, держащему зону, а не к тому, который получил, например, по dhcp.

Клиент!=Человек.

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

windows10 ★★★★★
()
Ответ на: комментарий от t184256

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

В моем примере валидации - аутентификация вообще лишняя. Если цель всей этой мышиной возни - выдать в браузере плашку «not secure» - это можно сделать и проще.

Шаг 1. Ввел в браузер URL;

Шаг 2. Браузер определил IP домена;

Шаг 3. Браузер полез во whois и нашел что домен использует ns1.godaddy.com;

Шаг 4. Браузер считал А-запись с ns1.godaddy.com;

Шаг 5. Если IP с шага 2 не совпадает с IP с шага 4 - выдаем плашку. Если нет - красим все секюрным зелененьким. Если А-записей несколько, то перебираем их все.

windows10 ★★★★★
()
Ответ на: комментарий от windows10

Шаг 2. Выдан левый айпи.

Шаг 3. Запрос к серверу имён от whois перехвачен и выдан адрес подконтрольного нам DNS-сервера, возвращающего тот же левый айпи.

или

Шаг 4. Браузер ищет ns1.godaddy.com, спрашивая у дефолтного DNS-сервера, который наш и отдаёт свой айпишник. Таким образом как и на шаге 2 браузер получает левый айпи.

PROFIT.

shell-script ★★★★★
()
Последнее исправление: shell-script (всего исправлений: 1)
Ответ на: комментарий от windows10

Что такое уязвимый алгоритм, для чего он нужен, и почему он мне не мешает играть в Крузис, смотреть ютубчик и отправлять своего котика девушкам ?

Вот тут запись с первого занятия моего полгодового вводного курса по прикладной криптографии: https://www.youtube.com/watch?v=yrOKSZ6CxtU Можешь послушать и разобраться.

А если не можешь, то не мешай взрослым дядям заниматься делом. Они знают, что творят.

ivlad ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 →
Red Hat