Debian по-прежнему отказывается использовать HTTPS

    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 [verfällt: 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 — скрыть трафик от посторонних глаз (провайдер, государственные службы и другие злоумышленники), чтобы третье лицо не смогло:

    1. Вмешаться в трафик (модифицировать его).
    2. Прослушать трафик (сбор информации, разведка).

    Система 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? (Опрос ниже).



    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Как вы считаете, нужно ли шифровать трафик apt?

    GlobalSign
    174,00
    Компания
    Поделиться публикацией

    Комментарии 43

      +1

      Очень вовремя сегодня опубликовали уязвимость в APT.

        +1
        Вот здесь подробности:
        justi.cz/security/2019/01/22/apt-rce.html
        bugs.launchpad.net/ubuntu/%2Bsource/apt/%2Bbug/1812353

        Там два вектора атаки — MITM и подмена данных на зеркале. От второго https, конечно, не защитил бы. Но от первого — вполне.
          0
          И чем тут поможет https, если MITM может и https сертификат подменить?
            0

            Сертификат по цепочке подписан корневым сертификатом, корневой уже есть локально.

              0
              Корневой сертификат от разработчиков Debian тоже есть локально и это на порядок лучше доверия ко всяким StartCom, раздававшим сертификаты вообще без проверки.
              На эту тему хорошо высказался 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 не вычисляет сумму сам, а верит всему, что ему скажет сервер.
        +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 качать.
          +1
          а этот пакет установлен по умолчанию?
            +1
            https support has been moved into the apt package in 1.5. It can be safely removed.

            Начиная с релиза buster — да, установлен по умолчанию, точнее это уже входит в apt. До этого каждый волен был сам выбирать нужный уровень безопасности. Для особых ценителей даже транспорт tor есть.
              +1
              Установка транспорта по-умолчанию ещё ни о чем не говорит. По опыту, количество людей, которые что-то делают со списком зеркал, исчезающе мало.
              По-умолчанию в sources.list прописаны http-зеркала. Хостеры вроде DO тоже добавляют свои зеркала по http.

              Я буду рад ошибаться, но кажется, что вы нерепрезентативны.
                +8
                Вы разницу между «Debian по-прежнему отказывается использовать HTTPS» и «По-умолчанию Debian использует HTTP» специально игнорируете?
                Если пользователь хочет использовать HTTPS для apt, Debian предоставляет пользователю такую возможность.
                Заголовок и статья предоставляют заведомо недостоверную информацию. И странно видеть это в блоге компании, которая якобы занимается информационной безопасностью.
                  +2
                  Статья статьёй, она действительно написана несколько желтовато.
                  Но самое главное в ней — ссылка на whydoesaptnotusehttps.com за авторством Chris Lamb, откуда все подобные статьи и пошли. Но даже там автор уже написал: надо учитывать, что сайт был сделан до обнародования CVE-2019-3462.
                    +1
                    угу, вот только netinstall не находит сам https зеркала
                    0
                    Любой разработчик или мантейнер, реализующий свое зеркало может тупо не пускать по http, а пускать только по https, и пользователь вынужден будет использовать https-transport. Не вижу проблем
                      –1
                      Любой MITM может перехватить http к этому зеркалу без поддержки http и реализовать свою http-прокси с нужными ему данными.
                        0
                        Читайте внимательно. Владелец репы может отдавать только по https через apt-https-transport, что многие и делают. А дальше встроенные фичи APT-Security, контрольные суммы, подписи, ключи и т.п. Где тут MITM внедрять?
                          0
                          Боюсь, это вы невнимательно читаете. Если владелец репы сделал её доступной только по https никто не мешает кому-то по середине сделать http-proxy со своим содержимым.
                          А про всякие APT-Security и контрольные суммы — посмотрите CVE-2019-3462.
                            0
                            чистый http-proxy подменяющий https трафик? Ничоси у вас фантазии
                              0
                              Вы всё-таки невнимательно читаете. Я нигде про подмену https трафика на 443 порту на http не писал.
                                0
                                Я нигде про подмену https

                                Да? А это что?
                                Любой MITM может перехватить http к этому зеркалу без поддержки http и реализовать свою http-прокси с нужными ему данными.

                                Более того, вы сами написали выше
                                От второго https, конечно, не защитил бы. Но от первого — вполне.

                                То есть https таки защитит от MITM? Ну а для второго надо иметь контроль над зеркалом, не?
                                  0
                                  Да? А это что?

                                  Я попробую ещё раз обьяснить: меняет человек себе зеркало в sources.list. Он может это делать любым способом: через ssh, ikvm или любым другим. Насколько высока вероятность, что он только адрес зеркала поменяет, а протокол как был http — так и оставит?
                                  И даже если хозяин зеркала оставил только https, в APT пиннинга, или HSTS. Никто не гарантирует, что http пакеты по пути до зеркала кто-то не перехватывает.
                                  То есть https таки защитит от MITM? Ну а для второго надо иметь контроль над зеркалом, не?
                                  Защитит ли https от MITM — это тема для отдельной дискуссии. Пока будем считать, что да.
                                    0
                                    Я рассматривал вариант того, что человек добавляет новый репозиторий для установки нужного ему софта (ну пусть это будет nginx/mariadb etc) и строго по инструкции владельца репы, где нет никакого http. Да и со стороны веб сервера никто не запрещает делать принудительный редирект на https, если пришло на http порт
                      0

                      Так потому что базовый уровень обеспечен подписью, остальные (в т.ч. тор) это в т.ч. способ обхода блокировок, хитрых прокси и т.п.).
                      p.s. на волне реклам ipv6 уже приделали приоритет ему по умолчанию без опроса сети (а есть ли реально выход в мир по ipv6) и как итог, статистика поиска в гугле по проблеме "не работает после установки"

                  0
                  Вот только не все официальные зеркала принимают подключения на 443-й порт.
                  Например, security.debian.org и ftp.ru.debian.org по HTTPS не доступны.
                  Можно, конечно, пользоваться deb.debian.org, но у него зачастую доступность оказывается хуже.
                  0

                  Некоторые нехорошие провайдеры умеют вставлять рекламу в HTTP. Поэтому иногда контрольных сумм недостаточно. Ещё эти провайдеры соединения HTTPS/FTP периодически рвут, жизнь — боль.
                  Есть ещё, кажется, метод rsync, но у меня его на raspbian настроить не получилось.

                    +2
                    Они, всё же, не вставляют рекламу в передающиеся файлы произвольного формата, только в html, так что не создают проблемы в этом случае.
                      0

                      rsync вроде хоьели отключить, были громкие заголовки не очень давно вроде.

                      +6
                      Я вот совершенно не понял пассажа про DOH после слов «Если вы подключитесь к зеркалу дистрибутива, будет совершенно очевидно, что вы загружаете обновления.»

                      Вы адрес то зеркала получите секьюрно, но на хост зеркала то все равно пойдете запросами. Толку то что вы скрыли DNS запрос, если после этого пошли на известный по назначению хост?
                        0

                        Теоретически существует возможность скрыть имя хоста при подключении по HTTPS (от видимости IP-адреса уйти, разумеется, нельзя, но при использовании CDN один и тот же IP-адрес может использоваться для множества имён):


                        • В протоколе TLS 1.3, в отличие от предыдущих версий TLS, сертификат сервера передаётся в зашифрованном виде.
                        • Разрабатываемый стандарт Encrypted Server Name Indication for TLS 1.3 позволяет использовать шифрование и для имени сервера, передаваемого клиентом при установке TLS-соединения. С серверной стороны поддержку Encrypted SNI уже внедряет CloudFlare, с клиентской — Mozilla Firefox.
                          0
                          IP вы тоже скроете?
                        +1
                        Да. Я не хочу, чтобы кто-то узнал, что я скачал Tor из репозитория.
                          +1
                          Статья не учитывает зеркала. Вот парочка, работающих через https:


                          Тем более, что обычно зеркала и выбирают, т. к. они могут быстрее работать. Да и сам deb.debian.org, например, может перенаправлять на mirror.yandex.ru.

                          А поддержка в дистрибутиве — пакет apt-transport-https. Кому требуется, может без проблем использовать APT поверх https, на самом деле проблем здесь никаких нет.
                            0
                            > Что думаете вы, нужно ли шифровать трафик apt?

                            1. Безопасность ключей сомнительна, уже написано в статье, что нужно ещё сказать?
                            2. При этом HTTPS убивает кэширование, хотя №1 уже достаточно

                            Если кому-то нужна безопасность, лучше использовать tor и ему подобные чёрные i2p.
                              0
                              1. Поскольку это не «вместо», а «вдобавок к» — хуже не будет.
                              2. Для кэширования пакетов есть apt-cache и т. п., а не странные пляски на уровне HTTP.
                              +1

                              Вообще если совсем включить параноика то можно даже через ssh обновления сделать

                                0
                                Можно через онион сервисы пакеты получать.
                                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
                                  +1
                                  Какие отмазки не придумаешь, чтобы сертификат не ставить.
                                    0
                                    Разве что самоподписаный… Что, впрочем, вполне возможно. Дебиан вполне может установить свой собственный корневой сертификат в дистрибутив.
                                    +5
                                    «провайдер, государственные службы и другие злоумышленники»

                                    Это шедевр ящитаю.
                                      0

                                      Там на самом деле контрольные суммы md5, и они считаются безопасными?..

                                        0
                                        не только md5, там две суммы, md5 и SHA256
                                          0
                                          Если так — то хорошо, в статье об этом ничего нет, показаны только MD5Sum, известные своей криптостойкостью…
                                        +2
                                        Инфраструктура PKI в той форме, в которой она используется для HTTPS — это маркетинговый энтерпрайз головного мозга. Подписей пакетов достаточно, а то, что сейчас для отладки чего-либо на локалхосте нужно втыкать свой CA — уже говорит о зазомбированности большинства потребителей веба. Что дальше потребовать, чтобы дебиан подписывал свои релизы ключом от Microsoft'а, потому что только у них есть своя надежная цифровая подпись? (хотя после маразма с UEFI, Ubuntu и подписью загрузчика — не удивлюсь)
                                          0
                                          существует более 400 CA, которые предлагают сертификаты для любого домена ...

                                          А среди этих центров есть хоть один Российский?

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое