Conforme declarado na pergunta anterior: Como posso forçar o apt-get ou o apt a usar apenas conexões https
deb https://deb.debian.org/debian bookworm main
deb https://security.debian.org/debian-security bookworm/updates main
deb https://deb.debian.org/debian bookworm-updates main
security.debian.org não funciona se eu usar o protocolo https.
Com o Ubuntu, tenho problemas semelhantes na atualização do cache do apt-get com o protocolo https.
Agora, não é considerado um grande problema de segurança usar http simples para baixar atualizações para o seu sistema operacional?
Estou coçando a cabeça para entender por que em 2023 o http simples ainda é considerado usado fora de alguns ambientes de teste. O main pesado no meio e a confusão de pacotes não podem ser transportados para que os pacotes criados possam ser despachados e instalados nas máquinas dos usuários?
O Debian e seus derivados não dependem de TLS para garantir a entrega de pacotes, eles dependem de assinaturas de chaves OpenPGP, usando chaves já existentes no sistema (configuradas durante a instalação ou adicionadas pelo administrador do sistema). Isso abrange metadados e conteúdo de pacotes; veja Como a autenticidade dos pacotes Debian é garantida? para detalhes.
O outro recurso comumente solicitado fornecido pelo TLS é a confidencialidade, ou seja , qualquer pessoa capaz de espionar seu tráfego não poderá determinar o que você está fazendo. Não tenho os links em mãos, mas descobri que o TLS não é suficiente para ocultar significativamente a atividade de download de pacotes - os tamanhos de transferência são suficientes para determinar quais pacotes estão sendo baixados na maioria dos casos.
Portanto, o TLS adiciona integridade, que o Debian já fornece, e poderia adicionar confidencialidade, mas na prática não o faz. Ele também adiciona alguma sobrecarga e torna mais complicado armazenar dados em cache (o que é extremamente útil para repositórios de pacotes de distribuição); então o Debian não o configura por padrão.
Existe um recurso do TLS que não é suportado em todos os casos nos repositórios Debian: resistência a ataques de repetição. Em um cenário man-in-the-middle, sem TLS, um cliente pode receber versões mais antigas de metadados de repositório e pacotes associados, que podem ser usados para manter um sistema vulnerável. Repositórios Debian com atualizações frequentes (notadamente, as “atualizações” e suítes de segurança) produzem metadados que são válidos apenas por uma semana, evitando replays além disso; mas os lançamentos pontuais estáveis são válidos até que sua chave de assinatura expire, portanto, um sistema de destino pode ser mantido artificialmente em um lançamento pontual mais antigo. (No entanto, em sua configuração padrão, ele ainda veria atualizações de segurança nesse tipo de cenário.)
É claro que a defesa em profundidade é melhor e houve vulnerabilidades no passado que teriam sido mitigadas pelo TLS; portanto, o TLS pode ser habilitado com a maioria dos repositórios.
No que diz respeito às melhores práticas:
apterros (mas não deixe que eu o impeça de ativar o TLS, se desejar);