Как использовать https с apt-get?


51

apt-getИспользует ли https или какой-либо другой тип шифрования? Есть ли способ настроить его на использование?


3
Обратите внимание, что из-за таких уязвимостей, как bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467 ..., которые обходят подпись InRelease, вероятно, в любом случае рекомендуется настроить HTTPS.
Ройс Уильямс

whydoesaptnotusehttps.com - это веб-страница, которая точно и подробно отвечает на этот вопрос.
м.райнал

1
Есть более приземленная причина, почему это было бы полезно. Я часто нахожусь в интернет-соединении со сломанным «прозрачным» прокси, который имеет тенденцию блокировать определенные загрузки deb (они, вероятно, вызывают некоторую глупую блокировку вредоносного ПО). Но через https прокси не знает, что я скачиваю, и поэтому не мешает.
Нейт Элдридж

Ответы:


53

apt-get(и другие команды манипулирования пакетами, которые являются интерфейсом к тем же библиотекам APT) могут использовать HTTP, HTTPS и FTP (и смонтированные файловые системы). Если вы укажете https://URL-адреса в /etc/apt/sources.listи /etc/apt/sources.list.d/*, то APT будет использовать HTTPS.

APT проверяет подпись пакетов. Таким образом, вам не нужно иметь форму транспортировки, которая обеспечивает аутентификацию данных. Если злоумышленник изменяет загружаемые вами файлы, это будет замечено. Использование проверки подписи лучше, чем использование HTTPS-соединения, потому что оно обнаружит атаку на сервер, с которого вы скачиваете, а не только транзитную атаку.

Точнее говоря, (упрощенный) поток данных для пакета выглядит следующим образом:

  1. Пакет производится на сборочном станке.
  2. Пакет подписан на сборочной машине.
  3. Подписанный пакет копируется в зеркало загрузки.
  4. Вы скачиваете пакет.

HTTPS гарантирует, что шаг 4 происходит правильно. Подписи пакета гарантируют, что шаги 2-4 выполнены правильно.

На самом деле, для шага 4 HTTPS имеет одно небольшое преимущество: подписи пакета гарантируют только подлинность пакета. Злоумышленник на шаге 4 может выдать себя за законный сервер и обслуживать устаревшие версии пакета. Например, злоумышленник может помешать вам загрузить любые обновления безопасности в надежде использовать уязвимость на вашем компьютере, которую вы бы исправили, если бы не атака. Это не очень реалистичный сценарий, потому что он требует активного злоумышленника (так что это должен быть кто-то, кто контролирует ваше интернет-соединение), но это может произойти в принципе.

Другое преимущество HTTPS будет в том случае, если вы пытаетесь скрыть тот факт, что вы загружаете пакеты Ubuntu от кого-то, кто отслеживает ваше сетевое соединение. Даже тогда подслушиватель мог видеть, к какому хосту вы подключаетесь; если вы подключаетесь к зеркалу Ubuntu и загружаете сотни мегабайт, становится ясно, что вы загружаете пакеты Ubuntu. Подслушиватель может также определить, какие пакеты вы скачиваете, по размеру файлов. Поэтому HTTPS будет полезен, только если вы скачиваете с сервера, который также предлагает другие файлы аналогичного размера - я не вижу никакого смысла, кроме сторонних пакетов, и только в очень необычных обстоятельствах.

Повторим еще раз: обычное преимущество HTTPS, заключающееся в том, что вы знаете, что подключены к реальному серверу, бесполезно при загрузке пакетов Ubuntu. Проверка подписи на пакетах дает более надежную гарантию, чем то, что может обеспечить HTTPS.


11
Дело не в том, что это менее безопасно, а в том, что это менее важно для того, что вы пытаетесь защитить. С APT, шифровать содержимое вашей сделки не так уж важно, потому что вы скачиваете очень бесспорный: это просто те же пакеты Ubuntu , что много людей скачать. Но что важно, так это убедиться, что файлы, которые вы получаете, не были подделаны.
Томасруттер

3
Несколько недель назад я пытался изменить источник на https, и он просто не работал, apt-get updateсообщал об ошибке при попытке получить доступ к ссылкам. С ppas: то же самое. Кто-нибудь пробовал это?
Страпаковски

