Por que não há transporte https para a ferramenta debian apt?

Existe. Você precisa instalar o pacote apt-transport-https . Então, você pode usar linhas como

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

em seu arquivo sources.list. Mas geralmente isso não é necessário, já que todo o conteúdo é público de qualquer maneira e adiciona sobrecarga de criptografia e latência. Como você não confia na chave pública do invasor, até mesmo o tráfego http está protegido contra ataques MitM. apt irá avisá-lo e falhar ao instalar os pacotes quando um invasor injetar pacotes manipulados.

EDITAR: Como mencionado nos comentários, é realmente mais seguro usar o Repositório TLS . Pesquisas mostram que usar apt em repositórios não criptografados pode representar um risco de segurança, pois o transporte HTTP é vulnerável a ataques de repetição.

Comentários

• Não, a maioria dos mirrors não suporta https. Simplesmente porque não ‘ não faz muito sentido criptografar esse tipo de tráfego. Os pacotes estão sendo verificados de qualquer maneira e as informações são públicas.
• Posso pensar em alguns motivos pelos quais ainda posso preferir baixar por TLS: 1) Posso me preocupar com minha privacidade ao instalar pacotes e 2) lá podem ser bugs no código de verificação de assinatura do pacote, que um MITM poderia explorar.
• @JackO ‘ Connor, enquanto a primeira objeção sobre privacidade é compreensível, a segunda é como dizer que gosto de sites que assinem seu conteúdo com chaves PGP porque pode haver bugs no código TLS. PGP e TLS estabelecem confiança; você não ‘ não precisa de ambos para isso.
• @Marco sua resposta está incorreta; vários artigos de pesquisa mostraram que os repositórios APT e YUM são vulneráveis a ataques de repetição quando o repositório é acessado via HTTP, mesmo com assinaturas GPG. Repositórios só devem ser acessados via TLS, 100% do tempo.
• Aqui está o artigo ao qual @Joe Damato se refere – veja também o seu responda aqui

Seu suposição está errada: você pode usar downloads HTTPS. Você só precisa encontrar um espelho que o suporte e colocar sua URL em sua lista de fontes. Você precisará instalar o pacote apt-transport-https .

O Debian não faz HTTPS downloads fáceis porque há muito poucos benefícios. A distribuição de pacotes Debian já inclui um mecanismo para verificar os pacotes: todos os pacotes são assinados com Gpg . Se um man-in-the-middle ativo redirecionar seu tráfego para um servidor com pacotes corrompidos, a corrupção será detectada porque as assinaturas GPG não serão válidas. Usar GPG em vez de HTTPS tem a vantagem de proteger contra mais ameaças: não apenas contra man-in-the-middle ativo na conexão do usuário final, mas também contra um espelho não autorizado ou infectado ou outros problemas em qualquer lugar na cadeia de distribuição do pacote.

O HTTPS oferece uma pequena vantagem de privacidade na medida em que obscurece os pacotes que você baixa. No entanto, um observador passivo ainda pode detectar o tráfego entre o seu computador e um servidor de pacotes, então eles saberão que você está baixando pacotes Debian. Eles também podem ter uma boa idéia de quais pacotes você “está baixando a partir dos tamanhos de arquivo.

O único lugar onde o HTTPS ajudaria é no bootstrapping trust, para obter uma imagem de instalação válida. O Debian não” parecem fornecer isso: há somas de verificação da mídia de instalação , mas apenas sobre HTTP.

Comentários

• Há uma versão HTTPS da mídia de instalação: cdimage.debian.org/debian -cd
• Muito pouco benefício? E quanto a justi.cz/security/2019/01/22/apt-rce.html ?
• @AaronFranke Um bug específico que é mais fácil de explorar com HTTP do que com HTTPS conta com um pequeno benefício, sim. Não ‘ é como se o HTTP tivesse uma superfície de ataque maior do que o HTTPS: na verdade, o próprio HTTPS tem uma superfície de ataque maior, pois envolve mais código. Portanto, não é ‘ nem mesmo um benefício líquido: é ‘ uma compensação entre dois riscos marginais.

Recentemente, descobri o problema com o repositório apt da minha empresa. O problema era que, se usarmos http padrão transporte qualquer outra pessoa pode obter o pacote facilmente. Como a empresa está empacotando seu próprio software proprietário e não quer compartilhá-lo com todos, o transporte http se torna um problema. Não é uma tragédia, mas um problema. Existem algumas maneiras de limitar o acesso ao pacote – firewalling, restringindo o acesso no nível do servidor web, usando ssh como um transporte. Uma leitura bastante fácil de consumir sobre este tópico pode ser encontrada aqui: Restringir o acesso ao seu repositório Debian privado

