Чому для програми debian apt не існує транспорту https?

При всій параноїї, яка прийшла з викриттями NSA, і все, мені цікаво, чому механізм встановлення пакунків debian не підтримує HTTPS для його транспортування, не кажучи вже про використання його за замовчуванням.

Я знаю, що пакети Debian мають певну перевірку підписів за допомогою GPG, але все ж я не думаю, що використання транспорту HTTPS замість HTTP було б надто важким, враховуючи, наскільки це важливо для безпеки.

Редагувати: Я в основному хочу захистити себе від атак MitM (включаючи лише нюхання трафіку), а не адміністраторів дзеркальних дзеркал. HTTP-сховища поміщають цілі налаштування системи на стіл, якщо хтось прослуховує мій трафік на дзеркала Debian.

Існує. Вам потрібно встановити пакет apt-transport-https. Тоді ви можете використовувати лінії типу

 deb https://some.server.com/debian stable main

у вашому sources.listфайлі. Але зазвичай це не потрібно, оскільки весь вміст все одно є загальнодоступним, і він додає шифрування накладних витрат та затримки. Оскільки ви не довіряєте відкритому ключу зловмисників, навіть трафік http захищений від атак MitM. aptпопередить вас і не вдасться встановити пакунки, коли зловмисник вводить маніпульовані пакети.

EDIT: Як зазначалося в коментарях, користуватися сховищем TLS дійсно безпечніше . Дослідження показують, що використання apt на незашифрованих сховищах дійсно може становити загрозу безпеці, оскільки транспорт HTTP вразливий для повторних атак.

Ваше припущення неправильне: ви можете використовувати завантаження HTTPS. Вам просто потрібно знайти дзеркало, яке його підтримує, і ввести його URL у свій список джерел. Вам потрібно буде встановити apt-transport-httpsпакет.

Debian не робить завантаження HTTPS простим, оскільки користь дуже мала. Дистрибутив пакунків Debian вже включає механізм перевірки пакетів: усі пакунки підписані Gpg . Якщо активний чоловік-посередині перенаправляє ваш трафік на сервер із пошкодженими пакетами, пошкодження буде виявлено, оскільки підписи GPG не будуть дійсними. Використання GPG, а не HTTPS має перевагу в тому, що він захищає від більшої кількості загроз: не лише від активного "посередника" на з'єднанні з кінцевим користувачем, але також від шахрайства чи зараженого дзеркала чи інших проблем, що перебувають у ланцюзі розповсюдження пакетів. .

HTTPS надає невелику перевагу конфіденційності, оскільки він затінює пакети, які ви завантажуєте. Однак пасивний спостерігач все ще може виявити трафік між вашим комп'ютером та сервером пакетів, тому вони знають, що ви завантажуєте пакети Debian. Вони також можуть добре зрозуміти, які пакунки ви завантажуєте з розмірів файлів.

Єдине місце, де HTTPS допоможе, - це завантаження довіри, щоб отримати відоме дійсне зображення встановлення. Debian, схоже, не передбачає: є контрольні суми інсталяційних носіїв , але лише через HTTP.

Нещодавно я зіткнувся з проблемою з підходящим сховищем моєї компанії. Проблема полягала в тому, що якщо ми використовуємо стандартний http-транспорт, будь-хто інший може легко отримати пакет. Оскільки компанія пакує власне програмне забезпечення і не хоче ділитися ним з усіма, транспорт http стає проблемою. Не трагедія, а проблема. Існує кілька способів обмежити доступ до пакету - брандмауер, обмеження доступу на рівні веб-сервера, використовуючи ssh як транспорт. Тут можна прочитати досить легко читати на цю тему: Обмежити доступ до вашого приватного сховища Debian

У нашому випадку ми вирішили використовувати https транспорт + автентифікацію сертифікату клієнта. Коротко, все, що потрібно:

1. Підготувати самопідписані сертифікати, клієнта та сервера (використовуючи easy-rsa);

2. Налаштуйте веб-сервер, який у фронтовому сховищі приймає лише https; У разі nginx це може виглядати так:

   server {
   
     listen 443;
   
     root /path/to/public;
     server_name secure_repo;
   
     ssl on;
     ssl_certificate /etc/nginx/ssl/server.crt;
     ssl_certificate_key /etc/nginx/ssl/server.key;
   
     ssl_session_timeout 5m;
   
     ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
     ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:;
   
     ssl_prefer_server_ciphers on;
     ssl_client_certificate /etc/nginx/ssl/ca.crt;
     ssl_verify_client on;
   
     location / {
        autoindex on;
     }
   }
   

3. Помістіть сертифікат клієнта, клієнтський ключ та сертифікат ca в / etc / apt / ssl і, у випадку з Ubuntu, додайте файл 00https у /etc/apt/apt.conf.d:

   Debug::Acquire::https "true"; Acquire::https::example.com { Verify-Peer "true"; Verify-Host "false"; CaInfo "/etc/apt/ssl/ca.crt"; SslCert "/etc/apt/ssl/client.crt"; SslKey "/etc/apt/ssl/client.key"; };

Майте на увазі, що якщо ви використовуєте сертифікат, який самостійно підписує, важливо вимкнути перевірку хоста. Verify-Host "false";Якщо цього не зробити, ви введете помилку: SSL: certificate subject name (blah-blah-blah) does not match target host name 'example.com'

І ось ми не маємо більше несанкціонованого доступу до сховища. Тож це досить корисна і потужна річ.

Зауважте, що через такі вразливості

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467

... що обходить підпис InRelease, мабуть, хороша ідея налаштувати HTTPS все одно.

Для випадків використання "анонімності" також існує такий варіант, apt-transport-torякий дозволяє вам розміщувати URI, як tor+http://у файлах source.list. Це набагато кращий захист від анонімності, ніж просто шифрування з'єднання з дзеркалом.

Наприклад, місцевий спостерігач все ще знатиме, що ви оновлюєте або встановлюєте програмне забезпечення навіть за допомогою HTTPS, і, ймовірно, може зробити деякі пристойні здогадки щодо того, хто з тих, хто ви робите (і, можливо, навіть, які пакети, залежно від розміру).

Debian надає сховища APT через Tor-сервіси "Onion" Tor, щоб ви могли отримати повне шифрування (подібне до TLS), не довіряючи системі доменних імен. Дивіться onion.debian.org про всі доступні таким чином послуги Debian. Основний сховище Debian FTP знаходиться вvwakviie2ienjx6t.onion