8
Репозиторий (сервер обновлений) должен поддерживать https / SSL, чтобы это работало. Основное archive.ubuntu.com нет . Вы можете проверить в вашем браузере , если сервер поддерживает это предваряя https: // в URL и увидеть , если вы получите список каталогов и т.д.
иш

7
«Злоумышленник на шаге 4 может выдать себя за законный сервер и обслуживать устаревшие версии пакета». На самом деле, мы защищаемся от этого, предоставляя информацию о пакете срок годности. APT предупредит после этой даты, что ваше зеркало устарело.
Паутина

4
Вот список всех 15 зеркал, которые поддерживают HTTPS вместе со скриптом, который генерирует список: pastebin.com/QY2TQ1dq
Shnatsel

13

С APT, как правило, важнее не то, что ваше соединение зашифровано, а то, что файлы, которые вы получаете, не были подделаны.

APT имеет встроенную проверку подписи, чтобы гарантировать это.

Шифрование будет препятствовать перехватчикам от того, чтобы видеть то, что вы скачиваете, но то, что вы на самом деле загрузки (и запрос) довольно бесспорное: это будет таким же, как и тысячи других пользователей Ubuntu скачивают и файлы не содержат ничего, что ISN» т свободно доступны на многих серверах. Тем не менее, если вам нужна конфиденциальность относительно того, какие пакеты, в частности, вы загружаете, можно использовать HTTPS (укажите это в вашем sources.list).

Проверка подписи, встроенная в APT, гарантирует, что полученные вами файлы не были подделаны. На самом деле не имеет значения, откуда берутся файлы, и даже можно иметь прокси или обратные прокси между вами и сервером, чтобы снизить нагрузку на сервер или ускорить работу. Проверка подписи по-прежнему гарантирует, что вы получаете неизмененный файл, сопоставляя подпись, которую можно криптографически создать только с исходным файлом и копией закрытого ключа Ubuntu.

Если вы переключитесь на HTTPS, вы больше не сможете использовать прокси-серверы для ускорения доступа или снижения нагрузки. И это не добавило бы больше уверенности в том, что APT не проверяет подпись. Однако это будет означать, что перехватчики (такие как ваш интернет-провайдер) не смогут увидеть, какие пакеты вы загружаете (что вряд ли будет конфиденциальным, и, как указал Жиль, они могут догадаться по размеру файла).


3
HTTPS не даст много конфиденциальности, потому что размер файлов виден. На самом деле HTTPS имеет небольшое преимущество, заключающееся в том, что он гарантирует, что злоумышленник, контролирующий ваше сетевое соединение, не сможет незаметно вставить устаревшие данные. Это немного надумано.
Жиль "ТАК ... перестать быть злым"

6
Хорошие моменты. Под «устаревшими данными» я полагаю, вы подразумеваете, что посредник настраивает версию зеркала Ubuntu, состоящего из немного более ранних версий, но все еще неизменную из того, что Ubuntu подписал в то время.
Томасруттер

5
Да это оно. Не стесняйтесь указывать, если я немного раздражительный - я должен помнить, что это Ask Ubuntu, а не Information Security .
Жиль "ТАК - перестань быть злым"

Кажется, в apt есть большая дыра - когда вы apt updateи кто-то посередине кормите фиктивных индексов, apt с радостью берет все, что дает вам человек в середине, и записывает это в / var / lib / apt / lists. Это не просто злой человек посередине, а, например, если вы находитесь в отеле WiFi и будете перенаправлены на страницу входа, если вы запустили apt updateдо входа в систему, ваши / var / lib / apt / lists будут выброшены с домашней страницы отеля HTML. BOGUS! В любом случае базовая проверка сертификата TLS немедленно исключит это.
Мариус

@Marius это не должно быть возможно из-за проверки, которая охватывает списки, а также пакеты. Если вы воспроизвели это со стандартной установкой Apt, вы должны сообщить об этом сопровождающему.
Томасруттер

1

В последних версиях APT встроена поддержка TLS, поэтому вам просто нужно заменить зеркальные URL-адреса хранилища пакетов на httpsпрефиксные. Для Debian это может выглядеть так:

deb https://deb.debian.org/debian/ stretch main
deb https://deb.debian.org/debian-security stretch/updates main
deb https://deb.debian.org/debian/ stretch-updates main

