He notado que al instalar paquetes desde apt, a veces hacemos 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 \
Si entiendo correctamente, lo que hacemos aquí es buscar una clave pública GPG de https://download.../gpgy colocarla en /usr/share/keyrings/docker-archive-keyring.gpg. Luego, le decimos apt: "cuando descargue paquetes, https://download.docker.com/...verifique que estos paquetes estén firmados por la clave privada que pertenece a esta clave pública".
Así que no lo entiendo del todo: si confiamos en que es Docker el que está al otro lado https://download.docker.com/.. (y lo hacemos, ya que de aquí es de donde obtenemos la clave pública), entonces ¿por qué necesitamos verificar los paquetes que vienen desde allí con una clave gpg? ?
Me parece un certificado autofirmado.
¿Me estoy perdiendo de algo?
Respuesta1
Esto se debe a múltiples razones, y todas giran en torno aEl hombre en el medio ataca(MITM): específicamente, lo protege de cualquier caso en el futuro en el que reciba un ataque MITM o algún otro tipo de redireccionamiento malicioso a "fuentes de descarga falsas".despuésTienes la buena llave.
Si se encuentra en la peor situación (su sistema ya está comprometido y redirigido a un sitio incorrecto para un actor malicioso ("MA" para abreviar), entonces está arruinado y esto no lo protege porque usted Estaremos descargando las claves de MA. Ese no es el objetivo de esta protección de la clave PGP y el llavero aquí, es protegerlo defuturoAtaques MITM.
En este ejemplo, usted ya está comprometido y la clave que esté en uso es irrelevante porque es probable que MA tenga el control de su computadora, red, datos, etc. en este momento. Sin embargo, el escenario de protección más común es ustedcomenzarcon un entorno/sistema limpio yentoncesinstalar software de la fuente legítima. (ver siguiente sección)
Sin embargo, partir de un entorno comprometido no es el "escenario común" contra el que se protegen las firmas clave. El escenario más común es: estás en un sistema limpio, con actualizaciones limpias, sin comprometer tu sistema, los servidores DNS que usas, la red a la que estás conectado, etc.
Vaya a instalar Docker y obtenga la clave de Docker del sitio web real de Docker. Luego instala Docker y la clave se valida.
En algún momento en el futuro, MA tomó el control de cómo fluye su tráfico a Internet y lo redirigió a un sitio de descarga de Docker "falso".
A menos que MA haya robado la clave PGP de Docker con su correspondiente clave privada, su aptsistema mostrará que las firmas endownload.docker.com no coincideny que algo extraño está sucediendo en su entorno y no aplicará las actualizaciones de la redirección del repositorio "malo" de MA.
Estees contra lo que protegen la firma de claves y las partes clave: que usted sea MITM en elfuturo. No te protege si ya estás comprometido, nada lo hará. Te protege cuando empiezas de forma limpia y sin concesiones y luegoconvertirsecomprometido por alguna razón.
Esta es también la razón por la que debe verificar las huellas digitales de las claves con las huellas dactilares de claves en buen estado. La mayoría de los buenos proveedores de repositorios tienen sus huellas digitales disponibles para su validación manual, de modo que no dependa SOLO de comandos para obtener y confiar en las claves.