¿Por qué no hay transporte https para la herramienta debian apt?

45

Con toda la paranoia que ha venido con las revelaciones de la NSA y todo, me pregunto por qué el mecanismo de instalación de paquetes de Debian no admite HTTPS para su transporte, y mucho menos usarlo de forma predeterminada.

Sé que los paquetes de Debian tienen algún tipo de validación de firma usando GPG, pero todavía no creo que usar el transporte HTTPS en lugar de HTTP sea demasiado difícil, considerando lo crucial que es esto en cuanto a seguridad.

Editar: Principalmente quiero protegerme de los ataques de MitM (incluyendo solo el rastreo del tráfico), no de los administradores espejo de Debian. Los repositorios HTTP ponen toda la configuración del sistema sobre la mesa, si alguien espía mi tráfico yendo a los espejos de Debian.

zaadeh
fuente
no es necesario ... es contenido público ... los paquetes tienen sumas de verificación firmadas
Skaperen
ok, así que no desea que su administrador de red sepa qué paquetes instala / actualiza.
Skaperen
administradores, o cualquier otro espía.
zaadeh

Respuestas:

49

Ahi esta. Necesitas instalar el paquete apt-transport-https. Entonces puedes usar líneas como

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

en tu sources.listarchivo Pero generalmente eso no es necesario, ya que todo el contenido es público de todos modos y agrega sobrecarga de cifrado y latencia. Dado que no confía en la clave pública de un atacante, incluso el tráfico http está a salvo de los ataques de MitM. aptle advertirá y no instalará los paquetes cuando un atacante inyecte paquetes manipulados.

EDITAR: Como se menciona en los comentarios, de hecho es más seguro usar el repositorio TLS . La investigación muestra que el uso de apt en repositorios sin cifrar puede representar un riesgo de seguridad ya que el transporte HTTP es vulnerable a los ataques de repetición.

Marco
fuente
77
No, la mayoría de los espejos no son compatibles con https. Simplemente porque no tiene mucho sentido cifrar este tipo de tráfico. Los paquetes se están verificando de todos modos y la información es pública.
Marco
44
Puedo pensar en un par de razones por las que aún podría preferir descargar sobre TLS: 1) Me podría importar mi privacidad al instalar paquetes, y 2) podría haber errores en el código de verificación de firma del paquete, que un MITM podría explotar.
Jack O'Connor
2
@ JackO'Connor, mientras que la primera objeción sobre la privacidad es comprensible, la segunda es como decir que me gusta que los sitios web firmen sus contenidos con claves PGP porque puede haber errores en el código TLS. Tanto PGP como TLS establecen confianza; No necesitas ambos para eso.
Paul Draper
77
@Marco tu respuesta es incorrecta; numerosos trabajos de investigación han demostrado que los repositorios APT y YUM son vulnerables a los ataques de reproducción cuando se accede al repositorio a través de HTTP, incluso con firmas GPG. Solo se debe acceder a los repositorios a través de TLS, el 100% del tiempo.
Joe Damato
66
Aquí está el artículo al que se refiere @Joe Damato - también vea su respuesta aquí
SauceCode
17

Su suposición es incorrecta: puede usar descargas HTTPS. Solo tiene que encontrar un espejo que lo admita y poner su URL en su lista de fuentes. Deberá instalar el apt-transport-httpspaquete.

Debian no facilita las descargas HTTPS porque hay muy pocos beneficios. La distribución de paquetes de Debian ya incluye un mecanismo para verificar paquetes: todos los paquetes están firmados con Gpg . Si un hombre en el medio activo redirige su tráfico a un servidor con paquetes dañados, la corrupción se detectará porque las firmas GPG no serán válidas. El uso de GPG en lugar de HTTPS tiene la ventaja de que protege contra más amenazas: no solo contra el intermediario activo en la conexión del usuario final, sino también contra un espejo malintencionado o infectado u otros problemas en cualquier parte de la cadena de distribución del paquete .

HTTPS proporciona una ligera ventaja de privacidad, ya que oscurece los paquetes que descargas. Sin embargo, un observador pasivo aún puede detectar el tráfico entre su computadora y un servidor de paquetes, por lo que sabrán que está descargando paquetes de Debian. También podrían tener una buena idea de qué paquetes está descargando desde los tamaños de archivo.

El único lugar donde HTTPS ayudaría es para la confianza de arranque, para obtener una imagen de instalación válida válida. Debian no parece proporcionar eso: hay sumas de comprobación de los medios de instalación , pero solo a través de HTTP.

Gilles 'SO- deja de ser malvado'
fuente
Hay una versión HTTPS de los medios de instalación: cdimage.debian.org/debian-cd
Fedir RYKHTIK
2
Muy poco beneficio? ¿Qué pasa con justi.cz/security/2019/01/22/apt-rce.html ?
Aaron Franke
@AaronFranke Un error específico que es más fácil de explotar con HTTP que con HTTPS cuenta con muy pocos beneficios, sí. No es como si HTTP tuviera una superficie de ataque más grande que HTTPS: de hecho, HTTPS tiene una superficie de ataque más grande ya que involucra más código. Por lo tanto, ni siquiera es un beneficio neto: es una compensación entre dos riesgos marginales.
Gilles 'SO- deja de ser malvado'
9