Это полезно, даже несмотря на то, что APT включает собственный протокол подписи, чтобы гарантировать, что пакеты не подделаны, потому что в APT могут быть ошибки (как это было: CVE-2016-1252 , CVE-2019-3462 ). Протоколы HTTP / TLS и их шифры подвергаются тщательному анализу, поэтому серьезная уязвимость нулевого дня гораздо менее вероятна, если вы добавите этот уровень безопасности.


Ой, я только сейчас понимаю, что этот сайт - Ask Ubuntu. :) Я не смог найти подобное решение CDN для Ubuntu.
Лейф Арне Сторсет

0

Я думаю, что этот вопрос может использовать ответ с инструкциями для непрофессионала, так что ...

APT по-прежнему не использует HTTPS по умолчанию в ежедневных сборках Ubuntu 19.10 (Eoan) (который все еще находится в разработке). В этом можно убедиться, изучив файл /etc/apt/sources.list и отметив, что все исходные URL-адреса используют схему URL-адресов "http:".

Чтобы настроить его для использования HTTPS, можно выполнить следующие инструкции:

Во-первых , найдите заслуживающее доверия официальное архивное зеркало Ubuntu, поддерживающее HTTPS:

  1. Перейдите на официальную веб-страницу « Зеркала для Ubuntu» .
  2. В таблице на этой веб-странице укажите зеркала, которые (A) размещены на веб-сайтах, которые вы считаете заслуживающими доверия, (B) имеют зеркало «http:» и, необязательно, (C) соответствуют вашей географической близости, скорости сервера и обновлениям предпочтения свежести.
  3. В таблице на этой веб-странице щелкните ссылку «http» зеркала, указанного на шаге (2), чтобы перейти к версии «http:» зеркала.
  4. В адресной строке браузера вручную измените «http:» в URL веб-страницы на «https:».
  5. Снова перейдите к зеркалу (через URL-адрес «https:»), чтобы увидеть, разрешается ли оно.

Например, я считаю фонд Викимедиа заслуживающим доверия, поэтому я посетил http://mirrors.wikimedia.org/ubuntu/ mirror URL и впоследствии изменил его на https://mirrors.wikimedia.org/ubuntu/ , который успешно разрешается.

Если вы используете Firefox (67.0.4) и у вас установлено расширение HTTPS Everywhere (2019.6.27) с включенной функцией «Зашифровать все сайты, подходящие» (через панель кнопок панели инструментов), шаги (4) и (5) можно пропустить потому что расширение будет автоматически изменять URL-адрес для использования HTTPS, что позволяет сразу же определить, будет ли разрешена версия URL-адреса «https:».

Два , обновить APT список источников:

  1. Выполните команду sudo cp /etc/apt/sources.list /etc/apt/sources.list.backupдля резервного копирования списка источников обновлений.
  2. Замените базовый URL-адрес зеркала, показанный здесь как https://mirrors.wikimedia.org, в команде sudo sed --in-place --regexp-extended 's http://(us\.archive\.ubuntu\.com|security\.ubuntu\.com) https://mirrors.wikimedia.org g' /etc/apt/sources.listна базовый URL-адрес зеркала предпочитаемого зеркала, а затем выполните команду.

В-третьих , вы должны проверить содержимое каталога /etc/apt/sources.list.d/ для источников «http:», которые могут быть изменены на «https:» после установки программного обеспечения вне архива Ubuntu.

Например, пакет Microsoft Visual Studio Code добавляет в этот каталог файл vscode.list, в котором указан URL-адрес «http:». Простое изменение схемы URL-адреса с «http:» на «https:» позволяет выполнять обновления через HTTPS.

Подумайте о резервном копировании любых таких исходных файлов перед их изменением.

Наконец , выполните обновление, чтобы убедиться, что обновления будут работать правильно:

  1. Выполните sudo apt-get updateкоманду.
  2. Если это не сработает должным образом, восстановите файл (ы) списка источников резервных копий, которые вы создали, выполнив sudo cp /etc/apt/sources.list.backup /etc/apt/sources.listкоманду.

Также стоит отметить, что есть пакет apt-transport-https для добавления поддержки HTTPS в APT. Тем не менее, этот пакет, по-видимому, не нужен в соответствии с веб-страницей https://launchpad.net/ubuntu/eoan/+package/apt-transport-https и не требовался начиная с APT 1.5 в соответствии с информацией, показанной после выполнения команды apt-cache show apt-transport-https.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.