Комментарии 43
Очень вовремя сегодня опубликовали уязвимость в APT.
Вот здесь подробности:
justi.cz/security/2019/01/22/apt-rce.html
bugs.launchpad.net/ubuntu/%2Bsource/apt/%2Bbug/1812353
Там два вектора атаки — MITM и подмена данных на зеркале. От второго https, конечно, не защитил бы. Но от первого — вполне.
justi.cz/security/2019/01/22/apt-rce.html
bugs.launchpad.net/ubuntu/%2Bsource/apt/%2Bbug/1812353
Там два вектора атаки — MITM и подмена данных на зеркале. От второго https, конечно, не защитил бы. Но от первого — вполне.
И чем тут поможет https, если MITM может и https сертификат подменить?
Сертификат по цепочке подписан корневым сертификатом, корневой уже есть локально.
Корневой сертификат от разработчиков Debian тоже есть локально и это на порядок лучше доверия ко всяким StartCom, раздававшим сертификаты вообще без проверки.
На эту тему хорошо высказался Christoph Anton Mitterer (calestyo):
Если завязываться исключительно на https, то есть два простых направления атаки: (а) найти продажный УЦ — казахстанский национальный УЦ и многие другие, по просьбе спецслужб, выпишут (и не раз выписывали) сертификат хоть на google.com (б) банальный взлом сайта или ftp. И все будут радостно качать инфицированные файлы по https.
Сейчас, чтобы подписать инфицированные файлы, нужно взломать три машины ключевых разработчиков, а они голой попой в интернет не светят. Как ни крути, а упражнение на два — три порядка более сложное.
Для приведённых FFiX дыр вообще нет разницы между http и https — в обоих случаях apt наивно верил ответам сервера:
1) Поменялось имя (даже не имя, а путь сохранения) запрошенного файла? Ладно, сохраним под другим.
2) Если в URL был закодированный перенос строки и левые заголовки после него, то после декодирования левые заголовки не отбрасывались, а вставлялись перед нормальными.
Надеюсь там просто кривое описание, иначе выходит, что apt не вычисляет сумму сам, а верит всему, что ему скажет сервер.
На эту тему хорошо высказался Christoph Anton Mitterer (calestyo):
150 root CAs alone in the mozilla bundle (many of them which cannot be trusted per se by any sane person)
Если завязываться исключительно на https, то есть два простых направления атаки: (а) найти продажный УЦ — казахстанский национальный УЦ и многие другие, по просьбе спецслужб, выпишут (и не раз выписывали) сертификат хоть на google.com (б) банальный взлом сайта или ftp. И все будут радостно качать инфицированные файлы по https.
Сейчас, чтобы подписать инфицированные файлы, нужно взломать три машины ключевых разработчиков, а они голой попой в интернет не светят. Как ни крути, а упражнение на два — три порядка более сложное.
Для приведённых FFiX дыр вообще нет разницы между http и https — в обоих случаях apt наивно верил ответам сервера:
1) Поменялось имя (даже не имя, а путь сохранения) запрошенного файла? Ладно, сохраним под другим.
2) Если в URL был закодированный перенос строки и левые заголовки после него, то после декодирования левые заголовки не отбрасывались, а вставлялись перед нормальными.
Надеюсь там просто кривое описание, иначе выходит, что apt не вычисляет сумму сам, а верит всему, что ему скажет сервер.
Да боже ж мой. Казалось бы все открыто, все есть в манах. Но нет, надо заголовок пожелтее и растрезвонить как можно громче. Все равно ведь никто проверять не пойдет. Ведь так?
apt-transport-https
Список файлов пакета apt в sid для архитектуры amd64
Плохой, негодный этот debian, не дает ничего по https качать.
apt-transport-https
This is a dummy transitional package — https support has been moved into the apt package in 1.5. It can be safely removed.
Список файлов пакета apt в sid для архитектуры amd64
/usr/lib/apt/methods/https
man sources.listhttps (apt-transport-https(1))
The https scheme specifies an HTTPS server for an archive and is very similar in use and available options to the http scheme. The main difference is that the communication between apt and server (or proxy) is encrypted. Note that the encryption does not prevent an attacker from knowing which server (or proxy) apt is communicating with and deeper analysis can potentially still reveal which data was downloaded. If this is a concern the Tor-based schemes mentioned further below might be a suitable alternative.
Плохой, негодный этот debian, не дает ничего по https качать.
а этот пакет установлен по умолчанию?
https support has been moved into the apt package in 1.5. It can be safely removed.
Начиная с релиза buster — да, установлен по умолчанию, точнее это уже входит в apt. До этого каждый волен был сам выбирать нужный уровень безопасности. Для особых ценителей даже транспорт tor есть.
Установка транспорта по-умолчанию ещё ни о чем не говорит. По опыту, количество людей, которые что-то делают со списком зеркал, исчезающе мало.
По-умолчанию в sources.list прописаны http-зеркала. Хостеры вроде DO тоже добавляют свои зеркала по http.
Я буду рад ошибаться, но кажется, что вы нерепрезентативны.
По-умолчанию в sources.list прописаны http-зеркала. Хостеры вроде DO тоже добавляют свои зеркала по http.
Я буду рад ошибаться, но кажется, что вы нерепрезентативны.
Вы разницу между «Debian по-прежнему отказывается использовать HTTPS» и «По-умолчанию Debian использует HTTP» специально игнорируете?
Если пользователь хочет использовать HTTPS для apt, Debian предоставляет пользователю такую возможность.
Заголовок и статья предоставляют заведомо недостоверную информацию. И странно видеть это в блоге компании, которая якобы занимается информационной безопасностью.
Если пользователь хочет использовать HTTPS для apt, Debian предоставляет пользователю такую возможность.
Заголовок и статья предоставляют заведомо недостоверную информацию. И странно видеть это в блоге компании, которая якобы занимается информационной безопасностью.
Статья статьёй, она действительно написана несколько желтовато.
Но самое главное в ней — ссылка на whydoesaptnotusehttps.com за авторством Chris Lamb, откуда все подобные статьи и пошли. Но даже там автор уже написал: надо учитывать, что сайт был сделан до обнародования CVE-2019-3462.
Но самое главное в ней — ссылка на whydoesaptnotusehttps.com за авторством Chris Lamb, откуда все подобные статьи и пошли. Но даже там автор уже написал: надо учитывать, что сайт был сделан до обнародования CVE-2019-3462.
угу, вот только netinstall не находит сам https зеркала
Любой разработчик или мантейнер, реализующий свое зеркало может тупо не пускать по http, а пускать только по https, и пользователь вынужден будет использовать https-transport. Не вижу проблем
Любой MITM может перехватить http к этому зеркалу без поддержки http и реализовать свою http-прокси с нужными ему данными.
Читайте внимательно. Владелец репы может отдавать только по https через apt-https-transport, что многие и делают. А дальше встроенные фичи APT-Security, контрольные суммы, подписи, ключи и т.п. Где тут MITM внедрять?
Боюсь, это вы невнимательно читаете. Если владелец репы сделал её доступной только по https никто не мешает кому-то по середине сделать http-proxy со своим содержимым.
А про всякие APT-Security и контрольные суммы — посмотрите CVE-2019-3462.
А про всякие APT-Security и контрольные суммы — посмотрите CVE-2019-3462.
чистый http-proxy подменяющий https трафик? Ничоси у вас фантазии
Вы всё-таки невнимательно читаете. Я нигде про подмену https трафика на 443 порту на http не писал.
Я нигде про подмену https
Да? А это что?
Любой MITM может перехватить http к этому зеркалу без поддержки http и реализовать свою http-прокси с нужными ему данными.
Более того, вы сами написали выше
От второго https, конечно, не защитил бы. Но от первого — вполне.
То есть https таки защитит от MITM? Ну а для второго надо иметь контроль над зеркалом, не?
Да? А это что?
Я попробую ещё раз обьяснить: меняет человек себе зеркало в sources.list. Он может это делать любым способом: через ssh, ikvm или любым другим. Насколько высока вероятность, что он только адрес зеркала поменяет, а протокол как был http — так и оставит?
И даже если хозяин зеркала оставил только https, в APT пиннинга, или HSTS. Никто не гарантирует, что http пакеты по пути до зеркала кто-то не перехватывает.
То есть https таки защитит от MITM? Ну а для второго надо иметь контроль над зеркалом, не?Защитит ли https от MITM — это тема для отдельной дискуссии. Пока будем считать, что да.
Я рассматривал вариант того, что человек добавляет новый репозиторий для установки нужного ему софта (ну пусть это будет nginx/mariadb etc) и строго по инструкции владельца репы, где нет никакого http. Да и со стороны веб сервера никто не запрещает делать принудительный редирект на https, если пришло на http порт
Так потому что базовый уровень обеспечен подписью, остальные (в т.ч. тор) это в т.ч. способ обхода блокировок, хитрых прокси и т.п.).
p.s. на волне реклам ipv6 уже приделали приоритет ему по умолчанию без опроса сети (а есть ли реально выход в мир по ipv6) и как итог, статистика поиска в гугле по проблеме "не работает после установки"
Вот только не все официальные зеркала принимают подключения на 443-й порт.
Например, security.debian.org и ftp.ru.debian.org по HTTPS не доступны.
Можно, конечно, пользоваться deb.debian.org, но у него зачастую доступность оказывается хуже.
Например, security.debian.org и ftp.ru.debian.org по HTTPS не доступны.
Можно, конечно, пользоваться deb.debian.org, но у него зачастую доступность оказывается хуже.
Некоторые нехорошие провайдеры умеют вставлять рекламу в HTTP. Поэтому иногда контрольных сумм недостаточно. Ещё эти провайдеры соединения HTTPS/FTP периодически рвут, жизнь — боль.
Есть ещё, кажется, метод rsync, но у меня его на raspbian настроить не получилось.
Я вот совершенно не понял пассажа про DOH после слов «Если вы подключитесь к зеркалу дистрибутива, будет совершенно очевидно, что вы загружаете обновления.»
Вы адрес то зеркала получите секьюрно, но на хост зеркала то все равно пойдете запросами. Толку то что вы скрыли DNS запрос, если после этого пошли на известный по назначению хост?
Вы адрес то зеркала получите секьюрно, но на хост зеркала то все равно пойдете запросами. Толку то что вы скрыли DNS запрос, если после этого пошли на известный по назначению хост?
Теоретически существует возможность скрыть имя хоста при подключении по HTTPS (от видимости IP-адреса уйти, разумеется, нельзя, но при использовании CDN один и тот же IP-адрес может использоваться для множества имён):
- В протоколе TLS 1.3, в отличие от предыдущих версий TLS, сертификат сервера передаётся в зашифрованном виде.
- Разрабатываемый стандарт Encrypted Server Name Indication for TLS 1.3 позволяет использовать шифрование и для имени сервера, передаваемого клиентом при установке TLS-соединения. С серверной стороны поддержку Encrypted SNI уже внедряет CloudFlare, с клиентской — Mozilla Firefox.
Да. Я не хочу, чтобы кто-то узнал, что я скачал Tor из репозитория.
Статья не учитывает зеркала. Вот парочка, работающих через https:
Тем более, что обычно зеркала и выбирают, т. к. они могут быстрее работать. Да и сам deb.debian.org, например, может перенаправлять на mirror.yandex.ru.
А поддержка в дистрибутиве — пакет apt-transport-https. Кому требуется, может без проблем использовать APT поверх https, на самом деле проблем здесь никаких нет.
Тем более, что обычно зеркала и выбирают, т. к. они могут быстрее работать. Да и сам deb.debian.org, например, может перенаправлять на mirror.yandex.ru.
А поддержка в дистрибутиве — пакет apt-transport-https. Кому требуется, может без проблем использовать APT поверх https, на самом деле проблем здесь никаких нет.
> Что думаете вы, нужно ли шифровать трафик apt?
1. Безопасность ключей сомнительна, уже написано в статье, что нужно ещё сказать?
2. При этом HTTPS убивает кэширование, хотя №1 уже достаточно
Если кому-то нужна безопасность, лучше использовать tor и ему подобные чёрные i2p.
1. Безопасность ключей сомнительна, уже написано в статье, что нужно ещё сказать?
2. При этом HTTPS убивает кэширование, хотя №1 уже достаточно
Если кому-то нужна безопасность, лучше использовать tor и ему подобные чёрные i2p.
Вообще если совсем включить параноика то можно даже через ssh обновления сделать
Можно через онион сервисы пакеты получать.
HOWTO: get all your Debian packages via Tor Onion Services
guardianproject.info/2016/07/31/howto-get-all-your-debian-packages-via-tor-onion-services
Какие отмазки не придумаешь, чтобы сертификат не ставить.
«провайдер, государственные службы и другие злоумышленники»
Это шедевр ящитаю.
Это шедевр ящитаю.
Там на самом деле контрольные суммы md5, и они считаются безопасными?..
Инфраструктура PKI в той форме, в которой она используется для HTTPS — это маркетинговый энтерпрайз головного мозга. Подписей пакетов достаточно, а то, что сейчас для отладки чего-либо на локалхосте нужно втыкать свой CA — уже говорит о зазомбированности большинства потребителей веба. Что дальше потребовать, чтобы дебиан подписывал свои релизы ключом от Microsoft'а, потому что только у них есть своя надежная цифровая подпись? (хотя после маразма с UEFI, Ubuntu и подписью загрузчика — не удивлюсь)
существует более 400 CA, которые предлагают сертификаты для любого домена ...
А среди этих центров есть хоть один Российский?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Debian по-прежнему отказывается использовать HTTPS