¿Cómo usar https con apt-get?

51

¿ apt-getUtiliza https o algún tipo de cifrado? ¿Hay alguna forma de configurarlo para usarlo?

apt configuration encryption official-repositories https Strapakowsky
fuente
3
Tenga en cuenta que debido a vulnerabilidades como bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467 ... que elude la firma de InRelease, probablemente sea una buena idea configurar HTTPS de todos modos.
Royce Williams
whydoesaptnotusehttps.com es una página web que responde de manera precisa y extensa a esta pregunta.
m.raynal
1
Hay una razón más mundana por la que esto sería útil. A menudo estoy en una conexión a Internet con un proxy "transparente" roto que tiende a bloquear ciertas descargas de Deb (probablemente desencadenan un estúpido bloqueador de malware). Pero a través de https, el proxy no sabe lo que estoy descargando y, por lo tanto, no interfiere.
Nate Eldredge

Respuestas:

53

apt-get(y otros comandos de manipulación de paquetes, que son un front-end para las mismas bibliotecas APT) pueden usar HTTP, HTTPS y FTP (y sistemas de archivos montados). Si especifica https://URL en /etc/apt/sources.listy /etc/apt/sources.list.d/*, entonces APT usará HTTPS.

APT verifica la firma de los paquetes. Por lo tanto, no necesita tener una forma de transporte que proporcione autenticación de datos. Si un atacante modifica los archivos que está descargando, esto se notará. Usar una verificación de firma es mejor que usar una conexión HTTPS, porque detectará un ataque en el servidor desde el que está descargando, no solo un ataque en tránsito.

Más precisamente, el flujo de datos (simplificado) para un paquete es el siguiente:

  1. El paquete se produce en una máquina de construcción.
  2. El paquete está firmado en la máquina de compilación.
  3. El paquete firmado se copia en un espejo de descarga.
  4. Usted descarga el paquete.

HTTPS garantiza que el paso 4 se realice correctamente. Las firmas del paquete aseguran que los pasos 2 a 4 se realicen correctamente.

De hecho, hay un pequeño beneficio para HTTPS para el paso 4: las firmas del paquete solo aseguran que el paquete sea auténtico. Un atacante en el paso 4 podría hacerse pasar por un servidor legítimo y servir versiones obsoletas del paquete. Por ejemplo, el atacante podría evitar que descargue actualizaciones de seguridad, con la esperanza de explotar una vulnerabilidad en su máquina que habría reparado si no fuera por el ataque. Este no es un escenario muy realista, porque requiere un atacante activo (por lo que tendría que ser alguien que controle su conexión a Internet), pero en principio podría suceder.

El otro beneficio para HTTPS sería si intenta ocultar el hecho de que está descargando paquetes de Ubuntu de alguien que está husmeando en su conexión de red. Incluso entonces, el espía podría ver a qué host te estás conectando; Si se conecta a un espejo de Ubuntu y descarga cientos de megabytes, está claro que está descargando paquetes de Ubuntu. El espía también podría averiguar en su mayoría qué paquetes está descargando del tamaño de los archivos. Por lo tanto, HTTPS solo sería útil si está descargando desde un servidor que también ofrece otros archivos de tamaño similar: no veo ningún punto, excepto los paquetes de terceros, y solo en circunstancias muy inusuales.

Para reiterar: el beneficio habitual de HTTPS, que es que sabes que estás conectado al servidor real, es inútil cuando descargas paquetes de Ubuntu. La verificación de firma en los paquetes ofrece una garantía más sólida que la que HTTPS puede proporcionar.

Gilles 'SO- deja de ser malvado'
fuente
11
No es que sea menos seguro, es que es menos relevante para lo que está tratando de proteger. Con APT, cifrar el contenido de su transacción no es tan importante, porque lo que está descargando es muy controvertido: son los mismos paquetes de Ubuntu que muchas personas descargan. Pero lo importante es asegurarse de que los archivos a medida que los recibe no hayan sido alterados.
thomasrutter
3
Hace algunas semanas intenté cambiar las fuentes a https y simplemente no funcionó, apt-get updateinformaba un error al intentar acceder a los enlaces. Con ppas: lo mismo. ¿Alguien lo ha intentado?
Strapakowsky
8
El repositorio (servidor de actualización) debe ser compatible con https / SSL para que esto funcione. El principal archive.ubuntu.com no . Puede verificar en su navegador si un servidor lo admite con el prefijo https: // a la URL y ver si obtiene una lista de directorios, etc.
ish
77
"Un atacante en el paso 4 podría hacerse pasar por un servidor legítimo y servir versiones obsoletas del paquete". En realidad, protegemos contra esto al dar a la información del paquete una fecha de vencimiento. APT advertirá después de esta fecha que su espejo está obsoleto.
tumbleweed
44
Aquí hay una lista de los 15 espejos que admiten HTTPS junto con un script que genera la lista: pastebin.com/QY2TQ1dq
Shnatsel
13

