HTTPS Tampoco Te Protege Siempre, más conocido por sus siglas: HTTPS (por fín he creado un acrónimo recursivo y, además, ambiguo, jajaja). Bueno, espero que así lo recordéis la próxima vez que os sintáis seguros al ver el candadito o el https:// resaltado o cualquiera de esas formas en las que el navegador te indica que estás usando HTTPS.

El motivo de este post viene debido a que la EFF (Electronic Frontier Foundation) ha iniciado una campaña contra el status quo de la autenticación y cifrado en el mundo de las aplicaciones y sitios web: el uso de HTTPS. Bajo el lema ‘It’s time to fix HTTPS’ han presentado en varios sitios su opinión sobre la situación actual y cómo proponen que se resuelva.

A continuación os dejo la presentación para que la veáis y, además, añado algunas consideraciones que he estado pensando desde que la vi.

El problema

La verdad es que la situación del uso de HTTPS tiene múltiples problemas a la hora de determinar si la página a la que nos conectamos es o no auténtica. Quizá uno de los mayores sea de concepto y se trata de la confianza. HTTPS es, en el fondo, una PKI y como sabréis, estos sistemas se basan en la confianza.

Como dice Marcus Ranum en sus ‘leyes físicas de la seguridad de la información‘ (slide 12): «la cantidad de confianza que ponemos en un sistema puede no tener nada que ver con si se lo merece o no».

En el caso de la PKI que es el HTTPS, ¿dónde confiamos? Pues principalmente en tres elementos fundamentales:

  • En la CA: La autoridad de certificación es la que firma los certificados (más o menos).
  • En la RA: La autoridad de registro es la que comprueba la identidad de los firmantes (más o menos).
  • En el navegador: Los certificados de las autoridades de certificación en las que ‘confiamos’ por defecto se encuentran en el navegador.

Vamos a ver cada caso por separado.

Autoridad de certificación

La CA es dónde están ‘las joyas de la corona’ de este asunto. Todos nos imaginamos el típico búnquer con guardas donde hacen falta dos llaves que llevan al cuello dos personas distintas y que deben ser giradas al unísono para que se encienda.

Y lo mismo es cierto y todo. El problema es que esa es la CA última (raíz) en la ‘cadena de confianza’. Es probable que con ella se hayan firmado otras CAs delegadas que están en sistemas más ‘accesibles’. Para que cada vez que compras un certificado on-line, no tengan que bajar dos tíos a un búnquer con guardas y girar las llaves que llevan al cuello al unísono, proceder a la firma y tal.

Eso ayuda a que, si una CA delegada es comprometida, se revoca y punto. Pero no hay que generar una nueva CA raíz. Si te das cuenta, claro. Recientes incidentes en RSA o Comodo hacen pensar en la tragedia que supondría una intrusión de alguien creativo en algunas de las empresas que firman certificados.

Porque, una vez generado, nos fiamos plenamente del certificado de un sitio siempre que haya sido firmado por una cadena de CAs que lleve a alguna de las CAs de las que tenemos certificados en nuestro navegador.

O, de lo contrario (y según el navegador que usemos) habrá que aceptar el certificado del sitio como válido… o no podremos verlo y disfrutar de su contenido. Por ejemplo, todas las webs gubernamentales que no tienen la CA raíz de la FNMT… pues hala, a aceptar el certificado. Eso o seguir el cansino proceso de instalar tú mismo la CA raíz de la FNMT en todos tus ordenadores y/o navegadores.

Autoridad de registro

La RA es dónde se valida la identidad de la entidad a la que se emite el certificado. En teoría se comprueba que los datos que se firman realmente pertenecen al que envía la petición. En la práctica esta validación no es tampoco muy exhaustiva (puede serlo más si compras un EV).

Lo cual significa que se podrían conseguir que se tramitaran certificados con datos de otro si se consiguen cumplir los requisitos de la RA. Esto ya ha ocurrido en alguna ocasión. La CA confía en la validación de la RA, por lo que una intrusión en la RA (que está disponible on-line para poder hacer negocio rápido por web) podría dar como resultado solicitudes de certificación falsas.

Navegador

En el navegador (o en el almacén de certificados del sistema operativo) es dónde se mantiene la larga lista de certificados de CA en las que confiamos ciegamente. Porque… ¿cuándo fue la última vez que miraste esa lista? Y, en caso de querer comprobar si los certificados son válidos… ¿cómo lo harías?

En la presentación presentan la posibilidad de insertar certificados de CA en el navegador de forma fraudulenta empleando CSRF. En tal caso, debe ser difícil que nos diéramos cuenta.

La solución propuesta

La presentación analiza diversos factores (incentivos perversos) que hacen que actualmente la situación sea tan negativa.

La solución que proponen la llaman jocosamente TOFU/POP (Trust On First Use; Persistence of Pseudonym). La idea es similar a la confianza que depositamos en el acceso ssh a servidores. Cada servidor tendrá su ‘pseudónimo’ o certificado, confiamos en él la primera vez que nos conectamos y luego, si cambia, seremos informados. Además comenta la posibilidad de diversos métodos para aportar confianza en la primera conexión o cuando haya algún cambio (DNSSEC, redes de confianza, etc.).

¿Qué os parece la idea? ¿ Creéis que nos desharemos del HTTPS tipo PKI para ir hacia un modelo distinto? ¿Os convence esta idea? ¿Cómo crees que afectará al usuario normal? ¿Y cómo se adaptarán los ‘cybercriminales’?

Actualización: No os perdáis este post en Security by default sobre mitos en HTTPS.