APT (advanced packaging tool) — программа для установки, обновления и удаления программных пакетов в операционных системах Debian и основанных на них (Ubuntu, Linux Mint и т. п.). Иногда также используется в дистрибутивах, основанных на Mandrake. Пакеты скачиваются по интернету из репозиториев по незащищённому соединению, без использования протокола TLS и шифрования. Возникает вопрос: почему? Разве HTTPS не обеспечивает лучшую безопасность? Debian считает, что HTTPS — лишняя сущность, поскольку система SecureAPT проверяет контрольную сумму для скачанных файлов и криптографическую gpg-подпись всего пакета.Один из разработчиков Debian запустил сайт whydoesaptnotusehttps.com («Почему APT не использует HTTPS»), где объясняет официальную позицию.
Как работает SecureAPT
Во-первых, apt сравнивает хэши файлов из пакета. Они публикуются на сайте Debian в файле Release…
MD5Sum:
6b05b392f792ba5a436d590c129de21f 3453 Packages
1356479a23edda7a69f24eb8d6f4a14b 1131 Packages.gz
2a5167881adc9ad1a8864f281b1eb959 1715 Sources
88de3533bf6e054d1799f8e49b6aed8b 658 Sources.gz…и передаются вместе с пакетом.
Package: uqm
Priority: optional
...
Filename: unstable/uqm_0.4.0-1_i386.deb
Size: 580558
MD5sum: 864ec6157c1eea88acfef44d0f34d219Чтобы защитить файл Release от подделки, система SecureAPT добавляет цифровую подпись gpg, которая находится в файле Release.gpg:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQBCqKO1nukh8wJbxY8RAsfHAJ9hu8oGNRAl2MSmP5+z2RZb6FJ8kACfWvEx
UBGPVc7jbHHsg78EhMBlV/U=
=x6og
-----END PGP SIGNATURE-----Программа apt скачивает файл Release.gpg и проверяет подпись с помощью доверенных публичных ключей, которые хранятся в файле /etc/apt/trusted.gpg. По умолчанию там записан записан публичный ключ архива Debian.
joey@dragon:~>sudo apt-key list
/etc/apt/trusted.gpg
--------------------
pub 4096R/55BE302B 2009-01-27 [verfallt: 2012-12-31]
uid Debian Archive Automatic Signing Key (5.0/lenny) <ftpmaster@debian.org>Это последняя линия защиты, поэтому Debian периодически меняет ключи. Новые ключи распространяются с пакетом debian-archive-keyring, а также публикуются на веб-странице.
После публикации нового публичного ключа происходит ещё одна процедура. Секретный ключ, который использовался для генерации открытого ключа, с помощью программы gfshare делится на пять частей и распределяется между пятью авторитетными разработчиками по схеме разделения секрета Шамира. Чтобы восстановить секрет, как минимум трое из пяти разработчиков должны предоставить свои части секрета. Математическое доказательство схемы Шамира публиковалось на Хабре: оно основано на том, что через две точки на плоскости можно провести неограниченное число полиномов степени 2. Чтобы выбрать из них единственный — нужна третья точка. Проще говоря, схема основана на полиномиальной интерполяции.
Итак, в системе SecureAPT секретный ключ разделён на пять частей и надёжно защищён, криптографическая подпись файла Release проверяется общедоступным публичным ключом, а в этом файле хранятся контрольные суммы файлов из пакета. Зачем же использовать HTTS, если всё так защищено?
Зачем использовать HTTP?
Основная задача HTTPS — скрыть трафик от посторонних глаз (провайдер, государственные службы и другие злоумышленники), чтобы третье лицо не смогло:
- Вмешаться в трафик (модифицировать его).
- Прослушать трафик (сбор информации, разведка).
Система SecureAPT частично защищает от первой угрозы, но не от второй. Поскольку пакеты передаются по открытым каналам, то постороннее лицо видит, какие конкретно пакеты скачиваются и откуда. Злоумышленник может и подменить пакеты и цифровую подпись, но тогда она не пройдёт проверку.
Разработчик Debian пишет:
HTTPS не обеспечивает значимой конфиденциальности для получения пакетов, поскольку злоумышленник обычно видит, с какими хостами вы связываетесь. Если вы подключитесь к зеркалу дистрибутива, будет совершенно очевидно, что вы загружаете обновления.Вероятно, этот абзац написан в те времена, когда браузеры и интернет-сервисы не начали поддерживать технологию DNS over TLS и DNS over HTTPS (DoH) для шифрования DNS-трафика. Например, в апреле 2018 года её внедрил один из крупнейших CDN-провайдеров Cloudfalre, а в октябре 2018 года Google Public DNS тоже включил поддержку DNS over TLS.
Таким образом, после соответствующей настройки системы можно эффективно прятать DNS-запросы от постороннего лица, которое прослушивает трафик. Также идёт активная работа над внедрением других технологий, которые скрывают адресата пакетов. То есть в будущем HTTPS всё-таки сможет обеспечить должную конфиденциальность.
Debian приводит ещё один аргумент: даже на зашифрованном соединении «несложно выяснить, какие файлы скачивает пользователь по размеру трафика». Эту «уязвимость» можно использовать даже при анализе трафика через Tor.
Наконец, Debian не видит причин полностью доверять центрам сертификации: существует более 400 CA, которые предлагают сертификаты для любого домена. У многих плохая репутация, а некоторые напрямую контролируются государством. Сложно определить, какому CA можно доверять.
Таким образом, по мнению Debian, самое главное — гарантировать подлинность файлов в пакете, а не защитить само соединение.
Почему бы не внедрить HTTPS поверх существующего механизма SecureAPT? Разработчик считает это сложной инженерной задачей, которая требует безопасного обмена и хранения секретных ключей. Кроме того, внедрение HTTPS подразумевает «введение в заблуждение пользователей относительно уровня безопасности и конфиденциальности» по причинам, описанным выше.
В 2019 году сознательный отказ от HTTPS выглядит весьма экстравагантно, поэтому позиция Debian вызвала оживлённую дискуссию на Hacker News, где комментаторы выдвинули несколько контраргументов.
Что думаете вы, нужно ли шифровать трафик apt? (Опрос ниже).
Комментарии (37)
skyeff
23.01.2019 11:08+11Да боже ж мой. Казалось бы все открыто, все есть в манах. Но нет, надо заголовок пожелтее и растрезвонить как можно громче. Все равно ведь никто проверять не пойдет. Ведь так?
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.list
https (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 качать.
fkvf
23.01.2019 11:36+1а этот пакет установлен по умолчанию?
skyeff
23.01.2019 11:40+1https support has been moved into the apt package in 1.5. It can be safely removed.
Начиная с релиза buster — да, установлен по умолчанию, точнее это уже входит в apt. До этого каждый волен был сам выбирать нужный уровень безопасности. Для особых ценителей даже транспорт tor есть.FFiX
23.01.2019 12:24+1Установка транспорта по-умолчанию ещё ни о чем не говорит. По опыту, количество людей, которые что-то делают со списком зеркал, исчезающе мало.
По-умолчанию в sources.list прописаны http-зеркала. Хостеры вроде DO тоже добавляют свои зеркала по http.
Я буду рад ошибаться, но кажется, что вы нерепрезентативны.skyeff
23.01.2019 12:47+7Вы разницу между «Debian по-прежнему отказывается использовать HTTPS» и «По-умолчанию Debian использует HTTP» специально игнорируете?
Если пользователь хочет использовать HTTPS для apt, Debian предоставляет пользователю такую возможность.
Заголовок и статья предоставляют заведомо недостоверную информацию. И странно видеть это в блоге компании, которая якобы занимается информационной безопасностью.FFiX
23.01.2019 12:53+2Статья статьёй, она действительно написана несколько желтовато.
Но самое главное в ней — ссылка на whydoesaptnotusehttps.com за авторством Chris Lamb, откуда все подобные статьи и пошли. Но даже там автор уже написал: надо учитывать, что сайт был сделан до обнародования CVE-2019-3462.
NickyX3
23.01.2019 18:34Любой разработчик или мантейнер, реализующий свое зеркало может тупо не пускать по http, а пускать только по https, и пользователь вынужден будет использовать https-transport. Не вижу проблем
FFiX
23.01.2019 22:52-1Любой MITM может перехватить http к этому зеркалу без поддержки http и реализовать свою http-прокси с нужными ему данными.
NickyX3
24.01.2019 08:52Читайте внимательно. Владелец репы может отдавать только по https через apt-https-transport, что многие и делают. А дальше встроенные фичи APT-Security, контрольные суммы, подписи, ключи и т.п. Где тут MITM внедрять?
FFiX
24.01.2019 08:54-1Боюсь, это вы невнимательно читаете. Если владелец репы сделал её доступной только по https никто не мешает кому-то по середине сделать http-proxy со своим содержимым.
А про всякие APT-Security и контрольные суммы — посмотрите CVE-2019-3462.NickyX3
24.01.2019 08:59чистый http-proxy подменяющий https трафик? Ничоси у вас фантазии
FFiX
24.01.2019 09:04-1Вы всё-таки невнимательно читаете. Я нигде про подмену https трафика на 443 порту на http не писал.
NickyX3
24.01.2019 09:07Я нигде про подмену https
Да? А это что?
Любой MITM может перехватить http к этому зеркалу без поддержки http и реализовать свою http-прокси с нужными ему данными.
Более того, вы сами написали выше
От второго https, конечно, не защитил бы. Но от первого — вполне.
То есть https таки защитит от MITM? Ну а для второго надо иметь контроль над зеркалом, не?FFiX
24.01.2019 09:19Да? А это что?
Я попробую ещё раз обьяснить: меняет человек себе зеркало в sources.list. Он может это делать любым способом: через ssh, ikvm или любым другим. Насколько высока вероятность, что он только адрес зеркала поменяет, а протокол как был http — так и оставит?
И даже если хозяин зеркала оставил только https, в APT пиннинга, или HSTS. Никто не гарантирует, что http пакеты по пути до зеркала кто-то не перехватывает.
То есть https таки защитит от MITM? Ну а для второго надо иметь контроль над зеркалом, не?
Защитит ли https от MITM — это тема для отдельной дискуссии. Пока будем считать, что да.NickyX3
24.01.2019 10:25Я рассматривал вариант того, что человек добавляет новый репозиторий для установки нужного ему софта (ну пусть это будет nginx/mariadb etc) и строго по инструкции владельца репы, где нет никакого http. Да и со стороны веб сервера никто не запрещает делать принудительный редирект на https, если пришло на http порт
nikolayv81
26.01.2019 18:23Так потому что базовый уровень обеспечен подписью, остальные (в т.ч. тор) это в т.ч. способ обхода блокировок, хитрых прокси и т.п.).
p.s. на волне реклам ipv6 уже приделали приоритет ему по умолчанию без опроса сети (а есть ли реально выход в мир по ipv6) и как итог, статистика поиска в гугле по проблеме "не работает после установки"
Dukat
24.01.2019 15:35Вот только не все официальные зеркала принимают подключения на 443-й порт.
Например, security.debian.org и ftp.ru.debian.org по HTTPS не доступны.
Можно, конечно, пользоваться deb.debian.org, но у него зачастую доступность оказывается хуже.
Akon32
23.01.2019 11:45Некоторые нехорошие провайдеры умеют вставлять рекламу в HTTP. Поэтому иногда контрольных сумм недостаточно.
Ещё эти провайдеры соединения HTTPS/FTP периодически рвут, жизнь — боль.
Есть ещё, кажется, метод rsync, но у меня его на raspbian настроить не получилось.
kotomyava
23.01.2019 19:07+2Они, всё же, не вставляют рекламу в передающиеся файлы произвольного формата, только в html, так что не создают проблемы в этом случае.
nikolayv81
26.01.2019 18:26rsync вроде хоьели отключить, были громкие заголовки не очень давно вроде.
Sly_tom_cat
23.01.2019 12:31+6Я вот совершенно не понял пассажа про DOH после слов «Если вы подключитесь к зеркалу дистрибутива, будет совершенно очевидно, что вы загружаете обновления.»
Вы адрес то зеркала получите секьюрно, но на хост зеркала то все равно пойдете запросами. Толку то что вы скрыли DNS запрос, если после этого пошли на известный по назначению хост?sigprof
24.01.2019 15:35Теоретически существует возможность скрыть имя хоста при подключении по HTTPS (от видимости IP-адреса уйти, разумеется, нельзя, но при использовании CDN один и тот же IP-адрес может использоваться для множества имён):
- В протоколе TLS 1.3, в отличие от предыдущих версий TLS, сертификат сервера передаётся в зашифрованном виде.
- Разрабатываемый стандарт Encrypted Server Name Indication for TLS 1.3 позволяет использовать шифрование и для имени сервера, передаваемого клиентом при установке TLS-соединения. С серверной стороны поддержку Encrypted SNI уже внедряет CloudFlare, с клиентской — Mozilla Firefox.
c0f04
23.01.2019 19:42+1Статья не учитывает зеркала. Вот парочка, работающих через https:
Тем более, что обычно зеркала и выбирают, т. к. они могут быстрее работать. Да и сам deb.debian.org, например, может перенаправлять на mirror.yandex.ru.
А поддержка в дистрибутиве — пакет apt-transport-https. Кому требуется, может без проблем использовать APT поверх https, на самом деле проблем здесь никаких нет.
sena
23.01.2019 20:29> Что думаете вы, нужно ли шифровать трафик apt?
1. Безопасность ключей сомнительна, уже написано в статье, что нужно ещё сказать?
2. При этом HTTPS убивает кэширование, хотя №1 уже достаточно
Если кому-то нужна безопасность, лучше использовать tor и ему подобные чёрные i2p.
Gorthauer87
23.01.2019 22:38+1Вообще если совсем включить параноика то можно даже через ssh обновления сделать
KonstantinSpb
24.01.2019 00:57Можно через онион сервисы пакеты получать.
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
arthi7471
24.01.2019 17:43+2«провайдер, государственные службы и другие злоумышленники»
Это шедевр ящитаю.
FFiX
Очень вовремя сегодня опубликовали уязвимость в APT.
FFiX
Вот здесь подробности:
justi.cz/security/2019/01/22/apt-rce.html
bugs.launchpad.net/ubuntu/%2Bsource/apt/%2Bbug/1812353
Там два вектора атаки — MITM и подмена данных на зеркале. От второго https, конечно, не защитил бы. Но от первого — вполне.