Hace poco me encontré con el problema con el repositorio apto de mi empresa. El problema era que si usamos el transporte http estándar, cualquier otra persona puede obtener el paquete fácilmente. Como la Compañía está empaquetando su propio software propietario y no quiere compartirlo con todos, el transporte http se convierte en un problema. No es una tragedia sino un problema. Hay un par de formas de limitar el acceso al paquete: cortafuegos, restricción del acceso a nivel de servidor web, utilizando ssh como transporte. Aquí puede encontrar una lectura bastante fácil de consumir sobre este tema: Restrinja el acceso a su repositorio privado de Debian

En nuestro caso, decidimos usar https transporte + autenticación de certificado de cliente. Brevemente, todo lo que se necesita es:

  1. Prepare certificados autofirmados, cliente y servidor (usando easy-rsa);
  2. Configure el servidor web cuyo repositorio de frentes acepte solo https; En el caso de nginx podría verse así:

    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 el certificado del cliente, la clave del cliente y el certificado ca en / etc / apt / ssl y, en el caso de Ubuntu, agregue el archivo 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"; };

Tenga en cuenta que si está utilizando un certificado autofirmado, es importante desactivar la verificación del host: Verify-Host "false";si no lo hace, verá un error: SSL: certificate subject name (blah-blah-blah) does not match target host name 'example.com'

Y aquí vamos, ya no hay acceso no autorizado al repositorio. Así que esto es algo bastante útil y poderoso.

at0S
fuente
3
Gracias por la gran respuesta. Pero creo que el problema principal sigue ahí. HTTPS realmente debería convertirse en el protocolo predeterminado para transferencias en la web y paquetes de Debian en particular. El argumento no debería ser por qué HTTPS, debería ser por qué no.
zaadeh
1
@aalizadeh, estoy de acuerdo con usted, hay gastos generales cuando se usa https, pero no hay gastos generales masivos. Creo que la razón principal por la que https no es un transporte predeterminado es que algunas organizaciones prohíben explícitamente cualquier tráfico encriptado (ya que quieren poder meter la nariz en lo que los empleados están haciendo por Internet), lo que significa que los repositorios deben admitir Transportes http y https. Puede haber otras consideraciones
0
1
El uso de »Verify-Host" false ";« está mal, incluso con certificados autofirmados. En su lugar, debe informar a sus clientes del certificado del servidor (correcto).
Axel Beckert
1
De hecho, pero aquí mis clientes eran solo sistemas internos. Entonces, en lugar de crear toda la infraestructura de pki adecuada, corté la esquina. Y sí, más tarde pki se resolvió correctamente y Verify-Host fue falso; fue eliminar Y sí, el punto es válido.
at0S
1
con ubuntu xenial, los paquetes apt se obtienen como usuario no privilegiado _apt, ¿puede actualizar este hilo con detalles sobre cómo gestionó o resolvió los problemas de permisos de archivos?
David
7

Tenga en cuenta que debido a vulnerabilidades como

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

... que evita la firma de InRelease, probablemente sea una buena idea configurar HTTPS de todos modos.

Royce Williams
fuente
1
Y ahora este también: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. La firma de InRelease no es suficiente . "¡Pero mover todos los espejos a HTTPS llevará tiempo y coordinación!". Si. Empezar ahora. Esta no será la última falla de InRelease.
Royce Williams
1
Aquí hay otro ejemplo, de un ecosistema diferente: Alpine. Su sistema de administración de paquetes no usa HTTPS de manera predeterminada, y se basa únicamente en la firma para verificar la integridad del paquete ... y esa verificación tenía un error explotable de forma remota en septiembre de 2018: justi.cz/security/2018/09/13/alpine- apk-rce.html Alpine debe empezar a moverse ahora a través de HTTPS por defecto.
Royce Williams el
4

Para el caso de uso de "anonimato" también existe el apt-transport-torque le permite colocar URI como tor+http://en los archivos sources.list. Esta es una protección de anonimato mucho mejor que simplemente encriptar la conexión a su espejo.

Por ejemplo, un observador local aún sabría que está actualizando o instalando software incluso con HTTPS, y probablemente pueda hacer algunas suposiciones decentes sobre cuáles de los que está haciendo (y posiblemente incluso qué paquetes, según el tamaño).

Debian proporciona repositorios APT a través de los "servicios Onion" de Tor para que pueda obtener un cifrado de extremo a extremo (similar a TLS) sin tener que confiar en el sistema de nombres de dominio. Vea onion.debian.org para todos los servicios de Debian disponibles de esta manera. El repositorio principal de Debian FTP está envwakviie2ienjx6t.onion

meejah
fuente