¿Por qué las descargas de aplicaciones no se realizan habitualmente a través de HTTPS?

Porque HTTPS no está muy bien adaptado para asegurar descargas de archivos públicos grandes. Para este caso de uso, es lento y no es tan útil. Hay razones para no usar HTTPS más allá de la incompetencia o el desconocimiento.

HTTPS no resuelve completamente el problema . Esto Si obtiene su aplicación directamente del sitio web del proveedor, HTTPS garantiza la autenticidad de la aplicación. Pero si obtiene su aplicación de un tercero (por ejemplo, réplicas de software libre), HTTPS solo protege la conexión con el tercero. Un esquema de firma de paquete funciona mejor: puede proteger a toda la cadena del proveedor. La distribución de aplicaciones requiere protección de extremo a extremo y HTTPS no proporciona eso .

HTTPS usa más ancho de banda . La sobrecarga por descarga es mínima si no tiene en cuenta el almacenamiento en caché. Esta es la vaca esférica de "HTTPS no cuesta más": si utiliza SSL, no puede almacenar datos en caché excepto en los puntos finales de SSL. Las descargas de aplicaciones son cacheables en extremo: son archivos grandes que muchas personas descargan.

HTTPS es una exageración . La confidencialidad de la descarga de una aplicación rara vez es un problema, todo lo que necesitamos es autenticidad. Lamentablemente, HTTPS no proporciona autenticidad sin proporcionar también confidencialidad. La autenticidad es compatible con el almacenamiento en caché, pero la confidencialidad no lo es.

HTTPS requiere más recursos en el servidor. correo de Google lo redujo a una sobrecarga del 1% y una sobrecarga del 2% de ancho de banda, pero Esto es para un caso de uso muy diferente. Los servidores frontend de Gmail hacen algo más que servir archivos sin pensar; un servidor de archivos no necesita una CPU potente en primer lugar (está muy fuertemente vinculado a IO), por lo que es probable que la sobrecarga sea significativamente mayor. Lo mismo ocurre con la sobrecarga de memoria: en primer lugar, un servidor de archivos necesita muy poca memoria por sesión, casi toda su memoria es un caché de disco. Para reducir el uso de los recursos se necesita una gran cantidad de trabajo .

HTTPS no ayudaría a muchas personas . La persona preocupada por la seguridad verificará el hash proporcionado por el proveedor ( que debe estar sobre HTTPS). Los que no están preocupados por la seguridad harán clic alegremente en el mensaje "esta conexión es insegura" (hay tantos servidores mal configurados que muchos usuarios están capacitados para ignorar los errores de HTTPS). Y eso sin mencionar a las CA dudosas que otorgan certificados que no deberían.

Si desea asegurarse de que está obteniendo la aplicación original, verifique su firma o su hash con un valor de referencia que obtenga con una firma (por ejemplo, a través de HTTPS).

Los buenos vendedores hacen esto automáticamente. Por ejemplo, Ubuntu proporciona firmas GPG de sus medios de instalación . También proporciona los hash a través de HTTPS (lamentablemente no está vinculado desde ningún lugar cerca de la página de descargas por lo que puedo ver). Después de eso, la herramienta de instalación de software comprueba automáticamente que los paquetes vienen con una firma válida. Consulte ¿Cómo usar https con apt-get?

Nota: si obtiene la aplicación directamente del proveedor (en lugar de a través de algún repositorio de paquetes o mercado de aplicaciones), HTTPS brinda protección. Entonces, si usted es un proveedor que proporciona su aplicación directamente para descargar en su sitio web, ¡protéjalo con HTTPS!

Es la misma razón por la que no todas las solicitudes de inicio de sesión utilizan https todavía: las personas son demasiado perezosas, piensan que un certificado es demasiado caro o tienen un alojamiento que cobra más por usar https.

La pregunta real es por qué las descargas se sirven a través de una conexión simple más a menudo que los formularios de inicio de sesión. Y creo que esto se debe principalmente al desconocimiento . A menudo se proporcionan sumas de control, pero no son seguras si se envían a través de http. Una buena implementación de las sumas de comprobación que he visto es dónde se publicaron en Twitter (que utiliza https y se puede asumir razonablemente que no está comprometido). Sin embargo, no conozco a nadie que compruebe la suma de comprobación, quizás solo si el software no se ejecuta. Normalmente se asume que TCP realiza una comprobación de errores razonable.

Por supuesto, https es más pesado en el servidor que http. Para sitios web de alto tráfico, esto puede ser una razón. Pero nuevamente, los sitios web de alto tráfico también pueden generar 'dinero' para financiarlo.

Podría decirse que, cuando los usuarios descargan una aplicación a través de la web, la descarga de la aplicación debería ser más de HTTPS, ya que es la experiencia de usuario más limpia para los usuarios la que proporciona la seguridad que pueden comprender. Podría decirse que es realista esperar que muchos usuarios verifiquen un brillo verde en la barra de direcciones antes de descargar, pero no es razonable (por ejemplo) esperar que ellos calculen los hashes y los comprueben de forma segura.

Sin embargo, estas descargas de aplicaciones a menudo no se ofrecen a través de HTTPS, por diversas razones posibles:

• Buenas razones: HTTPS evita el almacenamiento en caché en la red. Esto puede aumentar el tráfico de red, la carga en el servidor y la carga en la red del lado del cliente.

• Malas razones: la gente tiene la creencia errónea de que "HTTPS es lento" (que es un mito ), porque se necesita trabajo adicional para configurar un servidor con SSL, porque dependen de los espejos y los sitios de réplica no usan HTTPS, o porque la gente no lo ha pensado o no Creo que están en riesgo. Para el software ampliamente utilizado, estas creencias son probablemente miopes. Aparentemente, también algunos sitios pueden usar equilibradores de carga o aceleradores que no pueden entender correctamente el HTTPS, y no quieren o no pueden permitirse diseñar una implementación adecuada que pueda hablar el HTTPS correctamente.

Algunos sitios de distribución de aplicaciones do usan HTTPS. Pero muchos no lo hacen.

Firefox es un ejemplo de alto perfil de una aplicación que no usa HTTPS de manera predeterminada cuando descarga la aplicación (consulte ¿Qué tan seguras son las copias de Firefox que se encuentran en varios sitios espejo de Mozilla? ).

Windows Update se realiza a través de un canal seguro (similar a HTTPS). Los administradores de paquetes de Linux utilizan la criptografía para proteger el software que descargan, aunque no el propio HTTPS.

La mayoría de las veces habrá sumas MD5 y SHA1 para la aplicación. Después de descargarlo, debe verificar esto con el que se muestra en el sitio web. Si el que calculaste es el mismo, entonces no hay problema.