Dlaczego nie ma transportu https dla narzędzia debian apt?

Jest. Musisz zainstalować pakiet apt-transport-https . Następnie możesz użyć takich linii jak

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

w swoim pliku sources.list. Zwykle nie jest to jednak konieczne, ponieważ cała zawartość i tak jest publiczna i dodaje narzut szyfrowania i opóźnienia. Ponieważ nie ufasz kluczowi publicznemu atakującego, nawet ruch HTTP jest zabezpieczony przed atakami MitM. apt ostrzeże Cię i nie zainstaluje pakietów, gdy osoba atakująca wstrzyknie zmanipulowane pakiety.

EDYCJA: Jak wspomniano w komentarzach, bezpieczniej jest używać Repozytorium TLS . Badania pokazują , że używanie apt na niezaszyfrowanych repozytoriach może rzeczywiście stanowić zagrożenie dla bezpieczeństwa, ponieważ transport HTTP jest podatny na ataki powtórkowe.

Komentarze

• Nie, większość serwerów lustrzanych nie obsługuje protokołu HTTPS. Po prostu dlatego, że ' nie ma sensu szyfrować tego rodzaju ruchu. Pakiety są mimo to weryfikowane, a informacje są publiczne.
• Przychodzi mi do głowy kilka powodów, dla których nadal wolę pobierać przez TLS: 1) Mogę dbać o swoją prywatność podczas instalowania pakietów i 2) tam mogą być błędami w kodzie sprawdzającym podpis pakietu, które MITM mógłby wykorzystać.
• @JackO ' Connor, podczas gdy pierwszy zarzut dotyczący prywatności jest zrozumiały, drugi to tak, jakby powiedzieć, że lubię strony internetowe podpisywać swoje treści kluczami PGP, ponieważ mogą zawierać błędy w kodzie TLS. Zarówno PGP, jak i TLS ustanawiają zaufanie; nie potrzebujesz do tego ' obu.
• @Marco twoja odpowiedź jest nieprawidłowa; liczne prace badawcze wykazały, że repozytoria APT i YUM są podatne na ataki typu replay, gdy dostęp do repozytorium uzyskuje się za pośrednictwem protokołu HTTP, nawet z podpisami GPG. Repozytoria powinny być dostępne tylko przez TLS, przez 100% czasu.
• Tutaj jest artykuł, do którego odnosi się @Joe Damato – zobacz też jego odpowiedz tutaj

Twój założenie jest błędne: możesz korzystać z pobierania HTTPS. Musisz tylko znaleźć serwer lustrzany, który go obsługuje i umieścić jego adres URL na liście źródeł. Będziesz musiał zainstalować pakiet apt-transport-https .

Debian nie tworzy protokołu HTTPS pobieranie jest łatwe, ponieważ przynosi bardzo niewielkie korzyści. Dystrybucja pakietów Debiana zawiera już mechanizm weryfikacji pakietów: wszystkie pakiety są podpisane za pomocą Gpg . Jeśli aktywny pośrednik przekierowuje Twój ruch na serwer z uszkodzonymi pakietami, uszkodzenie zostanie wykryte, ponieważ podpisy GPG nie będą prawidłowe. Korzystanie z GPG zamiast HTTPS ma tę zaletę, że chroni przed większą liczbą zagrożeń: nie tylko przeciwko aktywnemu man-in-the-middle na połączeniu użytkownika końcowego, ale także przeciwko nieuczciwemu lub zainfekowanemu serwerowi lustrzanemu lub innym problemom w dowolnym miejscu w łańcuchu dystrybucji pakietów.

HTTPS zapewnia niewielką przewagę w zakresie prywatności ponieważ przesłania pakiety, które pobierasz, jednak pasywny obserwator może nadal wykrywać ruch między Twoim komputerem a serwerem pakietów, więc wie, że pobierasz pakiety Debiana. Mogą również uzyskać dobre wyobrażenie o tym, które pakiety pobierasz z określonych rozmiarów plików.

Jedynym miejscem, w którym pomógłby HTTPS, jest załadowanie zaufania w celu uzyskania znanego, prawidłowego obrazu instalacyjnego. Debian tego nie robi ”. Wydaje się, że zapewnia to: istnieją sumy kontrolne nośnika instalacyjnego , ale tylko przez HTTP.

Komentarze

• Istnieje wersja HTTPS nośnika instalacyjnego: cdimage.debian.org/debian -cd
• Bardzo małe korzyści? A co z justi.cz/security/2019/01/22/apt-rce.html ?
• @AaronFranke Jeden konkretny błąd, którym jest łatwiejszy do wykorzystania z HTTP niż z HTTPS liczy się bardzo mało korzyści, tak. ' nie jest tak, jakby HTTP miał większą powierzchnię ataku niż HTTPS: w rzeczywistości sam HTTPS ma większą powierzchnię ataku, ponieważ obejmuje więcej kodu. Zatem nie jest to ' w ogóle korzyści netto: to ' kompromis między dwoma marginalnymi ryzykami.

Niedawno natknąłem się na problem z repozytorium apt mojej firmy. Problem polegał na tym, że jeśli używamy standardowego protokołu http transport każdy inny może łatwo dostać paczkę. Ponieważ firma pakuje własne, zastrzeżone oprogramowanie i nie chce się nim wszystkim dzielić, transport http staje się problemem. Nie tragedia, ale problem. Istnieje kilka sposobów ograniczenia dostępu do paczki – firewalling, ograniczanie dostępu na poziomie serwera WWW, używanie ssh jako środka transportu. Dość łatwą do skonsumowania lekturę na ten temat można znaleźć tutaj: Ogranicz dostęp do prywatnego repozytorium Debiana

