19 abril 2011

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.

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 StartSSLComodo.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.

25 comments :

Madrikeka dijo...

Muchas gracias por la info, yo había cosas que no sabía!! habrá que empezar a usar Ópera XD

Estebancostablanco dijo...

Muy completito el artículo, creo que algunos confunden la seguridad del https, con la seguridad en todos los componentes (equipo cliente, comunicación y servidor), cuando si un equipo tiene un keylogger, base de datos vulenable, página Web vulnerable... la comunicación será segura, pero el proceso completo no tiene por que serlo, de ahí la importancia de proteger todo: equipos, comunicaciones y servidores...

lo dicho, muy bueno el artículo.

Anónimo dijo...

Muy buen post. Como Madrikeka, había cosas que no sabía, y me ha venido muy bien.
Creo que voy a dejar de usar Chrome (me ha durado menos que el PCCity del CC nuevo de Coruña)

Mikel Ihidoi dijo...

Hay un error, en cuanto a cómo cachea el FireFox con una conexión segura, está mal comentado, se dice que por defecto se almacena en caché pero es lo contrario (el Bug que se comenta es muy antiguo del 2005), lo podéis comprobar directamente poninendo en la barra de direcciones:
about:config

Esto siginifica que el FireFox es más seguro que el Internet Explorer, ya que por defecto el FireFox no los almacena, mientras que el IE sí, y hay que cambiar la configuración expresamente.
Gracias por compartir vulnerabilidades ;)
Salu2!

Alejandro Ramos dijo...

Yo he hecho la prueba en Firefox4 y SI las cachea. El bug es antiguo pero si te fijas no se ha cerrado hasta el 2010.

Monzisez dijo...

Increíble ... vaya artículo más bueno has escrito!

Me encantó, sobre todo la parte "todas las páginas que se sirvan han de ser única y exclusivamente vía HTTPS". Me cabrea tanto ver que páginas como tuenti (que asco ...) sólamente mandan los credenciales por https.

Sigue con el buen trabajo!

Alejandro Ramos dijo...

Lo bueno es que se lo comentas, y dicen que tu no tienes ni idea de escalabilidad o recursos y que lo máximo que has administrado es el PC de tu casa. Ellos son los únicos grandes y que saben algo en España. El resto estamos de farolas y solo trabajamos en VMWares en PYMES... En fin [...]

Luis Delgado dijo...

verdades como puños FTW!

Josep Sanz dijo...

Muy buen artículo. De hecho, ya he aplicado lo que he aprendido en mi proyecto SaltOS. Son cosas que no le damos importancia, pero tras leer este artículo, te das cuenta de que mejor hacerlo bien que no esperar a las sorpresas. Poco a poco aprendemos entre todos. Gracias por vuestro trabajo. Josep.

ln dijo...

Buen articulo. Gracias

Rómulo Manuel Soto Díaz dijo...

Como algunas veces lo he mencionado “el mayor peligro está frente al teclado” haciendo referencia clara al usuario. Aunque esta máxima la uso más para los temas se infección de virus, troyanos y contra el pishing o hacking, es totalmente aplicable para este tema de las creencias de que porque aparece HTTPS en la dirección de un web o aparece el candado indicando una conexión segura, pues no siempre es así y esto ha quedado claramente demostrado, pues si vamos a depender exclusivamente de la seguridad de los programas, y dejamos que ellos hagan lo suyo sin menternos de por medio, estaremos cometiendo un gran error ya que parte de la solución es, precisamente, estar metidos en el asunto, pero no haciendo cambios experimentales o estableciendo configuraciones complejas y algo excéntricas, sino estando bien informados. Y esto implica leer, leer, leer y leer. Esa es la mejor solución que podemos dar para que la ecuación de seguridad usuario & software tenga el efecto deseado y esperado.

Un saludo desde Lima, Perú

Carlos Capote dijo...

