Miért nincs https szállítás a debian apt eszközhöz?

Van. Telepítenie kell a apt-transport-https csomagot. Ezután olyan sorokat használhat, mint a

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

a sources.list fájlban. De általában erre nincs szükség, mivel a teljes tartalom egyébként is nyilvános, és titkosítási rezsit és késést ad hozzá. Mivel nem bízik a támadók nyilvános kulcsában, még a http-forgalom is védett a MitM támadásoktól. A apt figyelmeztet, és nem tudja telepíteni a csomagokat, amikor a támadó manipulált csomagokat injektál.

SZERKESZTÉS: Amint a megjegyzésekben említettük, valóban biztonságosabb a TLS adattár. A kutatások azt mutatják, hogy az apt használata titkosítatlan adattárakban valóban biztonsági kockázatot jelenthet, mivel a HTTP-transzport sérülékeny az ismétlési támadásokkal szemben.

Megjegyzések

• Nem, a legtöbb tükör nem támogatja a https-t. Egyszerűen azért, mert ‘ nincs sok értelme titkosítani ezt a fajta forgalmat. A csomagokat egyébként ellenőrzik, és az információk nyilvánosak.
• Pár okra gondolhatok, amelyeket mégis inkább a TLS-n keresztül szeretnék letölteni: 1) A csomagok telepítésekor fontos lehet az adatvédelem, és 2) ott hibák lehetnek a csomag aláírás-ellenőrző kódjában, amelyet egy MITM kihasználhat.
• @JackO ‘ Connor, míg az adatvédelemmel kapcsolatos első kifogás érthető, a második olyan, mintha azt mondanám, hogy szeretem a weboldalakat PGP kulcsokkal aláírni a tartalmukat, mert a TLS-kód hibákat tartalmazhat. A PGP és a TLS egyaránt bizalmat teremt; ehhez nem szükséges mindkettő ‘.
• @Marco a válaszod helytelen; számos kutatási anyag azt mutatta, hogy az APT és a YUM adattárak is kiszolgáltatottak az ismétlési támadásokkal szemben, amikor a tárházat HTTP-n keresztül érik el, még GPG aláírásokkal is. A tárakhoz csak a TLS-n keresztül szabad hozzáférni, az esetek 100% -ában.
• Itt található az a cikk, amelyre @Joe Damato hivatkozik – lásd még válasz itt

téves feltételezés: használhatja a HTTPS letöltéseket. Csak meg kell találnia egy tükröt, amely támogatja, és felteszi annak URL-jét a források listájába. Telepítenie kell a apt-transport-https csomagot.

A Debian nem készít HTTPS-t a letöltések egyszerűek, mert nagyon kevés az előnye. A Debian csomagterjesztés már tartalmaz egy mechanizmust a csomagok ellenőrzésére: az összes csomag Gpg -vel van aláírva. Ha egy aktív ember a közepén irányítja a forgalmát egy sérült csomagokkal rendelkező kiszolgálóra, akkor a sérülést észlelni fogja, mert a GPG-aláírások nem lesznek érvényesek. A GPG használata a HTTPS helyett előnye, hogy védelmet nyújt további fenyegetésekkel szemben: nemcsak a végfelhasználói kapcsolaton belüli aktív ember ellen, hanem egy szélhámos vagy fertőzött tükör vagy más problémák ellen is, bárhol a csomagterjesztési láncban.

A HTTPS nyújt némi adatvédelmi előnyt A passzív megfigyelő azonban még mindig képes észlelni a számítógép és a csomagkiszolgáló közötti forgalmat, így tudnák, hogy Ön letölti a Debian csomagokat. Jó képet kaphatnak arról is, hogy mely csomagokat tölti le a fájlméretekből.

Az egyetlen hely, ahol a HTTPS segítséget nyújt, az a megbízhatóság indításának feltöltése, egy ismert érvényes telepítési kép megszerzése. Debian nem ” Úgy tűnik, hogy ez nem biztosítja: a telepítési adathordozók ellenőrző összegei vannak, de csak a HTTP-n keresztül.

Megjegyzések

• A telepítési adathordozó HTTPS verziója létezik: cdimage.debian.org/debian -cd
• Nagyon kevés előny? Mi a helyzet a justi.cz/security/2019/01/22/apt-rce.html ?
• @AaronFranke Egy konkrét hibával, amely a HTTP-vel könnyebb kihasználni, mint a HTTPS-sel, az nagyon kevés haszonnal jár, igen. ‘ nem mintha a HTTP nagyobb támadási felülettel rendelkezne, mint a HTTPS: valójában maga a HTTPS is nagyobb támadási felülettel rendelkezik, mivel több kódot tartalmaz. Tehát egyáltalán nem ‘ még nettó haszon sem: ez ‘ kompromisszumot jelent két marginális kockázat között.

