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.
Aunque la conexión se establezca utilizando SSL, las sesiones han de ser configuradas para que no puedan ser enviadas utilizando otros canales. Tal y como comentamos en "Sesiones seguras: es gratis", se ha de establecer el parámetro "secure".
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.
Lo único que hay que transmitir vía HTTPS es la información sensible, como el usuario y contraseña.
Si algo hemos aprendido todos con FireSheep es que no es necesario tener las credenciales de un portal para acceder con la cuenta de otro usuario. Basta con robarle la sesión y asignarla a nuestro navegador.
Por ese motivo, si una web requiere autenticación y trata datos confidenciales, todas las páginas que se sirvan han de ser única y exclusivamente vía HTTPS.
El usuario debería elegir si quiere utilizar o no HTTPS.
Volvemos a lo de siempre: Seguridad Por Defecto (SbD). Me gustaría no tener que explicarle a nadie porque debe usar HTTPS y no HTTP. La seguridad ha de ser impuesta, evitará problemas.
Si a un usuario únicamente le dejas acceder al servicio mediante el protocolo seguro, con certeza jamás hará una transacción por otra vía. No debe ser una opción y mucho menos una opción deshabilitada por defecto.
Me puedo fiar de la web si hay un candado en mi navegador.
El candado que se muestra en el navegador solo indica que el certificado SSL es válido, no que la entidad que dice estar detrás es la auténtica. Generalmente informa que la los datos serán transmitidos de forma cifrada. Pero insisto nuevamente: no garantiza la autenticidad de la compañía en la que está alojado.
Yo puedo crear un certificado SSL válido para "paipal.com" y hacerme pasar por Paypal, y el navegador mostraría el candado correctamente. Yago escribió sobre esto y lo demostró en un magnifico artículo: Fraude online con firma digital y SSL. Comprobar que la dirección y el dominio son correctos, es tarea que ha de hacer el usuario manualmente.
Las páginas que tienen HTTPS no tienen problemas de seguridad.
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.
Publicado por Alejandro Ramos en http://www.securitybydefault.com/2011/04/mitos-de-https-y-la-navegacion-segura.html
Marcadores