Perché non esiste il trasporto https per debian apt tool?

Cè. Devi installare il pacchetto apt-transport-https . Quindi puoi utilizzare righe come

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

nel tuo file sources.list. Ma di solito non è necessario, poiché lintero contenuto è comunque pubblico e aggiunge un sovraccarico di crittografia e latenza. Poiché non ti fidi della chiave pubblica di un aggressore, anche il traffico http è al sicuro dagli attacchi MitM. apt ti avviserà e non riuscirà a installare i pacchetti quando un utente malintenzionato inietta pacchetti manipolati.

EDIT: come menzionato nei commenti, è davvero più sicuro usare il Repository TLS . La ricerca mostra che lutilizzo di apt su repository non crittografati può effettivamente rappresentare un rischio per la sicurezza poiché il trasporto HTTP è vulnerabile agli attacchi di replay.

Commenti

• No, la maggior parte dei mirror non supporta https. Semplicemente perché ‘ non ha molto senso crittografare questo tipo di traffico. I pacchetti vengono comunque verificati e le informazioni sono pubbliche.
• Posso pensare a un paio di motivi per cui potrei ancora preferire il download tramite TLS: 1) potrei preoccuparmi della mia privacy durante linstallazione dei pacchetti e 2) lì potrebbero essere bug nel codice di controllo della firma del pacchetto, che un MITM potrebbe sfruttare.
• @JackO ‘ Connor, mentre la prima obiezione sulla privacy è comprensibile, la seconda è come dire che mi piace che i siti web firmino i loro contenuti con chiavi PGP perché potrebbero esserci bug nel codice TLS. Sia PGP che TLS stabiliscono la fiducia; non ‘ ti servono entrambi per questo.
• @Marco la tua risposta non è corretta; numerosi documenti di ricerca hanno dimostrato che i repository APT e YUM sono vulnerabili agli attacchi di riproduzione quando si accede al repository tramite HTTP, anche con firme GPG. È possibile accedere ai repository solo tramite TLS, il 100% delle volte.
• Ecco il documento a cui fa riferimento @Joe Damato – vedi anche il suo rispondi qui

Il tuo il presupposto è sbagliato: puoi usare i download HTTPS. Devi solo trovare un mirror che lo supporti e inserire il suo URL nel tuo elenco di fonti. Dovrai installare il pacchetto apt-transport-https .

Debian non crea HTTPS download facile perché il vantaggio è minimo. La distribuzione dei pacchetti Debian include già un meccanismo per verificare i pacchetti: tutti i pacchetti sono firmati con Gpg . Se un man-in-the-middle attivo reindirizza il tuo traffico a un server con pacchetti danneggiati, il danneggiamento verrà rilevato perché le firme GPG non saranno valide. Luso di GPG invece di HTTPS ha il vantaggio di proteggere da più minacce: non solo contro un man-in-the-middle attivo sulla connessione dellutente finale, ma anche contro un mirror non autorizzato o infetto o altri problemi ovunque nella catena di distribuzione dei pacchetti.

HTTPS fornisce un leggero vantaggio sulla privacy in quanto oscura i pacchetti che scarichi, tuttavia un osservatore passivo può ancora rilevare il traffico tra il tuo computer e un server di pacchetti, in modo che sappia che stai scaricando pacchetti Debian. Potrebbero anche avere una buona idea di quali pacchetti stai scaricando dalle dimensioni dei file.

Lunico posto in cui HTTPS potrebbe aiutare è per il bootstrap della fiducia, per ottenere unimmagine di installazione valida nota. Debian non lo fa “. Non sembra fornire questo: esistono checksum del supporto di installazione , ma solo su HTTP.

Commenti

• Esiste una versione HTTPS del supporto di installazione: cdimage.debian.org/debian -cd
• Pochissimo vantaggio? Che dire di justi.cz/security/2019/01/22/apt-rce.html ?
• @AaronFranke Un bug specifico che è più facile da sfruttare con HTTP che con HTTPS conta un vantaggio minimo, sì. ‘ non è come se HTTP avesse una superficie di attacco maggiore di HTTPS: infatti HTTPS stesso ha una superficie di attacco maggiore poiché coinvolge più codice. Quindi non è ‘ nemmeno un vantaggio netto: è ‘ un compromesso tra due rischi marginali.

Di recente ho affrontato il problema con il repository apt della mia azienda. Il problema era che se usiamo lo standard http trasporto chiunque altro può ottenere il pacchetto facilmente. Poiché la società sta impacchettando il proprio software proprietario e non vuole condividerlo con tutti, il trasporto http diventa un problema. Non una tragedia ma un problema. Ci sono un paio di modi per limitare laccesso al pacchetto – firewalling, limitando laccesso a livello di server web, utilizzando ssh come trasporto. La lettura abbastanza facile da consumare su questo argomento può essere trovata qui: Limita laccesso al tuo repository Debian privato

