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

Hay. Necesita instalar el paquete apt-transport-https . Luego, puede usar líneas como

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

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

EDITAR: Como se mencionó en los comentarios, de hecho es más seguro usar el Repositorio TLS . La investigación muestra que el uso de apt en repositorios no cifrados puede representar un riesgo de seguridad ya que el transporte HTTP es vulnerable a los ataques de reproducción.

Comentarios

• No, la mayoría de los espejos no admiten https. Simplemente porque no ‘ 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.
• Puedo pensar en un par de razones por las que aún prefiero descargar sobre TLS: 1) Puede que me preocupe mi privacidad al instalar paquetes, y 2) allí podrían ser errores en el código de verificación de firma del paquete, que un MITM podría explotar.
• @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 su contenido con claves PGP porque puede haber errores en el código TLS. Tanto PGP como TLS establecen confianza; no ‘ no necesita ambos para eso.
• @Marco su respuesta es incorrecta; Numerosos trabajos de investigación han demostrado que los repositorios APT y YUM son vulnerables a 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.
• Aquí está el documento al que se refiere @Joe Damato; consulte también su answer aquí

Su la 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 paquete apt-transport-https .

Debian no hace HTTPS descargas fáciles porque hay muy pocos beneficios. La distribución de paquetes de Debian ya incluye un mecanismo para verificar los paquetes: todos los paquetes están firmados con Gpg . Si un intermediario activo redirige su tráfico a un servidor con paquetes corruptos, la corrupción se detectará porque las firmas GPG no serán válidas. Usar 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 infectado o malicioso u otros problemas en cualquier parte de la cadena de distribución de paquetes.

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

El único lugar donde HTTPS ayudaría es para arrancar la confianza, para obtener una imagen de instalación válida conocida. Debian no lo hace «. Parece que proporciona eso: hay sumas de comprobación de medios de instalación , pero solo a través de HTTP.

Comentarios

• Existe una versión HTTPS del medio de instalación: cdimage.debian.org/debian -cd
• ¿Muy poco beneficio? ¿Qué pasa con justi.cz/security/2019/01/22/apt-rce.html ?
• @AaronFranke Un error específico que es más fácil de explotar con HTTP que con HTTPS tiene un beneficio muy pequeño, sí. No es ‘ como si HTTP tuviera una mayor superficie de ataque que HTTPS: de hecho, HTTPS en sí mismo tiene una mayor superficie de ataque ya que involucra más código. Por lo tanto, no es ‘ ni siquiera un beneficio neto: es ‘ una compensación entre dos riesgos marginales.

Hace poco me encontré con el problema con el repositorio apt de mi empresa. El problema era que si usamos http estándar transporte cualquier otra persona puede obtener el paquete fácilmente. Como la empresa está empaquetando su propio software propietario y no quiere compartirlo con todo el mundo, 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, restringir el acceso a nivel de servidor web, usar ssh como transporte. Se puede encontrar una lectura bastante fácil de consumir sobre este tema aquí: Restringir el acceso a su repositorio privado de Debian

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

1. Preparar certificados autofirmados, cliente y servidor (usando easy-rsa);

2. Configure el servidor web que tiene frente al repositorio para aceptar 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, «Detectaré un error: SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

Y aquí vamos, ya no hay más acceso no autorizado al repositorio. Entonces esto es algo bastante útil y poderoso.

Comentarios

• Gracias por la gran respuesta. Pero creo que el problema principal sigue ahí. HTTPS realmente debería convertirse en el protocolo predeterminado para transferencias a través de la web y paquetes de Debian en particular. El argumento no debería ser por qué HTTPS, debería ser ¿por qué no?
• @aalizadeh, estoy de acuerdo contigo, hay sobrecarga cuando se usa https, pero no hay sobrecarga masiva. 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 cifrado (ya que quieren poder meter sus narices en lo que hacen los empleados a través de Internet), lo que significa que los repositorios deben admitir transportes http y https. Puede haber otras consideraciones
• Uso de » Verify-Host » false «; « es incorrecto, incluso con certificados autofirmados. En su lugar, debe informar a sus clientes del certificado de servidor (correcto).
• De hecho, pero aquí mis clientes eran solo sistemas internos. Entonces, en lugar de crear toda la infraestructura pki adecuada, corté la esquina. Y sí, más tarde pki se resolvió correctamente y Verify-Host falso; fue eliminado. Y sí, el punto es válido.
• con ubuntu xenial, los paquetes apt se obtienen como usuario sin privilegios _apt, ¿puede actualizar este hilo con detalles sobre cómo gestionó o resolvió los problemas de permisos de archivos? >

Tenga en cuenta que debido a vulnerabilidades como

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

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

Y este no es un solo ejemplo: muchos otros sistemas de actualización que utilizan HTTP de forma predeterminada también han tenido un historial de fallas en la verificación de firmas.

Los mecanismos de actualización críticos para la seguridad deben usar HTTPS y verificación de firma para ser robusto. Cada uno mitiga una falla del otro.

Comentarios

• 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 requerirá tiempo y coordinación! «. Si. Empezar ahora. Esta no será la última falla de InRelease.
• Aquí ‘ s otro ejemplo, de un ecosistema diferente: Alpine. Su sistema de administración de paquetes no ‘ t usa HTTPS de forma 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 debería comenzar pasando ahora al uso de HTTPS de forma predeterminada.
• (Revelación completa: mi propia esencia, pero ‘ es la única referencia que conozco of), aquí hay una lista de todas las fallas de verificación de firma del lado del cliente que ‘ estoy consciente. La lista no es trivial y crece con regularidad. Agrega bienvenida. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004

Para el caso de uso de» anonimato «también hay apt-transport-tor que luego le permite poner URI como tor+http:// en 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 todavía sabría que está actualizando o instalando software incluso con HTTPS, y probablemente pueda hacer algunas conjeturas decentes en cuanto a cuál de los que estás 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 puedas obtener cifrado de extremo a extremo a TLS) sin tener que confiar en el sistema de nombres de dominio. Consulte onion.debian.org para conocer todos los servicios Debian disponibles de esta manera. El repositorio FTP principal de Debian está en vwakviie2ienjx6t.onion