Con APT, por lo general, lo más importante no es que su conexión esté encriptada, sino que los archivos que recibe no hayan sido alterados.

APT tiene verificación de firma incorporada para garantizar esto.

El cifrado evitaría que los espías puedan ver lo que está descargando, pero lo que realmente está descargando (y solicitando) es bastante controvertido: será lo mismo que miles de otros usuarios de Ubuntu están descargando y los archivos no contienen nada que no sea t disponible gratuitamente en muchos servidores. Aún así, si necesita privacidad sobre qué paquetes en particular está descargando, se puede usar HTTPS (especifíquelo en su lista sources.list).

La verificación de firma integrada en APT asegurará que los archivos que reciba no hayan sido alterados. Realmente no importa de dónde provienen los archivos e incluso es posible tener proxies o proxies inversos entre usted y el servidor para reducir la carga del servidor o acelerarlo. La verificación de la firma aún asegura que está obteniendo el archivo no modificado, que coincide con la firma que solo podría producirse criptográficamente con el archivo original y una copia de la clave privada de Ubuntu.

Si cambia a HTTPS, ya no podrá aprovechar los servidores proxy para acelerar el acceso o reducir la carga. Y no agregaría ninguna garantía más sobre la no manipulación que la verificación de firma de APT ya no brinda. Sin embargo, significaría que los espías (como su ISP) no podrán ver qué paquetes está descargando (lo que no es probable que sea confidencial, y como Gilles señaló que podían adivinar el tamaño del archivo).

thomasrutter
fuente
3
HTTPS no dará mucha privacidad, porque el tamaño de los archivos es visible. De hecho, hay un pequeño beneficio para HTTPS, que es que garantiza que un atacante que controle su conexión de red no pueda introducir silenciosamente datos obsoletos. Es un poco exagerado.
Gilles 'SO- deja de ser malvado'
66
Buenos puntos. Por "datos obsoletos" supongo que te refieres a un hombre en el medio que configura una versión del espejo de Ubuntu compuesta por versiones ligeramente anteriores, pero aún sin cambios de lo que Ubuntu había firmado en ese momento.
thomasrutter
55
Si eso es. No dudes en señalar si soy un poco jerga: tengo que tener en cuenta que esto es Ask Ubuntu y no Information Security .
Gilles 'SO- deja de ser malvado'
Parece que hay un gran agujero en apt: cuando usted apt updatey un hombre en el medio alimentan sus índices falsos, apt toma felizmente lo que el hombre en el medio le da y lo escribe en / var / lib / apt / lists. Esto no es solo con un hombre malvado en el medio, sino que si está en el WiFi del hotel y es redirigido a una página de inicio de sesión, si se ejecuta apt updateantes de iniciar sesión, sus listas / var / lib / apt / serán destruidas con la página de inicio del hotel HTML. ¡FALSO! De todos modos, la verificación básica del certificado TLS lo descartaría de inmediato.
Marius
@ Mario no se supone que esto sea posible debido a la verificación, que cubre las listas y los paquetes. Si ha reproducido esto con una instalación estándar de Apt, debe informarlo al mantenedor.
thomasrutter
1

Las versiones recientes de APT tienen compatibilidad con TLS incorporada, por lo que simplemente necesita reemplazar las URL httpsduplicadas de su repositorio de paquetes por otras con prefijo. Para Debian, podría verse así:

deb https://deb.debian.org/debian/ stretch main
deb https://deb.debian.org/debian-security stretch/updates main
deb https://deb.debian.org/debian/ stretch-updates main

