Noticias de Interés

28/05/2011 Publicada en el BOE la Ley que regula el juego online(PDF) 31/03/2011 Juez obliga a devolver el canon a Nokia # 24/03/2011 La Audiencia Nacional anula la normativa que regula el canon digital # 23/03/2011 Audiencia Provincial de Madrid - Caso Indicedonkey y Caso Spanishshare: Enlazar no es delito # 17/03/2011 Miembro de la Academia de Cine detenido por lucrarse colgando películas en la red de forma presuntamente ilícita # 17/03/2011 Estados Unidos bloquea exvagos.es # 03/03/2011 Sentencia contra el canon en la Audiencia Provincial de Barcelona # 15/02/2011 Se aprueba la Ley Sinde en el Congreso-Ya es definitiva # 04/02/2011 Aprobado Proyecto de Ley de Regulación del Juego ONLINE # 01/02/2011 Comisión de Economía del Senado aprueba la Ley Sinde # 26/1/2011 Twitter bloqueado en Egipto por protestas contra Mubarak # 25/1/2011 Alex de la Iglesia diimite tras nefasta Ley Sinde # 24/1/2011 PP y PSOE pactan ley SINDE # 24/1/2011 Gran operación policial contra la pedofília # 15/1/2011 Anonymous convoca ataque DDoS el 16 de enero a las 18:00 por la votación el 18 de Enero de la ley Sinde # 12/1/2011 Tribunal Constitucional: la sentencia del canon europea ha de aplicarse en España porque forma parte de nuestro derecho interno # 11/1/2011 Convocada por internet primera manifestación contra Ley Antitabaco # 11/1/2011 Victoria judicial de Rapidshare en Alemania # 8/1/2011 Manifestaciones en toda España contra Ley Sinde # 8/1/2011 Manifestación en Murcia pro Wikileaks y contra Ley Sinde # 3/1/2011 Sentencia sobre caso Chipspain.com # 23/12/2010 Detenciones de responsables de webs de descarga y grabadores de screeners # 21/12/2010 Hoy se aprueba la ley SINDE con polémica y movilizaciones # 16/12/2010 Detención y registro TaquillaDivx.com # 13-12-2010 Suspensión medidas cautelares contra PSJailbreak #

martes, 22 de marzo de 2011

HTTPS ¿Qué es? ¿Por qué no se usa en todas las conexiones?

Hace unos días mencioné de pasada el HTTPS en el post sobre Riesgos del Cloud Computing. No es un sistema novedoso, y funciona la mayor parte de las veces de forma invisible para el usuario. Pero empecemos por el principio.

¿Qué es HTTP?

Estas siglas significan Hipertext Transfer Protocol o Protocolo de Transferencia de Hipertexto y es uno de los pilares sobre el que descansa la web (World Wide Web) actual. 

De forma llana y entendible, el HTTP es un lenguaje para preguntas y respuestas sobre el que se sostiene toda la información que hay en internet. Así cuando yo quiero entrar en una página web mi ordenador hace una pregunta al servidor en el que según el servidor de DNS esta está almacenada y este me responde enviándome la información solicitada si tiene esa información. Así de sencillo y así de vital.

Es un protocolo sin memoria, es decir, el no contiene información del usuario que hace la petición. Y hay día muchas aplicaciones web necesitan reconocer nuestro estado (quienes somos, que hemos hecho en esa web, etc). Para solucionar esto existen los cookies (concepto que me es necesario para un próximo post sobre la nueva regulación de la UE sobre privacidad) en la que el servidor que contiene la web almacena información del ordenador cliente que hace las preguntas o peticiones. Para que os hagáis una idea, cuando accedéis a vuestro email desde vuestro ordenador puede que os reconozca como usuarios (y os pida la contraseña) o incluso que os de acceso inmediatamente. Eso es gracias a una cookie que se envía junto a la petición aportando dichos datos.

¿Qué peligros tiene el HTTP?

Pues principalmente que alguien puede estar escuchando esa pregunta a la que añadimos una cookie con nuestra información, bien sea de forma pasiva (Eavesdropping) o de forma activa (Ataque Man-in-the-middle) ya que nuestro mensaje pasa por muchos puntos. Aunque a priori la información puede estar cifrada, si se captura la clave pública que usa el servidor, es posible modificar el mensaje para que un intermediario se convierta en receptor de una información privada.