Nemrég jöttem rá a problémára a Vállalkozásom megfelelő adattárával. A probléma az volt, hogy ha a szokásos http a szállítás során bárki más megkaphatja a csomagokat. Mivel a vállalat saját szoftverét csomagolja, és nem akar mindenkivel megosztani, a http szállítás problémává válik. Nem tragédia, hanem probléma. Párféleképpen korlátozhatjuk a csomaghoz való hozzáférést – tűzfal, a hozzáférés korlátozása a web-szerver szintjén, az ssh használata transzportként. A témával kapcsolatban elég könnyű elolvasni: Hozzáférés korlátozása a privát Debian-tárházhoz

Esetünkben a https transport + kliens tanúsítvány hitelesítés mellett döntöttünk. Röviden, csak annyi kell:

1. Készítsen elő saját aláírású tanúsítványokat, klienseket és szerver (az easy-rsa használatával);

2. Állítsa be a webkiszolgálót, hogy melyik elülső adattár fogadja el csak a https-t; Az nginx esetében a következőképpen nézhet ki:

   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. Helyezze az ügyféltanúsítványt, az ügyfélkulcsot és a ca tanúsítványt az / etc / apt / fájlba ssl, és Ubuntu esetén adjon hozzá 00https fájlt az /etc/apt/apt.conf.d fájlba:

   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"; };

Ne feledje, hogy önaláírt tanúsítvány használata esetén fontos kikapcsolni a gazdagép-ellenőrzést: Verify-Host "false"; Ha ezt nem teszi meg, akkor “Elkapok egy hibát: SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

És folytatjuk, nincs több jogosulatlan hozzáférés az adattárhoz. Tehát ez nagyon hasznos és hatalmas dolog.

Hozzászólások

• Köszönöm a remek választ. De azt gondolom, hogy a fő kérdés még mindig ott van. A HTTPS-nek valóban az alapértelmezett protokollnak kell lennie a webes és főleg a debian csomagok közötti átvitelnél. Az érvelésnek nem az kellene lennie, hogy miért a HTTPS, hanem miért nem?
• @aalizadeh, egyetértek veled, a https használatakor van rezsi, de nincs masszív rezsi. Azt gondolom, hogy a https nem az alapértelmezett szállítás, az az oka, hogy egyes szervezetek kifejezetten tiltják a titkosított forgalmat (mivel azt akarják, hogy az interneten keresztül bedugják az orrukat a dolgozók tevékenységéhez), ami azt jelenti, hogy a tárhelyeknek támogatniuk kell mind a http, mind a https transzport. Lehet, hogy vannak más szempontok is
• A » Verify-Host ” false “; « hibás, még saját aláírású tanúsítványok esetén is. Helyette ismernie kell ügyfeleit a (helyes) szerver tanúsítvánnyal.
• Valóban, de itt az ügyfeleim csak belső rendszerek voltak. Tehát ahelyett, hogy létrehoznám az összes megfelelő pki infrastruktúrát, kivágtam a sarkot. És igen, később a pki rendezése rendben volt, és a Verify-Host hamis; eltávolították. És igen, a pont érvényes.
• Az ubuntu xenial alkalmazással az apt csomagok kiváltságos felhasználóként kerülnek letöltésre _apt, kérjük, frissítse ezt a szálat a fájlengedélyezési problémák kezelésének vagy megoldásának részleteivel. >

Ne feledje, hogy olyan sebezhetőségek miatt, mint a

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

… ami megkerüli az InRelease aláírást, valószínűleg jó ötlet egyébként a HTTPS konfigurálása.

És ez nem egy példa – sok más, a HTTP-re alapértelmezett frissítési rendszernél is előfordult már aláírás-ellenőrzési hiba.

A biztonság szempontjából kritikus frissítési mechanizmusoknak a HTTPS és az aláírás ellenőrzése megbízható. Mindegyik enyhíti a másik kudarcát.

Megjegyzések

• És most ez is: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. Az InRelease aláírás nem elegendő . ” De az összes tükör HTTPS-be történő áthelyezése időbe és koordinációba fog kerülni! “. Igen. Indítás most. Ez nem lesz az utolsó InRelease hiba.
• Itt ‘ egy másik példa, egy másik ökoszisztémától – Alpine. Csomagkezelő rendszere ‘ alapértelmezés szerint nem használja a HTTPS-t, és kizárólag az aláírásra támaszkodik a csomag integritásának ellenőrzésére …és ennek az ellenőrzésnek volt egy távolról kihasználható hibája 2018 szeptemberében: justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine induljon el most áttérés alapértelmezés szerint a HTTPS használatára.
• (Teljes közzététel: a saját lényegem, de ‘ ez az egyetlen hivatkozás, amelyet ismerek of), itt van egy lista az ügyféloldali aláírás-ellenőrzési hibák összes hibájáról, amelyekről ‘ tudom. A lista nem triviális méretű, és rendszeresen növekszik. Üdvözletet ad hozzá. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004