Esto es útil, aunque APT incluye su propio protocolo de firma para garantizar que los paquetes no sean manipulados, ya que puede haber errores en APT (como ha habido: CVE-2016-1252 , CVE-2019-3462 ). Los protocolos HTTP / TLS y sus cifrados están sujetos a un escrutinio intenso, por lo que una vulnerabilidad severa de día cero es mucho menos probable si agrega esta capa de seguridad.

Leif Arne Storset
fuente
Vaya, solo ahora me doy cuenta de que este sitio es Ask Ubuntu. :) No pude encontrar una solución CDN similar para Ubuntu.
Leif Arne Storset
0

Creo que esta pregunta podría usar una respuesta con instrucciones para el lego, así que ...

APT todavía no usa HTTPS de manera predeterminada en las compilaciones diarias de Ubuntu 19.10 (Eoan) (que todavía está en desarrollo). Uno puede verificar esto examinando el archivo /etc/apt/sources.list y observando que todas las URL de origen utilizan el esquema de URL "http:".

Para configurarlo para usar HTTPS, se pueden seguir las siguientes instrucciones:

Primero , encuentre un espejo de archivo de Ubuntu oficial confiable que admita HTTPS:

  1. Vaya a la página web de archivos oficiales de Mirror for Ubuntu .
  2. En la tabla de esa página web, identifique los espejos que están (A) alojados en sitios web que considera confiables, (B) tienen un espejo "http:" y, opcionalmente, (C) cumplen con su proximidad geográfica, la velocidad del servidor y la actualización preferencias de frescura.
  3. En la tabla de esa página web, haga clic en el enlace "http" de un espejo identificado en el paso (2) para visitar la versión "http:" del espejo.
  4. En la barra de direcciones del navegador, cambie manualmente "http:" en la URL de la página web a "https:".
  5. Vaya al espejo nuevamente (a través de la URL "https:") para ver si se resuelve.

Por ejemplo, considero que la Fundación Wikimedia es confiable, por lo que visité la http://mirrors.wikimedia.org/ubuntu/ mirror URL y luego la cambié a https://mirrors.wikimedia.org/ubuntu/ , que se resuelve con éxito.

Si usa Firefox (67.0.4) y tiene instalada la extensión HTTPS Everywhere (2019.6.27) con la función "Cifrar todos los sitios elegibles" habilitada (a través del panel de botones de la barra de herramientas), se pueden omitir los pasos (4) y (5) porque la extensión modificará automáticamente la URL para utilizar HTTPS, lo que permite determinar de manera más inmediata si la versión "https:" de la URL se resolverá.

Dos , actualice su lista de fuentes APT:

  1. Ejecute el comando sudo cp /etc/apt/sources.list /etc/apt/sources.list.backuppara hacer una copia de seguridad de su lista de fuentes de actualización.
  2. Reemplace la URL base espejo (que se muestra aquí como https://mirrors.wikimedia.org) en el comando sudo sed --in-place --regexp-extended 's http://(us\.archive\.ubuntu\.com|security\.ubuntu\.com) https://mirrors.wikimedia.org g' /etc/apt/sources.listcon la URL base espejo de su espejo preferido y luego ejecute el comando.

En tercer lugar , debe examinar el contenido del directorio /etc/apt/sources.list.d/ para ver las fuentes "http:" que podrían cambiarse a "https:" después de instalar el software desde fuera del archivo de Ubuntu.

Por ejemplo, el paquete Visual Studio Code de Microsoft agrega un archivo vscode.list a este directorio que especifica una URL "http:". El simple cambio del esquema de URL de "http:" a "https:" permite actualizaciones a través de HTTPS.

Considere hacer una copia de seguridad de dichos archivos fuente antes de modificarlos.

Por último , realice una actualización para asegurarse de que las actualizaciones funcionen correctamente:

  1. Ejecute el sudo apt-get updatecomando
  2. Si eso no funciona como se esperaba, restaure los archivos de la lista fuente de respaldo que realizó ejecutando el sudo cp /etc/apt/sources.list.backup /etc/apt/sources.listcomando.

También vale la pena señalar que hay un paquete apt-transport-https para agregar soporte HTTPS a APT. Sin embargo, este paquete es aparentemente innecesario de acuerdo con la página web https://launchpad.net/ubuntu/eoan/+package/apt-transport-https y no ha sido necesario desde APT 1.5 de acuerdo con la información mostrada después de ejecutar el comando apt-cache show apt-transport-https.

Patrick Dark
fuente