No nosso caso, decidimos usar o transporte https + autenticação de certificado de cliente. Resumidamente, tudo o que precisamos é:

1. Preparar certificados autoassinados, cliente e servidor (usando easy-rsa);

2. Configure o servidor da web que faz frente ao repositório para aceitar apenas https; No caso do nginx, pode ser parecido com:

   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. Coloque o certificado do cliente, a chave do cliente e o certificado ca em / etc / apt / ssl e, no caso do Ubuntu, adicione o arquivo 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"; };

Lembre-se de que, se você estiver usando um certificado autoassinado, é importante desligar a verificação de host: Verify-Host "false"; Se você não fizer isso, você “Vou pegar um erro: SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

E lá vamos nós, não há mais acesso não autorizado ao repositório. Portanto, isso é uma coisa bastante útil e poderosa.

Comentários

• Obrigado pela ótima resposta. Mas acho que o problema principal ainda está lá. HTTPS realmente deve se tornar o protocolo padrão para transferências pela web e pacotes debian em particular. O argumento não deveria ser por que HTTPS, deveria ser por que não?
• @aalizadeh, concordo com você, há sobrecarga ao usar https, mas não há sobrecarga massiva. Acho que a principal razão pela qual o https não é um transporte padrão é que algumas organizações proíbem explicitamente qualquer tráfego criptografado (já que querem poder meter o nariz no que os funcionários estão fazendo na Internet), o que significa que os repositórios devem oferecer suporte transportes http e https. Pode haver outras considerações
• Usando » Verify-Host ” false “; « está errado, mesmo com certificados autoassinados. Você precisa informar seus clientes sobre o certificado do servidor (correto).
• Certamente, mas aqui meus clientes eram apenas sistemas internos. Então, em vez de criar toda a infraestrutura de pki adequada, eu cortei o canto. E sim, mais tarde o pki foi resolvido corretamente e o Verify-Host falso; foi removido. E sim, o ponto é válido.
• com ubuntu xenial os pacotes apt são obtidos como usuário sem privilégios _apt, você pode atualizar este tópico com detalhes sobre como você gerencia ou resolveu os problemas de permissão de arquivo.

Observe que devido a vulnerabilidades como

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

… que contorna a assinatura InRelease, provavelmente é uma boa ideia configurar HTTPS de qualquer maneira.

E este não é um único exemplo – muitos outros sistemas de atualização que assumem como padrão HTTP também têm um histórico de falhas na verificação de assinatura.

Os mecanismos de atualização de segurança crítica devem usar HTTPS e verificação de assinatura para ser robusta. Cada um atenua a falha do outro.

Comentários

• E agora este também: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. A assinatura InRelease não é suficiente . ” Mas mover todos os espelhos para HTTPS exigirá tempo e coordenação! “. sim. Comece agora. Esta não será a última falha do InRelease.
• Aqui ‘ está outro exemplo, de um ecossistema diferente – Alpine. Seu sistema de gerenciamento de pacotes não ‘ não usa HTTPS por padrão e depende apenas da assinatura para verificar a integridade do pacote …e essa verificação teve um bug que pode ser explorado remotamente em setembro de 2018: justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine deve começar mudar agora para usar HTTPS por padrão.
• (Divulgação completa: minha própria essência, mas ‘ é a única referência que conheço de), aqui está uma lista de todas as falhas de verificação de assinatura do lado do cliente que ‘ estou ciente. A lista não é trivial em tamanho e cresce regularmente. Adiciona boas-vindas. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004

Para o caso de uso de” anonimato “, há também apt-transport-tor, que permite que você coloque URIs como tor+http:// em arquivos sources.list. Esta é uma proteção de anonimato muito melhor do que simplesmente criptografar a conexão com seu espelho.

Por exemplo, um observador local ainda saberia que você está atualizando ou instalando software mesmo com HTTPS, e provavelmente pode fazer algumas suposições decentes sobre quais dos que você está fazendo (e possivelmente até quais pacotes, com base no tamanho).

O Debian fornece repositórios APT via Tor “serviços” para que você possa obter criptografia ponta a ponta (semelhante para TLS) sem ter que confiar no sistema de nomes de domínio. Veja onion.debian.org para todos os serviços Debian disponíveis desta forma. O principal repositório de FTP do Debian está em vwakviie2ienjx6t.onion