Jak korzystać z https w apt-get?


51

Czy apt-getużywa https lub innego rodzaju szyfrowania? Czy istnieje sposób, aby go skonfigurować, aby go używał?


3
Należy pamiętać, że z powodu luk w zabezpieczeniach, takich jak bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467 ... które omijają podpisywanie InRelease, prawdopodobnie dobrym pomysłem jest skonfigurowanie HTTPS.
Royce Williams

whydoesaptnotusehttps.com to strona internetowa, która dokładnie i wyczerpująco odpowiada na to pytanie.
m.raynal

1
Jest bardziej przyziemny powód, dla którego byłoby to przydatne. Często korzystam z połączenia internetowego ze zepsutym „przezroczystym” serwerem proxy, który ma tendencję do blokowania pobierania niektórych plików deb (prawdopodobnie powodują one głupie blokowanie złośliwego oprogramowania). Ale przez https serwer proxy nie wie, co pobieram, więc nie przeszkadza.
Nate Eldredge

Odpowiedzi:


53

apt-get(i inne polecenia manipulowania pakietami, które są frontonem do tych samych bibliotek APT) mogą korzystać z HTTP, HTTPS i FTP (i zamontowanych systemów plików). Jeśli podasz https://adresy URL /etc/apt/sources.listi /etc/apt/sources.list.d/*, następnie APT użyje protokołu HTTPS.

APT weryfikuje podpis paczek. Nie musisz więc mieć formy transportu zapewniającej uwierzytelnianie danych. Jeśli atakujący zmodyfikuje pobierane pliki, zostanie to zauważone. Użycie weryfikacji podpisu jest lepsze niż połączenie HTTPS, ponieważ wykryje atak na serwer, z którego pobierasz plik, a nie tylko atak w drodze.

Mówiąc dokładniej, (uproszczony) przepływ danych dla pakietu jest następujący:

  1. Pakiet jest produkowany na maszynie kompilacyjnej.
  2. Pakiet jest podpisany na komputerze kompilacji.
  3. Podpisany pakiet jest kopiowany do kopii dystrybucyjnej pobierania.
  4. Pobierasz pakiet.

HTTPS zapewnia prawidłowe wykonanie kroku 4. Podpisy paczki zapewniają, że kroki od 2 do 4 przebiegają poprawnie.

W rzeczywistości HTTPS ma jedną małą zaletę dla kroku 4: podpisy paczki zapewniają tylko, że paczka jest autentyczna. Osoba atakująca w kroku 4 może podszyć się pod legalny serwer i obsługiwać nieaktualne wersje pakietu. Na przykład osoba atakująca może uniemożliwić pobranie aktualizacji zabezpieczeń w nadziei na wykorzystanie luki w zabezpieczeniach komputera, którą można by załatać, gdyby nie atak. To nie jest bardzo realistyczny scenariusz, ponieważ wymaga aktywnego atakującego (aby musiał to być ktoś, kto kontroluje twoje połączenie internetowe), ale może się zdarzyć w zasadzie.

Inną korzyścią dla HTTPS byłaby próba ukrycia faktu, że pobierasz pakiety Ubuntu przed kimś szpiegującym twoje połączenie sieciowe. Nawet wtedy podsłuchujący może zobaczyć, z którym hostem się łączysz; jeśli połączysz się z lustrem Ubuntu i pobierzesz setki megabajtów, jasne jest, że pobierasz pakiety Ubuntu. Podsłuchiwacz może również w większości dowiedzieć się, które pakiety pobierasz z rozmiaru plików. Tak więc HTTPS byłby użyteczny tylko wtedy, gdy pobierasz z serwera, który oferuje także inne pliki o podobnej wielkości - nie widzę sensu, z wyjątkiem pakietów innych firm, i tylko w bardzo nietypowych okolicznościach.

Powtórzmy: zwykła zaleta HTTPS, polegająca na tym, że wiesz, że masz połączenie z prawdziwym serwerem, jest bezużyteczna podczas pobierania pakietów Ubuntu. Weryfikacja podpisu na paczkach daje silniejszą gwarancję niż to, co może zapewnić HTTPS.


11
Nie chodzi o to, że jest mniej bezpieczny, ale o to, że jest mniej istotny dla tego, co próbujesz chronić. Dzięki APT szyfrowanie zawartości transakcji nie jest tak ważne, ponieważ to, co pobierasz, jest bardzo kontrowersyjne: są to te same pakiety Ubuntu, które pobiera wiele osób. Ale ważne jest, aby pliki, które otrzymujesz, nie zostały naruszone.
thomasrutter

3
Kilka tygodni temu próbowałem zmienić źródła na https i to po prostu nie działało, apt-get updatezgłasza błąd podczas próby uzyskania dostępu do linków. Z ppas: to samo. Czy ktoś tego próbował?
Strapakowsky

