Forum Linux.pl
System => Instalacja => Wątek zaczęty przez: parana w 2019-06-24, 11:28:17
-
Witajcie, czy używa może ktoś z Was https w apt w Debianie?
Jeśli tak to proszę o podpowiedź czy działa to stabilnie i jak z mirrorami https dla Debiana i czy mamy jakieś w Polsce?
Jaki proponujecie wpisy https /etc/apt/sources.list?
-
Nie używam bo i po co?
https://wiki.debian.org/SourcesList
-
1. Proste pytania mozna takze "
jakby co" zadawac np. na kanalach IRC Debiana.
2. bo i po co
Ponieważ http i pewnie ftp jest podatne na atak " man in the middle " (MITM)
https://thehackernews.com/2019/01/linux-apt-http-hacking.html
Na czym polega ten atak dokladniej --> https://pl.wikipedia.org/wiki/Atak_man_in_the_middle
Dlaczego https nie jest powszechne --> https://whydoesaptnotusehttps.com/
Dzieki HTTPS - mamy jakies potwierdzenie ze wchodzimy na zaufana strone,
a moze nie zawsze, - strona oszustow tez moze miec https i troche podobna nazwe
- rzadko kto sprawdza przez kogo zostala uwierzytelniona dana strona
- celem szyfrowania nie jest animowosc, ale ochrona przed podmiana pliku podczas przesylania
Podobny problem jest z pobraniem ISO jak z pakietami.
( Pomine ze ciezko bylo na tej samej stronie co *netinst.iso dac linka do plikow hash i kluczy, lub skopiowac
ja godzine szukalem zanim znalazlem )
Zauzmy ze mozemy bezpiecznie pobrac, ale zastanowmy sie czy mozna sprawdzic czy plik nie zostal zmodyfikowany....
- Suma kontrolna
- pozwala sprawdzic czy wieksza czesc pliku nie zostala uszkodzona, a ta mniejszosc to tzw. kolizje
- Wstrzykniecie wirusa zazwyczaj jest nie mozliwe bo kolizje sa zazwyczaj rozsiane --> https://proxy.duckduckgo.com/iu/?u=https%3A%2F%2Fwww.links.org%2Fpics%2Fd12-2.png&f=1
- Ale moze umozliwic czasami na wstrzykniecie luki bezpieczenstwa, bo moga byc znacznie mniejsze i przez to trudniejsze do wykrycia
- W tych algorytmach zazwyczaj im wiekszy plik i im mniej suma "bitow weryfikacyjnych" tworzy / posiada (ze sie tak wyraze),
to bedzie wiecej kolizji - Nie mozemy jednoznacznie stwierdzic, czy algorytmy nie zostaly stworzone odrazu z mozliwoscia odnajdywania kolizji,
ale doswiadczenie pokazuje ze nie jest to proste. Algorytmy ktore nie zostaly oficjalnie zlamane uwaza sie za bezpieczne
i wyglada to mniej wiecej tak http://valerieaurora.org/hash.html - Jesli suma znajduje sie w tym samym co plik, to mozemy zalozyc ze mozna obie te rzeczy zmodyfikowac
- Klucze
- pozwalaja zidentyfikowac do jakiego wlasciciela i repozytorium nalezy plik
- ale problem w tym ze klucz jakby co mozna skopiowac,
- a nawet wydaje mi sie ze nie trzeba nic z nim robic, skoro mamy podatnosc w kolizjach sumy kontrolnej.
- jezeli podpisanie daje jeszcze dodatkowe zabezpieczenie, to przepraszam, ale nie znam, bo nigdy nie testowalem ani nie slyszalem
[/list]
-
Dlaczego https nie jest powszechne
1. Instalując Dockera musiałem dodać: deb [arch=amd64] https://download.docker.com/linux/debian...
2. Instalując VSC musiałem dodać: deb [arch=amd64] https://packages.microsoft.com/repos/vscode...
3. Instalując VisualBox misałem dodać: deb https://download.virtualbox.org/virtualbox/debian...
4. Instalując Operę musiałem dodać: deb https://deb.opera.com/opera-stable/...
Wszystkie repozytoria https. Dlatego nie wiem dlaczego nie miałbym przejść z repozytoriami Debiana na HTTPS tym bardziej, że są gotowe i działają pod https://deb.debian.org/.
Po wtóre instalacja w moim systemie wcześniej podanych programów wymusiła zainstalowanie pakietu apt-transport-https, więc system jest na to przygotowany.
Używając github klonując repo używamy też standardowo HTTPS. W Polsce icm.edu.pl już wspiera https więc można mirror ustawić na https://ftp.icm.edu.pl/pub/linux/debian
Osobiście uważam, że nadszedł czas by przejść na HTTPS jeśli jest taka możliwość i jest to wspierane tak by pobieranie pakietów oparte było na SSL/TLS.
TLS to nie tylko niezmienność transferu danych jak napisał kolega 1709, ale to także poufność i uwierzytelnienie.
Ciekawe jak to wygląda w innych dystrybucjach Linuxa?
-
Moje dlaczego nie:
* HTTPS nie daje się cache'ować (u mnie w robocie na przykład wszystkie debianowate przechodzą przez centralny apt-cache-ng).
* Daje dodatkowe obciążenie dla serwerów, co jest nie "niemierzalne" przy tysiącach użytkowników.
* Nie podnosi bezpieczeństwa, bo po ściągnięciu i tak sprawdzane są sumy kontrolne i podpisy cyfrowe.
Ewentualnie podnosi poufność i bagiety nie podjadą mi prewencyjnie pod blok jak tylko ściągnę tor-a albo transmission.
-
Ciekawe jak to wygląda w innych dystrybucjach Linuxa?
W bardziej " zacofanej " jak mojej to
- Dalej jest używane ftp, poniewaz nie ma developerow ktorzy zaimplementowali by https
I tak troche poza tematem.
- klucze GPG w moich oczach troche traca na znaczeniu.
W Debianie kazdy pakiet ma swojego opiekuna i mozna to zweryfikowac zagladajac na strone. U mnie jest tak, ze developerow jest zbyt malo i kazdy moze tworzyc dowolny pakiet. Dlatego ...
Po pierwsze pakiety sa juz weryfikowane w repozytorium na podstawie Nicku w pakiecie oraz nazwy "kanalu" ktorym ten pakiet dotarl.
Jesli ktos osmieli sie zmienic nick w pakiecie lub zapomniec dodac to pakiet jest automatycznie odrzucany przez skrypt.
Klucz GPG, przynajmniej mnie sie wydaje ze utrudnia, ale nie eliminuje problemu edytowania pakietu
(Tu moge sie mylic, bo wiele osob pisze o weryfikacji np. sygnatury.)
- Teoretycznie nie powinno sie takze uffac ze
-- osoby paczkujace maja bezpieczny komputer
-- osoba posiadajaca repozytorium ma zawsze dobre intencje
- Podstawa weryfikacji miedzy paczkujacym a zwyklym uzytkownikiem wydaje sie byc suma kontrolna pliku,
ale nie jest to jeszcze rozwiazane dokonca
-- paczkujacy musialby okresowo sprawdzac czy na serwerze suma kontrolna jest taka sama,
lub kazdy z nich musialby miec wlasny serwer z sumami kontrolnymi, z ktorych system automatycznie by pobieral w celu sprawdzenia.
-- system zawsze sprawdza sumy kontrolne pobranych pakietow na podstawie swojej bazy sum kontrolnych
-- gdyby repozytorium zostalo zaatowane, to lepiej gdyby sumy kontrolne byly na osobnym serwerze
- Poniewaz nie mozna uffac paczkujacym, to pakiety powinny byc kompilowane u jednej osoby lub jednym serwerze,
bo jesli doszloby do edycji pakietu to przy kompilacji mozna
-- porownac bit po bicie, lub nawet sciagnac caly kod zrodlowy programu z orginalnej strony i skompilowac
-- poniewaz kod zrodlowy bedzie orginalny, to latwiej bedzie mozna wykryc manipalacje w pliku ktory przygotowuje paczkujacy,
zwlaszcza ze powinien byc napisany w czytelny sposob. https://pl.wikipedia.org/wiki/KISS_%28regu%C5%82a%29
i kazdy z uzytkownikow moze sprawdzic zarowno plik do budowania jak i kod zrodlowy programu.
- Nie rozwiazuje to problemu braku zaufania do wszystkich developerow
" Nie uffaj nikomu ", " Weryfikacja podstawa zaufania "
- Jeden z tych problemow jest omawiany przy temacie Reproduciple Builds https://www.youtube.com/watch?v=kpRCfVk24m4
-
Od siebie dodam, że dla mnie desktopowca te problemy z cachowaniem nie dotyczą bo nie widzę potrzeby tego robić dla jednego komputera (to nie jest tak jak piszecie, że nie można cachować, jest podany na wiki apt-cache-ng sposób na poradzenie sobie z tym problemem).
To, co opisał kolega 1709, to podatność, która została już dawno załatana.
Takie podatności były już odkrywane i łatane w ramach zespołu bezpieczeństwa, można powiedzieć, że to normalna kolej rzeczy.
Generalnie czytam co piszą developerzy Debiana i oni nie widzą większego sensu w korzystaniu z https dla repozytoriów, to, że inni korzystają nie jest jakimś wyznacznikiem, że tak trzeba.
Podsumowując nie widzę potrzeby załączać to na siłę na desktopie i nie spotkałem się jeszcze z przekonującymi argumentami do ich stosowania.
Oczywiście nic nie stoi na przeszkodzie aby to sobie załączyć jeśli tylko dystrybucja na to pozwala.
-
Jeden z tych problemow jest omawiany przy temacie Reproduciple Builds https://www.youtube.com/watch?v=kpRCfVk24m4
Dzięki za to co napisałeś no i filmik :)