
Percebi que ao instalar pacotes do apt
, às vezes fazemos algo como:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
Se bem entendi, o que fazemos aqui é buscar uma chave pública GPG https://download.../gpg
e colocá-la em /usr/share/keyrings/docker-archive-keyring.gpg
. Então, dizemos ao apt - "ao baixar pacotes de https://download.docker.com/...
verifique se esses pacotes estão assinados pela chave privada pertencente a esta chave pública".
Então, não entendo muito bem: se confiamos que é o Docker do outro lado https://download.docker.com/..
- e confiamos, já que é de onde obtemos a chave pública - então por que precisamos verificar os pacotes vindos de lá com uma chave gpg ?
Parece um certificado autoassinado para mim.
Estou faltando alguma coisa aqui?
Responder1
Isso ocorre por vários motivos, e todos eles giram em tornoAtaques do homem no meio(MITM) - especificamente, protegendo você de qualquer caso no futuro em que você seja atingido por um ataque MITM ou algum outro tipo de redirecionamento malicioso para 'fontes de download falsas'depoisvocê conseguiu a chave boa.
Se você estiver na pior situação - seu sistema já está comprometido e redirecionado para um site mal-intencionado por um ator mal-intencionado ("MA" para abreviar) - então você está preso e isso não o protege porque você ' estarei baixando as chaves do MA. Esse não é o objetivo desta proteção da chave PGP e do chaveiro aqui, é para protegê-lo defuturoAtaques MITM.
Neste exemplo, você já está comprometido e qual chave está em uso é irrelevante porque o MA provavelmente tem controle do seu computador, rede, dados, etc. neste momento. O cenário de proteção mais comum, entretanto, é vocêcomeçarcom um ambiente/sistema limpo eentãoinstale software de fonte legítima. (veja a próxima seção)
No entanto, partir de um ambiente comprometido não é o “cenário comum” contra o qual as principais assinaturas protegem. O cenário mais comum é: você está em um sistema limpo, com atualizações limpas, sem comprometer seu sistema, os servidores DNS que você usa, a rede à qual está conectado, etc.
Você vai instalar o Docker e obter a chave do Docker no site real do Docker. Em seguida, você instala o Docker e a chave é validada.
Em algum momento no futuro, MA assumiu o controle de como seu tráfego flui para a Internet e redirecionou você para um site de download ‘falso’ do Docker.
A menos que o MA tenha roubado a chave PGP do Docker com sua chave privada correspondente, seu apt
sistema mostrará que as assinaturas nodownload.docker.com
não combinae que algo estranho está acontecendo em seu ambiente e não aplicará as atualizações do redirecionamento de repositório 'ruim' do MA.
Esseé contra o que a assinatura de chave e as partes principais protegem: você sendo MITM nofuturo. Isso não protege você se você já estiver comprometido, nada o protegerá. Ele protege você quando você começa limpo e descomprometido e depoistornar-secomprometido por algum motivo.
É também por isso que você deve verificar as impressões digitais das chaves em relação às impressões digitais das chaves em boas condições. A maioria dos bons provedores de repositórios tem suas impressões digitais prontamente disponíveis para validação manual, para que você não dependa APENAS de comandos para obter e confiar nas chaves.