8
Aby to działało, repozytorium (serwer aktualizacji) musi obsługiwać protokół https / SSL . Główny archive.ubuntu.com nie . Możesz sprawdzić w przeglądarce, czy serwer go obsługuje, poprzedzając https: // adresem URL i sprawdzając, czy otrzymujesz listę katalogów itp.
Ish

7
„Osoba atakująca w kroku 4 może podszyć się pod legalny serwer i obsługiwać nieaktualne wersje pakietu”. W rzeczywistości chronimy się przed tym, podając informacje o pakiecie na datę ważności. APT ostrzeże po tej dacie, że twoje lustro jest nieaktualne.
tumbleweed

4
Oto lista wszystkich 15 serwerów lustrzanych obsługujących HTTPS wraz ze skryptem, który generuje listę: pastebin.com/QY2TQ1dq
Shnatsel

13

W przypadku APT zwykle ważniejsze jest nie to, że połączenie jest szyfrowane, ale że otrzymywane pliki nie zostały naruszone.

APT ma wbudowaną weryfikację podpisów, aby to zapewnić.

Szyfrowanie uniemożliwiłoby podsłuchującym zobaczenie, co pobierasz, ale to, co faktycznie pobierasz (i żądasz), jest dość kontrowersyjne: będzie to samo, co tysiące innych użytkowników Ubuntu, którzy pobierają, a pliki nie zawierają niczego, co nie jest t swobodnie dostępne na wielu serwerach. Jeśli jednak potrzebujesz prywatności na temat tego, które pakiety w szczególności pobierasz, możesz użyć HTTPS (określ to na swojej stronie sources.list).

Weryfikacja podpisu wbudowana w APT zapewni, że otrzymane pliki nie zostaną zmienione. Tak naprawdę nie ma znaczenia, skąd pochodzą pliki, a nawet można mieć proxy lub odwrotne proxy między tobą a serwerem, aby zmniejszyć obciążenie serwera lub przyspieszyć. Weryfikacja podpisu nadal zapewnia otrzymanie niezmodyfikowanego pliku, pasującego do podpisu, który można wytworzyć kryptograficznie tylko z oryginalnym plikiem i kopią klucza prywatnego Ubuntu.

Jeśli przełączysz się na HTTPS, nie będziesz w stanie skorzystać z serwerów proxy w celu przyspieszenia dostępu lub zmniejszenia obciążenia. I nie zapewniłoby to już żadnej pewności, że nie zostanie sfałszowane, czego weryfikacja podpisu APT jeszcze nie daje. Oznaczałoby to jednak, że osoby podsłuchujące (takie jak dostawca usług internetowych) nie będą w stanie zobaczyć, które pakiety są pobierane (co prawdopodobnie nie będzie poufne, a jak zauważył Gilles, mogą odgadnąć na podstawie rozmiaru pliku).


3
HTTPS nie zapewnia dużej prywatności, ponieważ rozmiar plików jest widoczny. W rzeczywistości HTTPS ma niewielką zaletę, ponieważ zapewnia, że ​​osoba atakująca, która kontroluje połączenie sieciowe, nie może po cichu wślizgnąć się w przestarzałe dane. To trochę za daleko.
Gilles „SO- przestań być zły”

6
Słuszne uwagi. Przez „nieaktualne dane” zakładam, że masz na myśli człowieka w środku, który tworzy wersję lustra Ubuntu złożoną z nieco wcześniejszych wersji, ale wciąż niezmienioną w stosunku do tego, co Ubuntu podpisał w tym czasie.
thomasrutter

5
Tak, to jest to. Nie wahaj się zaznaczyć, że jestem trochę żargonem - muszę pamiętać, że jest to Zapytaj Ubuntu, a nie Bezpieczeństwo informacji .
Gilles „SO- przestań być zły”

Wydaje się, że jest duża dziura w apt - kiedy ty apt updatei mężczyzna w środku karmi cię fałszywymi indeksami, apt z radością bierze wszystko, co daje ci mężczyzna w środku i zapisuje to w / var / lib / apt / list. Nie chodzi tylko o złego człowieka w środku, ale tak, jakbyś był w hotelowym WiFi i został przekierowany na stronę logowania, jeśli uruchomisz apt updateprzed zalogowaniem, twoje / var / lib / apt / list zostaną zniszczone z HTML strony głównej hotelu. PODROBIONY! W każdym razie podstawowe sprawdzanie certyfikatów TLS natychmiast wykluczałoby to.
Marius

@Marius nie powinno to być możliwe ze względu na weryfikację, która obejmuje zarówno listy, jak i pakiety. Jeśli odtworzyłeś to ze standardową instalacją Apt, powinieneś zgłosić to opiekunowi.
thomasrutter

1

Najnowsze wersje APT mają wbudowaną obsługę TLS, więc wystarczy zastąpić swoje lustrzane adresy URL repozytorium httpspakietami z prefiksami. W przypadku Debiana może to wyglądać tak:

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