Siempre he pensado que otro mito por el estilo, es el de que es más seguro visitar una página HTTP, que una HTTPS cuyo certificado es no tiene el apoyo de una entidad certificadora detrás. Culpa la tienen los mensajes rocambolescos que muestran los navegadores. ¿No opináis igual?

Legajius dijo...

Que buen articulo, por aquí usaré tu info para tomar buenas medidas en mi red

David dijo...

Hola, me gustaria saber cual es comportamiento general de un proxy/firewall de una organizacion cuando se ven paginas con https. Gracias

Alejandro Ramos dijo...

En general conocen origen y destino a nivel IP, pero no el contenido. Es decir, no pueden ver los GET, ni los POST, ni sus parámetros.

David Escribano dijo...

En el artículo había creido entender que los parámetros pasados por GET bajo una sesión SSL sí eran visibles a un man-in-the-middle... ¿Podrías aclarar en qué sistemas podría quedar registrada esta información además de en local?

chmeee dijo...

Cuidado con "do not save encrypted pages to disk" en IE porque, si no tenéis bien configurada la aplicación para incluir las cabeceras correctas en la descarga de ficheros, os podéis encontrar con que el usuario no puede descargar ficheros a través de HTTPS.

Echad un ojo [aquí][1] y [aquí][2].

[1]: http://stackoverflow.com/questions/1038707/cant-display-pdf-from-https-in-ie-8-on-64-bit-vista
[2]: http://support.microsoft.com/kb/323308

Eslapera dijo...

Muy buen artículo. Gracias.

Josemaria dijo...

Yo trabajé en el departamento de pruebas de prestaciones de Telefónica hace ya unos 10 años y nos dejaron unos F5 para hacer pruebas. No recuerdo el modelo pero eran de gama alta: hacían el cifrado SSL por hardware y, además, balanceaban la carga entre varios servidores. Los resultados fueron sorprendentes: la velocidad ante una carga media-alta era superior a la obtenida haciendo la misma navegación con HTTP y sin cifrado. Y con el equipo prácticamente salido de la caja sin ningún tipo de tunning ni nada. Auténticas joyas, vaya. Eso si: del precio que tenían ni hablamos...

byhanzo dijo...

Yo lo he mirado en el Firefox 4 que instalé desde 0 hace unos días (acabo de formatear el ordenador) y esa entrada que mencionas aparece como "True". Digo desde 0 ya que no es una actualización ni nada, en la que podrían quedar configuraciones y parametros antiguas.

Saludos!!!

byhanzo dijo...

Opino lo mismo. Es una verdadera putada el que para que un navegador te reconozca "perfectamente" que cifras la conexión tengas que pagar a una empresa tercera que lo único que hace es verificar lo obvio.

En mi web uso en el webmail conexíon cifrada y al no tener certificado me saltan cien mil avisos en el navegador pareciendo que fuera el fín del mundo. Vamos, lo mejorcito como para darle una cuenta de email a un cliente...

Agnoia dijo...

No son visibles en un proxy intermedio: En los logs sólo se verá un Connect en las cabeceras HTTP y el resto irá cifrado.

Sin embargo, en el propio servidor web que te atiende, y/o en un proxy inverso que lo proteja, tódos los parámetros pasados por método GET quedarán reflejados en sus logs (ergo, el paso de session_ids por método GET no es nada seguro)

Agnoia dijo...

Porque los F5 aparte de cifrar también comprimen, y esta opción no se suele habilitar por defecto en los sevidores web.

Marta dijo...

Genial tu artículo Alejandro, muchas gracias
saludos
Marta

Certsuperior dijo...

Existe una frase en materia de seguridad que dice que para sentirse seguro hay que estar inseguro. Si navegamos con http pensamos que estamos seguros es un error. Con https también. Hay que estar siempre alerta pero creo que está claro que ir con un escudo es mejor que ir sin nada.
Como bien dices, el problema radica en el usuario. Cada vez va haciendo más falta que haya una educación informática seria en todos los países.
Felicidades por el artículo