Por ejemplo: Imaginen la banca online sin protección (tranquilos que ya no existe):
  1. Juan quiere comunicar con su Banco y Ladrón quiere obtener información. 
  2. Para iniciar la conversación Juan pide a Banco la Clave Pública que usa con el. 
  3. Ladrón intercepta la respuesta de Banco. 
  4. Ladrón modifica el mensaje usando una Clave Pública distinta y lo envía a Juan falseando identidad.
  5. Este cree recibir respuesta del banco y responde enviando su Clave Privada (su contraseña) a Ladrón.
  6. Ladrón recibe Clave Privada de Juan y puede iniciar proceso con el banco.
Cuidado con Firesheep y las redes públicas

No me cansaré de decirlo, si hace unos años usar un sniffer no era muy complicado (yo hice pruebas capturando mis propias conversaciones de Messenger con Wireshark y algún plugin) hoy es simplemente sencillísimo con aplicaciones como Firesheep, una extensión de Firefox con la que podemos obtener todas las contraseñas no seguras usadas en nuestra red o en una red pública.
  
¿Qués es HTTPS?

Pues una forma de crear una comunicación segura en una red insegura. Para ello esta comunicación esta avalada por una Autoridad de Certificación en la que nosotros confiamos.

¿Qué mejoras de seguridad supone el HTTPS?

 Pues principalmente los siguientes:

1º Tenemos un navegador que reconoce a la autoridad de certificación.

VeriSign o Microsoft por poner un par de ejemplos son autoridades certificadoras de conexión HTTPS. Nuestro navegador acude a ellos para verificar si la web a la que hacemos la petición es quien verdaderamente dice ser (Por ejemplo, si Banco es Banco y no Ladrón). 

La barra de direcciones del navegador suele mostrar un icono distinto cuando estamos en una conexión HTTPS. Y si pulsamos en ella nos da información adicional sobre la autoridad.

2º  El Administrador de la Web a la que accedemos obtiene un Certificado de Clave Pública.

Así, en caso de que una Clave Pública no este identificada como Certificada por la Autoridad de Certificación, nuestro navegador desplegará una alerta. 

3º SSL y TLS, el lenguaje de preguntas y respuestas va encriptado.



La comunicación comienza con una mediación con la Autoridad de Certificación para establecer como la pregunta y la respuesta va a ser encriptada (ambos extremos debemos conocer el método y las claves).

Para ello, cuando preguntamos (clientHello) nuestro navegador añade información sobre que tipos de encriptación soporta y este nos responde (serverHello) con la encriptación elegida. Después, por medio de la Autoridad de Certificación se nos concede o bien una Clave Simétrica para ambos o bien una Clave Pública compartida para descifrar una nueva Clave privada.

Y debajo de estas técnicas de cifrado esta el HTTP, es decir, la pregunta y la respuesta.

4º En ocasiones se garantizan que todos los nodos por los que ha pasado el paquete de datos son seguros.

 ¿Por qué no todo internet funciona con HTTPS?

Esta claro que una comunicación segura es mejor que una que no lo es, y aunque va creciendo el número de comunicaciones que usan el HTTPS, la gran mayoría de estas se producen sin ella. Las razones son enumerables:

1º Alto coste de los certificados de seguridad. 

Las Autoridades de Certificación no son gratis, por ello es normal que los comercios y la banca online, o las grandes corporaciones de internet las utilicen pero no las pequeñas y medianas webs. 

(Edito: En comentarios un lector nos indica que hay una entidad de certificación con un plan gratuito. Grácias por la información). 

2º El HTTPS no produce caché de datos.

Lo que hace que, especialmente cuando accedemos a webs alojadas en servidores lejanos (piensen en datos que tienen que recorrer medio mundo), todo el contenido tenga que ser reenviado, cuando la web normalmente almacena una serie de datos fijos que dan una velocidad aparente a nuestro navegador.

3º La negociación SSL inicial añade retardo.

Si la seguridad no es esencial, solemos preferir la velocidad.

4º No es usable en los Servidores Virtuales.

Esto es algo técnico, pero imaginemos que yo alquilo un espacio de servidor en una gran empresa de servidores y desde el gestiono a nivel software mi propio servidor. Esta es una práctica habitual. No esta bien solucionada la posibilidad de usar HTTPS (si mediante extensiones TLS pero de forma parcial).

¿Que hacer para evitar Firesheep y otros sniffers?

Hay varias extensiones que fuerzan el uso del HTTPS en los servidores que lo admitan. Muchas webs la ofrecen pero no la utilizan por defecto para maximizar la velocidad.





Mas seguro que estos es usar una VPN (Red Privada Virtual) de la que ya hablé el pasado mes (enlace aquí). 
  
Para saber más:



Safe Creative #1012140013368

1 comentario:

Tiramisú dijo...

Si que hay una entidad certificadora que es gratuita para certificados normales sin wildcard:

http://www.startssl.com

Y la reconocen todos los navegadores.

Publicar un comentario en la entrada