Nel nostro caso, abbiamo deciso di utilizzare il trasporto https + lautenticazione del certificato client. In breve, tutto ciò che serve è:

1. Preparare certificati autofirmati, client e server (utilizzando easy-rsa);

2. Configura il server web che fa da fronte al repository per accettare solo https; In caso di nginx potrebbe apparire come:

   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. Metti il certificato client, la chiave client e il certificato CA in / etc / apt / ssl e, nel caso di Ubuntu, aggiungi il file 00https a /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"; };

Tieni presente che se utilizzi un certificato autofirmato è importante disattivare la verifica dellhost: Verify-Host "false"; Se non lo fai, “Verrà rilevato un errore: SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

E qui andiamo, non cè più accesso non autorizzato al repository. Quindi questa è una cosa abbastanza utile e potente.

Commenti

• Grazie per lottima risposta. Ma penso che il problema principale sia ancora lì. HTTPS dovrebbe davvero diventare il protocollo predefinito per i trasferimenti sul web e in particolare per i pacchetti Debian. Largomento non dovrebbe essere perché HTTPS, dovrebbe essere perché no?
• @aalizadeh, sono daccordo con te, cè un sovraccarico quando si usa https, ma non cè un sovraccarico enorme. Penso che il motivo principale per cui https non sia un trasporto predefinito è che alcune organizzazioni vietano esplicitamente qualsiasi traffico crittografato (poiché vogliono essere in grado di ficcare il naso in ciò che i dipendenti stanno facendo su Internet), il che significa che i repository devono supportare trasporti sia http che https. Potrebbero esserci altre considerazioni
• Utilizzo di » Verify-Host ” false “; « è sbagliato, anche con certificati autofirmati. Devi invece rendere i tuoi clienti consapevoli del (corretto) certificato del server.
• In effetti, ma qui i miei clienti erano solo sistemi interni. Quindi, invece di creare tutta linfrastruttura pki adeguata, ho tagliato langolo. E sì, in seguito pki è stato regolato correttamente e Verify-Host falso; è stato rimosso. E sì, il punto è valido.
• con ubuntu xenial i pacchetti apt vengono recuperati come utente non privilegiato _apt, puoi aggiornare questo thread con i dettagli su come hai gestito o risolto i problemi di autorizzazione dei file.

Nota che a causa di vulnerabilità come

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

… che aggira la firma InRelease, è probabilmente una buona idea configurare HTTPS comunque.

E questo non è “un singolo esempio: molti altri sistemi di aggiornamento impostati su HTTP per impostazione predefinita hanno anche avuto una cronologia di errori di verifica della firma.

I meccanismi di aggiornamento critico per la sicurezza dovrebbero utilizzare sia HTTPS che verifica della firma per essere robusto. Ciascuno mitiga il fallimento dellaltro.

Commenti

• E ora anche questo: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. La firma InRelease non è sufficiente . ” Ma spostare tutti i mirror su HTTPS richiederà tempo e coordinamento! “. Sì. Parti ora. Questo non sarà lultimo errore di InRelease.
• Ecco ‘ s un altro esempio, da un ecosistema diverso: Alpine. Il suo sistema di gestione dei pacchetti ‘ non utilizza HTTPS per impostazione predefinita e si basa esclusivamente sulla firma per verificare lintegrità del pacchetto …e quella verifica aveva un bug sfruttabile da remoto nel settembre 2018: justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine dovrebbe iniziare passando ora allutilizzo di HTTPS per impostazione predefinita.
• (Divulgazione completa: la mia sintesi, ma ‘ è lunico riferimento che conosco di), ecco un elenco di tutti gli errori di verifica della firma lato client di cui ‘ sono a conoscenza. Lelenco è di dimensioni non banali e cresce regolarmente. Aggiunge il benvenuto. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004

Per il caso duso” anonimato “cè anche apt-transport-tor che ti consente di inserire URI come tor+http:// file sources.list. Questa è una protezione dallanonimato molto migliore rispetto alla semplice crittografia della connessione al tuo mirror.

Ad esempio, un osservatore locale saprebbe ancora che stai aggiornando o installando software anche con HTTPS e probabilmente potrebbe fare delle ipotesi decenti su quale di quelli stai “facendo (e possibilmente anche quali pacchetti, in base alle dimensioni).

Debian fornisce i repository APT tramite Tor” Onion services “in modo da poter ottenere la crittografia end-to-end a TLS) senza doversi fidare del sistema dei nomi di dominio. Vedere onion.debian.org per tutti i servizi Debian disponibili in questo modo. Il repository FTP principale di Debian si trova in vwakviie2ienjx6t.onion