W naszym przypadku zdecydowaliśmy się na użycie uwierzytelnienia https transport + certyfikat klienta. Krótko mówiąc, wystarczy:

1. Przygotować certyfikaty z podpisem własnym, klienta i serwer (przy użyciu easy-rsa);

2. Skonfiguruj serwer WWW, który front repozytorium akceptuje tylko https; W przypadku nginx może to wyglądać następująco:

   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. Umieść certyfikat klienta, klucz klienta i certyfikat CA w / etc / apt / ssl i, w przypadku Ubuntu, dodaj plik 00https do /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"; };

Pamiętaj, że jeśli używasz certyfikatu z podpisem własnym, ważne jest, aby wyłączyć weryfikację hosta: Verify-Host "false"; Jeśli tego nie zrobisz, „złapiemy błąd: SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

I zaczynamy, nie ma już nieautoryzowanego dostępu do repozytorium. Jest to więc bardzo przydatna i potężna rzecz.

Komentarze

• Dziękuję za świetną odpowiedź. Ale myślę, że główny problem nadal istnieje. HTTPS powinien naprawdę stać się domyślnym protokołem do transferów przez Internet, aw szczególności pakiety Debiana. Argumentem nie powinno być, dlaczego HTTPS, a powinno, dlaczego nie?
• @aalizadeh, zgadzam się z tobą, przy używaniu https jest narzut, ale nie ma dużego narzutu. Myślę, że głównym powodem, dla którego https nie jest domyślnym transportem, jest to, że niektóre organizacje wyraźnie zabraniają wszelkiego zaszyfrowanego ruchu (ponieważ chcą mieć możliwość wtykania nosów w to, co robią pracownicy przez Internet), co oznacza, że repozytoria muszą obsługiwać transporty http i https. Mogą istnieć inne kwestie
• Korzystanie z » Verify-Host ” false „; « jest błędny, nawet w przypadku certyfikatów z podpisem własnym. Zamiast tego musisz poinformować swoich klientów o (poprawnym) certyfikacie serwera.
• Rzeczywiście, ale tutaj moimi klientami były tylko systemy wewnętrzne. Więc zamiast tworzyć całą odpowiednią infrastrukturę pki, skracam róg. I tak, później pki zostało poprawnie rozliczone, a Verify-Host false; został usunięty. I tak, punkt jest ważny.
• w przypadku ubuntu xenial pakiety apt są pobierane jako użytkownik nieuprzywilejowany _apt, czy możesz zaktualizować ten wątek, podając szczegóły dotyczące zarządzania lub rozwiązania problemów z uprawnieniami do pliku.

Zwróć uwagę, że z powodu luk w zabezpieczeniach, takich jak

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

… który omija podpisywanie InRelease, prawdopodobnie i tak dobrym pomysłem jest skonfigurowanie HTTPS.

I to nie jest jedyny przykład – wiele innych systemów aktualizacji, które domyślnie obsługują protokół HTTP, również miało historię błędów weryfikacji podpisów.

Mechanizmy aktualizacji o krytycznym znaczeniu dla bezpieczeństwa powinny używać zarówno protokołu HTTPS , jak i weryfikacja podpisu, aby była solidna. Każda z nich ogranicza awarię drugiej.

Komentarze

• A teraz także ten: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. Podpisywanie InRelease nie jest wystarczające . ” Ale przeniesienie wszystkich serwerów lustrzanych do HTTPS wymaga czasu i koordynacji! „. Tak. Zacząć teraz. To nie będzie ostatnia awaria InRelease.
• Tutaj ' to kolejny przykład z innego ekosystemu – alpejskiego. Jego system zarządzania pakietami nie ' domyślnie korzysta z protokołu HTTPS i polega wyłącznie na podpisaniu w celu sprawdzenia integralności pakietu …i we wrześniu 2018 r. weryfikacja zawierała błąd, który można było wykorzystać zdalnie: justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine powinno się rozpocząć przechodzę teraz na domyślnie używanie HTTPS.
• (Pełne ujawnienie: moje własne sedno, ale to ' to jedyne źródło, jakie znam of), oto lista wszystkich błędów weryfikacji podpisywania po stronie klienta, o których ' jestem świadomy. Lista ma niebanalny rozmiar i regularnie rośnie. Dodaje powitanie. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004

W przypadku użycia„ anonimowość ”istnieje również apt-transport-tor, który umożliwia umieszczenie identyfikatorów URI, takich jak tor+http:// w pliki sources.list. Jest to znacznie lepsza ochrona anonimowości niż zwykłe szyfrowanie połączenia z serwerem lustrzanym.

Na przykład lokalny obserwator nadal wiedziałby, że aktualizujesz lub instalujesz oprogramowanie nawet przy użyciu protokołu HTTPS, i prawdopodobnie może zgadnąć co do tego, które z tych robisz (i być może nawet które pakiety, w zależności od rozmiaru).

Debian dostarcza repozytoria APT za pośrednictwem „usług cebulowych” Tora, dzięki czemu możesz uzyskać pełne szyfrowanie (podobnie do TLS) bez konieczności ufania systemowi nazw domen. Zobacz onion.debian.org , aby zapoznać się ze wszystkimi usługami Debiana dostępnymi w ten sposób. Główne repozytorium FTP Debiana znajduje się pod adresem vwakviie2ienjx6t.onion