Czy apt-get
używa https lub innego rodzaju szyfrowania? Czy istnieje sposób, aby go skonfigurować, aby go używał?
apt
configuration
encryption
official-repositories
https
Strapakowsky
źródło
źródło
Odpowiedzi:
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 podaszhttps://
adresy URL/etc/apt/sources.list
i/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:
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.
źródło
apt-get update
zgłasza błąd podczas próby uzyskania dostępu do linków. Z ppas: to samo. Czy ktoś tego próbował?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.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).
źródło
apt update
i 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 uruchomiszapt update
przed 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.Najnowsze wersje APT mają wbudowaną obsługę TLS, więc wystarczy zastąpić swoje lustrzane adresy URL repozytorium
https
pakietami z prefiksami. W przypadku Debiana może to wyglądać tak: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.
źródło
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:
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:
sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup
aby wykonać kopię zapasową listy źródeł aktualizacji.sudo sed --in-place --regexp-extended 's http://(us\.archive\.ubuntu\.com|security\.ubuntu\.com) https://mirrors.wikimedia.org g' /etc/apt/sources.list
na 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:
sudo apt-get update
polecenie.sudo cp /etc/apt/sources.list.backup /etc/apt/sources.list
polecenia.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
.źródło