Mitos de HTTPS y la navegación segura

Las siglas HTTPS (Hypertext Transfer Protocol Secure) han generado siempre confusión, ya que bajo el paraguas de la “S” de seguro siempre se han escondido mitos sobre lo que realmente significa e implica.

Con la entrada de hoy, a modo “Cazadores de Mitos“, espero aclarar algunas de estas confusiones y que poquito a poco, todos  naveguemos mejor informados.

Las páginas bajo HTTPS no se almacenan en la caché del ordenador.

Es común asociar HTTPS a información sensible, son siempre las páginas más delicadas y en las que más capas de seguridad se aplica las que contienen datos confidenciales, como datos de carácter personal,  o bancarios.

En teoría todo lo que se transmita por HTTPS y sea sensible el propio servidor debería identificar que no se cacheé, de esta forma se optimizaría las peticiones al igual que ocurre con HTTP.

Imaginemos que me conecto a un banco y este no especifica que la información no ha de cachearse localmente, si visito este banco desde un ordenador público, otro usuario podría consultar la cache del navegador y conocer mis movimientos u otros datos confidenciales. Esto es considerado una vulnerabilidad, pero aún hay miles de webs en las que se produce esta problemática

Está por lo tanto en manos del navegador definir qué hacer con el contenido pedido bajo HTTPS. Internet Explorer, salvo lo indique el servidor, por defecto usará la caché, aunque tiene una opción para deshabilitarlo y que nunca almacena datos, tal y como se comenta en el siguiente artículo: HTTPS Caching and Internet Explorer.

Para configurarla, tan solo hay que ir a “Herramientas”->”Opciones de Internet” y en la pestaña “Avanzado”, seleccionar “No guardar las páginas cifradas en el disco”

En Firefox, depende de la versión del navegador tiene un funcionamiento u otro, hasta el 2010 han tenido abierto un bug donde han discutido este funcionamiento. Actualmente las páginas son cacheadas si el servidor no dice lo contrario, al igual que hace Internet Explorer. Se puede controlar este comportamiento mediante la directiva: cache.disk_cache_ssl

La siguiente imagen muestra un elemento cacheado que se sirvió por SSL.

En el caso de Opera, las páginas cacheadas de HTTPS son eliminadas al cerrar el navegador. Definido en la opción: Cache HTTPS After Sessions

Chrome cachea las páginas como el resto y no permite modificar este comportamiento, salvo se use una extensión, como ya comentamos anteriormente en: Extensiones para navegar más seguro con Chrome

Si hay HTTPS puedo mandar cualquier cosa en las Cookies o en la petición (URL)

Todos los datos confidenciales deben ser enviados utilizando el método POST, ya que si existe información confidencial en la propia URL, está quedará almacenada en múltiples sitios, como el historial del navegador, los registros del proxy, o los registros del propio servidor donde llegan las peticiones, como ocurre con HTTP.

Hace falta un certificado SSL para cada dirección IP, domonio o subdominio.

Existen muchas opciones y alternativas que permiten versatilidad con los certificados SSL y su instalación y configuración.

Un único certificado SSL que soporte wildcards, podrá ser instalado en todos los subdominios que queramos.

Server Name Indication extiende el protocolo de SSL y TLS permitiendo que el “CN” sea solicitado en la negociación TLS, dejando al servidor presentar el certificado correcto en base a la consulta que reciba.
Mediante Unified Communications Certificate (UCC), es posible incluir varios dominios distintos en un único certificado. En caso de que compartamos IP con otras aplicaciones y otros clientes.

Los certificados SSL son muy caros y dificiles de conseguir

Algunas compañías no usan SSL porque piensan que adquirir uno tiene un precio muy elevado. Esto no es así. Hay certificados incluso gratuitos como los que ofrece StartSSL, Comodo.o CACert.

Se pueden adquirir otros productos, con garantía o que permiten wildcards, desde 10$ anuales. Un precio asumible para cualquier compañía que tenga presencia y venta de productos online.

HTTPS es muy lento.


Sobre este mito hay aún debates abiertos. Uno de ellos es el que mantiene Adam Langley de ImperioViolet con el fabricante de aceleradores SSL F5. El primero ofrece argumentos por lo que la negociación SSL hoy por hoy se puede asumir económicamente. F5 (entre otras cosas, vendedor de aceleradores SSL) responde con unas tablas de pruebas y explicando que las pruebas de Adam son con certificados 1024-bit y no con los 2048-bit. Finalmente Adam opina que las pruebas de F5 no son reales, ya que están hechas con portátiles y no con servidores.

El usuario debería elegir si quiere utilizar o no HTTPS.

Fuera de este mundo, para el usuario final y no experto posiblemente el mayor mito es que las páginas que se alojan en un servicio que contiene HTTPS ya son seguras en todos sus aspectos. Ignorando que la seguridad que proporciona HTTPS no afecta a la calidad del código de las páginas web, solo al canal por el que son transmitidas. Un banco, una red social, el correo electrónico o cualquier otro servicio web no está libre de fallos por el mero hecho de publicarse mediante el protocolo seguro de HTTP.