Perché non esiste un trasporto https per lo strumento debian apt?

Con tutta la paranoia fornita con le rivelazioni dell'NSA e tutto il resto, mi chiedo perché il meccanismo di installazione del pacchetto debian non supporti HTTPS per il suo trasporto, e tanto meno usarlo per impostazione predefinita.

So che i pacchetti debian hanno una sorta di convalida della firma usando GPG, ma ancora non penso che usare il trasporto HTTPS invece di HTTP sia troppo difficile, considerando quanto sia cruciale dal punto di vista della sicurezza.

Modifica: principalmente voglio proteggermi dagli attacchi MitM (incluso solo lo sniffing del traffico), non dagli amministratori di mirror debian. I repository HTTP mettono l'intera configurazione del sistema sul tavolo, se qualcuno si sporge sul mio traffico andando ai mirror debian.

C'è. Devi installare il pacchetto apt-transport-https. Quindi puoi usare linee come

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

nel tuo sources.listfile. Ma di solito non è necessario, poiché l'intero contenuto è comunque pubblico e aggiunge sovraccarico e latenza di crittografia. Poiché non ti fidi di una chiave pubblica degli aggressori, anche il traffico http è al sicuro dagli attacchi MitM. aptavviserà l'utente e non installerà 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 l'utilizzo di apt su repository non crittografati può effettivamente comportare un rischio per la sicurezza in quanto il trasporto HTTP è vulnerabile agli attacchi di replay.

La tua ipotesi è errata: puoi utilizzare i download HTTPS. Devi solo trovare un mirror che lo supporti e inserire il suo URL nel tuo elenco di fonti. Dovrai installare il apt-transport-httpspacchetto.

Debian non semplifica i download di HTTPS perché i vantaggi sono pochi. 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 verso un server con pacchetti danneggiati, il danneggiamento verrà rilevato perché le firme GPG non saranno valide. L'uso di GPG anziché HTTPS ha il vantaggio di proteggere da più minacce: non solo contro l'attivo man-in-the-middle sulla connessione dell'utente finale, ma anche contro un mirror non autorizzato o infetto o altri problemi in qualsiasi punto della catena di distribuzione dei pacchetti .

HTTPS offre un leggero vantaggio in termini di privacy in quanto oscura i pacchetti scaricati. Tuttavia un osservatore passivo può ancora rilevare il traffico tra il tuo computer e un server di pacchetti, quindi saprebbero che stai scaricando i pacchetti Debian. Potrebbero anche avere una buona idea di quali pacchetti si stanno scaricando dalle dimensioni del file.

L'unico punto in cui HTTPS sarebbe di aiuto è la fiducia nell'avvio del boot, per ottenere un'immagine di installazione valida e nota. Debian non sembra fornire questo: ci sono checksum dei supporti di installazione , ma solo su HTTP.

Proprio di recente ho riscontrato il problema con il repository apt della mia azienda. Il problema era che se usiamo il trasporto http standard chiunque altro può ottenere facilmente il pacchetto. Poiché la società sta confezionando il proprio software proprietario e non desidera condividerlo con tutti, il trasporto http diventa un problema. Non una tragedia ma un problema. Esistono due modi per limitare l'accesso al pacchetto: firewalling, limitazione dell'accesso a livello di server Web, utilizzo di ssh come trasporto. Si può trovare abbastanza facile da leggere su questo argomento qui: Limitare l'accesso al proprio repository Debian privato

Nel nostro caso, abbiamo deciso di utilizzare https transport + autenticazione certificato client. In breve, tutto ciò che serve è:

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

2. Configurare il server web che repository di fronti 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 su / etc / apt / ssl e, nel caso con 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 stai utilizzando un certificato autofirmato, è importante disattivare la verifica dell'host: in Verify-Host "false";caso contrario, verrà visualizzato 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.

Si noti che a causa di vulnerabilità simili

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

... che elude la firma di InRelease, è probabilmente una buona idea configurare HTTPS comunque.

Per il caso d'uso "anonimato" esiste anche un altro apt-transport-torche consente di inserire gli URI come tor+http://nei file sources.list. Questa è una protezione molto migliore dell'anonimato 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 può fare qualche ipotesi decente su quale di quelli che stai facendo (e possibilmente anche su quali pacchetti, in base alle dimensioni).

Debian fornisce repository APT tramite Tor "Onion services" in modo da poter ottenere la crittografia end-to-end (simile a TLS) senza affidarsi al sistema dei nomi di dominio. Vedi onion.debian.org per tutti i servizi Debian disponibili in questo modo. Il principale repository FTP Debian è suvwakviie2ienjx6t.onion