MITM и сертификатыWed Oct 25 14:45:14 2023 UTC К вопросу о том, как все эти криптографические сертификаты «помогают» против Man-in-the-Middle attack: http://notes.valdikss.org.ru/jabber.ru-mitm/ По-моему, это всё, что нужно знать про TLS/SSL, certificate authorities, HTTPS (несмотря на то, что в этой конкретной истории он не задействован) и прочее криптобесие. 
|
пояснениеВы находитесь на официальном сайте Андрея Викторовича Столярова, автора учебных пособий по программированию и информационным технологиям. Если вы искали сайт замечательного писателя-фантаста Андрея Михайловича Столярова, то вам, к сожалению, не сюда. Андрей Михайлович Столяров в библиотеке Мошкова |
☞ From Anonymous (Michael) (unverified) Thu Oct 26 09:16:41 2023 UTC
Какие задачи решают сертификаты
С одной стороны, действительно криптобесие и дурно пахнущее навязывание. Простой FTP убрали из браузеров. Хром в новейших версиях вообще позволяет себе по каким-то причинам блокировать скачивание или даже скачать и тут же удалить файл, если решит, что он из недоверенного источника получен.
Но можно и так на это посмотреть, что чьим-то спецслужбам, чтобы сунуть нос в чужую переписку пришлось принудить хостеров или вербовать там админов. И то это все-таки вскрылось (хотя и из-за ошибки атакующего), а если бы админы были несколько внимательнее и параноистее, то может и сразу не получилось бы. С задачей же не пустить туда нос своего локального провайдера или слишком любопытного соседа по подъезду и вовсе без проблем.
ответить
Re: Какие задачи решают сертификаты
Но можно и так на это посмотреть,
Нет, нельзя на это так смотреть. Чтобы кто-то куда-то не совал свой нос, нужно криптографию использовать осознанно и явно, например, PGP/GPG применять, поднимать VPN'ы и т.д. То, что происходит сейчас, даёт чувство ложной безопасности, которое крайне вредно. И в любом случае махровый идиотизм самой идеи централизованных "доверенных" CA остаётся махровым идиотизмом, как на него ни смотри.
ответить
☞ From Anonymous (unverified) Thu Oct 26 05:19:39 2023 UTC
Сертификаты
Вспомнил ещё одну статью того же автора. Несколько лет назад он насобирал целую коллекцию подписанных доверенными (которым Microsoft доверяет) ключами UEFI Secure Boot дырявых модулей для GRUB, позволяющих устроить цепочку Shim->GRUB->неподписанный_файл.efi.
И ведь только часть сертификатов была отозвана (сам он назвал не все, которые нашёл, да и другие предпочитают молчать об этом), и только часть старых компьютеров получила обновление dbx (список отозванных сертификатов). Совершенно точно некоторые загрузочные флешки, позволяющие обойти Secure Boot, всё ещё работают. Что в очередной раз доказывает, что дырява сама идея о "цепочке доверия". Если уж использовать сертификаты, то проверять, что это именно конкретный сертификат, а не что он куда-то там ведёт по цепочке доверия.
ответить
Re: Сертификаты
Авторов идеи secure boot следовало бы публично казнить каким-нибудь нетривиальным способом, лично я в таких случаях голосую за утопление в бочке с дерьмом. Нехер совать что попало в комп, вот и вся безопасность, а всё это бутявочное криптобесие в действительности имеет лишь одну цель — вставить как можно больше палок в колёса независимых разработчиков.
ответить
Re: Re: Сертификаты
Secureboot пример гнусно мерзопакостно извращенной идеи. В результате из идеи контроля пользователя за своей машиной получилось на практике прямо обратное - отбирание контроля, благо что все еще редко на каких компьютерах. Первоначальный смысл был защититься не от бутвирусов даже, а от подмены загрузчика в отсутствие хозяина. Например, чтобы собрать пароли к зашифрованному содержимому. Если бы а) всегда и абсолютно добровольно можно было бы вкл/выкл SB б) Можно было бы легко в BIOS редактировать список ключей, в том числе просто одним нажатием кнопки подписать уже стоящий загрузчик (возможно самим написанный) и выкинуть лишние ключи, если они были. Теоретически и сейчас можно самому под себя отредактировать, но это предельно усложнено и есть риск по неосторожности окирпичить устройство и похоже не везде реализовано.
ответить
Re: Re: Re: Сертификаты
Ни разу у меня не возникало проблем с Secure Boot.
Спецификация явным образом требует, чтобы прошивка предоставляла пользователю компьютера общего назначения возможность как отредактировать базу данных сертификатов, так и полностью отключить Secure Boot. Если где-то это не так или приводит к окирпичиванию, то это ошибка реализации.
Свой загрузчик я подписывал одним запуском sbsigntool, на десятке платформ это без проблем работало.
Первоначальный смысл был в облегчении обслуживания большого числа машин. Для защиты прошивки и диска от вирусов можно было бы сделать гораздо более простое решение - неотключаемую без физического присутствия защиту от записи, как это было во времена BIOS (называлось "Anti-Virus Protection" у AWARD).
Secure Boot же даёт более гибкий механизм вместо полного запрета - у владельца платформы нет необходимости вручную снимать защиту, обновлять ОС и ставить защиту обратно, теперь можно просто централизованно подписать новую версию.
ответить
Re: Сертификаты
> это ошибка реализации
Те, кто этот жирный косяк допускают, обычно не знают, что это ошибка реализации.
ответить
Re: Re: Сертификаты
Да сам-то Secure Boot ещё куда ни шло, он же почти везде отключаемый и можно поставить Core Boot / Libreboot и тд. А вот Intel boot guard гораздо хуже. Если он включен, то это полностью исключает возможность запуска например Core Boot или любого другого альтернативного загрузчика на компе.
ответить
☞ From gnsf (unverified) Wed Oct 25 17:10:04 2023 UTC
Все настолько плохо?
Погодите, я правильно понял, что если у атакующего есть доступ к хопу, который достаточно близко расположен к серверу, ip которого прописан в атакуемом домене, то атакущий может себе понаделать валидных сертификатов (с помощью того же Let's Ecrypt'а через HTTP-01 challenge) для этого домена? В частности, все VPS-провайдеры могут такое проворачивать, если не предпринять специальные меры, рекомендуемые в конце статьи? Да уж, точно криптобесие.
ответить
Re: Все настолько плохо?
VPS-провайдеры могут гораздо больше, им так извращаться незачем. Система hardware node (она же супервайзер, она же как хотите назовите — в общем система того физического компа, на котором крутятся VPSки) имеет полный и ничем не ограниченный доступ внутрь VPS. В рассматриваемом случае атакующему пришлось так крутиться, потому что арендованная серверная машина была аппаратная, её так просто не вскроешь. Ну, во всяком случае незаметно.
А общий принцип простой: пока вы можете получить сертификат от CA, не приехав физически в офис этой CA и не предъявив там миллион БУМАЖНЫХ документов, то как бы там криптографы ни изворачивались, у них нет и не может быть никаких "дополнительных" способов понять, реально они имеют дело с владельцем домена или нет. Больше того, предварительно нужно ещё заехать (опять же физически) в офис регистратора доменов и там тоже предъявить миллион бумажных документов, и чтобы CA потом спросил этого регистратора по защищённому каналу, точно ли вот этот домен зарегистрирован на такого-то и такого-то.
Поскольку всего этого, очевидно, не будет происходить никогда (хотя бы потому, что большинству хозяев доменов для этого придётся слетать в другое полушарие), все эти пляски с централизованным подписанием сертификатов — заведомая туфта. Толку от неё не то что нет, но и изначально быть не могло, просто потому что волшебных ясновидящих гномиков, как мы понимаем, не бывает.
Зато какое количество геморроя с этими сертификатами — ну, это вы и без меня знаете.
ответить