Jest to przydatne, mimo że APT zawiera własny protokół podpisu, aby upewnić się, że pakiety nie są modyfikowane, ponieważ mogą występować błędy w APT (jak było: CVE-2016-1252 , CVE-2019-3462 ). Protokoły HTTP / TLS i ich szyfry podlegają intensywnej analizie, więc poważna podatność na zero dni jest znacznie mniej prawdopodobna, jeśli dodasz tę warstwę bezpieczeństwa.


Ups, dopiero teraz zdaję sobie sprawę, że ta strona to Ask Ubuntu. :) Nie mogłem znaleźć podobnego rozwiązania CDN dla Ubuntu.
Leif Arne Storset

0

Myślę, że to pytanie mogłoby posłużyć odpowiedzią z instrukcjami dla laika, więc…

APT nadal domyślnie nie używa HTTPS w codziennych wersjach Ubuntu 19.10 (Eoan) (która jest wciąż w fazie rozwoju). Można to zweryfikować, sprawdzając plik /etc/apt/sources.list i zauważając, że wszystkie źródłowe adresy URL wykorzystują schemat adresów URL „http:”.

Aby skonfigurować go do korzystania z HTTPS, można postępować zgodnie z następującymi instrukcjami:

Najpierw znajdź godne zaufania oficjalne lustro archiwalne Ubuntu, które obsługuje HTTPS:

  1. Przejdź do oficjalnej kopii lustrzanej archiwum dla Ubuntu .
  2. W tabeli na tej stronie internetowej określ serwery lustrzane, które są (A) hostowane w witrynach, które uważasz za godne zaufania, (B) mają serwer lustrzany „http:” i opcjonalnie (C) odpowiadają Twojej bliskości geograficznej, szybkości serwera i aktualizacji preferencje świeżości.
  3. W tabeli na tej stronie kliknij link „http” lustra określonego w kroku (2), aby przejść do wersji „http:” lustra.
  4. Na pasku adresu przeglądarki ręcznie zmień „http:” w adresie URL strony na „https:”.
  5. Przejdź ponownie do kopii dystrybucyjnej (za pomocą adresu URL „https:”), aby sprawdzić, czy to rozwiązuje.

Na przykład uważam, że Fundacja Wikimedia jest godna zaufania, więc odwiedziłem http://mirrors.wikimedia.org/ubuntu/ mirror URL, a następnie zmieniłem go na https://mirrors.wikimedia.org/ubuntu/ , który z powodzeniem rozwiązuje.

Jeśli używasz przeglądarki Firefox (67.0.4) i masz zainstalowane rozszerzenie HTTPS Everywhere (2019.6.27) z włączoną funkcją „Szyfruj wszystkie kwalifikujące się witryny” (za pomocą panelu przycisków paska narzędzi), kroki (4) i (5) można pominąć ponieważ rozszerzenie automatycznie zmodyfikuje adres URL w celu wykorzystania protokołu HTTPS, umożliwiając natychmiastowe ustalenie, czy wersja adresu URL „https:” zostanie rozwiązana.

Po drugie , zaktualizuj listę źródeł APT:

  1. Wykonaj polecenie, sudo cp /etc/apt/sources.list /etc/apt/sources.list.backupaby wykonać kopię zapasową listy źródeł aktualizacji.
  2. Zamień lustrzany podstawowy adres URL - pokazany tutaj jako https://mirrors.wikimedia.org - w poleceniu sudo sed --in-place --regexp-extended 's http://(us\.archive\.ubuntu\.com|security\.ubuntu\.com) https://mirrors.wikimedia.org g' /etc/apt/sources.listna lustrzany podstawowy adres URL preferowanego lustrzanego pliku, a następnie wykonaj polecenie.

Po trzecie , powinieneś sprawdzić zawartość katalogu /etc/apt/sources.list.d/ pod kątem źródeł „http:”, które można zmienić na „https:” po zainstalowaniu oprogramowania spoza archiwum Ubuntu.

Na przykład pakiet Visual Studio Code firmy Microsoft dodaje do tego katalogu plik vscode.list, który określa adres URL „http:”. Prosta zmiana schematu URL z „http:” na „https:” umożliwia aktualizacje przez HTTPS.

Rozważ utworzenie kopii zapasowej takich plików źródłowych przed ich modyfikacją.

Na koniec wykonaj aktualizację, aby upewnić się, że aktualizacje będą działać poprawnie:

  1. Wykonaj sudo apt-get updatepolecenie.
  2. Jeśli to nie zadziała zgodnie z oczekiwaniami, przywróć pliki listy kopii zapasowych utworzone przez wykonanie sudo cp /etc/apt/sources.list.backup /etc/apt/sources.listpolecenia.

Warto również zauważyć, że istnieje pakiet apt-transport-https , aby dodać obsługę HTTPS do APT. Jednak pakiet ten jest najwyraźniej niepotrzebny według strony internetowej https://launchpad.net/ubuntu/eoan/+package/apt-transport-https i nie był potrzebny od APT 1.5 zgodnie z informacjami pokazanymi po wykonaniu polecenia apt-cache show apt-transport-https.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.