Cookies

Al desarrollar una aplicacin es necesario contar con algun mtodo para identificar a nuestros usuarios. De esta manera les podemos ofrecer una experiencia personalizada, o brindarle algn tipo de privacidad a sus datos, entre otras cosas.

En HTTP el mtodo por excelencia para identificar a los usuarios son las cookies. Una cookie no es ms que una cadena de texto con formato "nombre=valor" que es almacenada en el browser y enviada junto a cada solicitud HTTP. Veamos cmo trabajan las cookies. Digamos que un usuario nuevo entra al sitio www.ejemplo.com, haciendo una solicitud HTTP. GET /index.html HTTP/1.1 Host: www.ejemplo.com Cuando el servidor devuelve la respuesta, incluye el header Set-Cookie para asignar una nueva cookie.

HTTP/1.1 200 OK Content-Type: text/html Set-Cookie: userid=2500 <pgina html> De ahora en adelante, el browser guardar la cookie y la enviar como header cada vez que haga un request a www.ejemplo.com.

GET /otra/pagina.html HTTP/1.1 Host: www.ejemplo.com Cookie: userid=2500

De esta manera, el servidor puede identificar al cliente cada vez que ste solicite un recurso. Para conocer ms sobre el header Set-Cookie y sus distintas opciones, visitar este link.

HTTPS Hoy da se llevan a cabo muchas actividades confidenciales en la web, como transacciones comerciales y banca en lnea, entre otras. Si estas transacciones fuesen transportadas utilizando HTTP, se correran grandes riesgos de seguridad, incluyendo robos de identidad, filtracin de informacin privada y fraudes. Por esta razn fue desarrollado un nuevo protocolo llamado HTTPS,

que provee una capa de seguridad sobre el HTTP tradicional.

Si queremos entender cmo trabaja el HTTPS, debemos tener claros algunos conceptos de criptografa. La criptografa tiene tres objetivos principales:

1. Validar que los mensajes no sean alterados (confiabilidad de la data). 2. Asegurar que slo el destinatario del mensaje pueda leerlo (confidencialidad de la data). 3. Evitar robos de identidad (confiabilidad de la fuente). Para asegurar que la data no sea modificada, se utiliza el concepto de reduccin criptogrfica, o "hashing". Bsicamente, cuando aplicamos una funcin hash a un mensaje, obtenemos una cadena de texto conocida como el "message digest". El tamao del message digest depende del algoritmo que se utilice. Veamos qu sucede si aplicamos el algoritmo sha1 a algunos mensajes de ejemplo: Mensaje Original Hola Este es un mensaje de prueba. Mara, stas son las coordenadas del tesoro: Latitud 40 25' 12,3168" (N) Longitud 3 41' 19,7160" (O) Message Digest 4E46DC0969E6621F2D61D2228E3CD91B75CD9EDC CEE7B99A7E1BAA8315EA60262C1BF197AB4CCF4F

733C889072D4EAB4586FD9988B0066CD86D1964D

Mara, stas son las coordenadas del tesoro: EB2948DDBA0C5653DD40BD142AEC322C4F0948AB Latitud 1 15' 10,3168" (S) Longitud 80 20' 19,7160" (E) Las funciones hash tienen varias caractersticas:

Dos mensajes idnticos siempre generan el mismo digest. Dos mensajes distintos siempre generan digests distintos. Cualquier cambio a un mensaje, por mnimo que sea, lo convierte en un mensaje distinto y por ende genera un digest diferente. Las funciones hash trabajan en una sola direccin (no hay manera de transformar el digest de vuelta a la cadena original).

Digamos que Jos quiere enviarle un mensaje a Mara, pero no est seguro si alguien intentar modificar el mensaje en el camino. Jos decide escribir su mensaje y luego aplicarle una funcin hash para obtener el digest. Finalmente, Jos aade el digest al final del mensaje y se lo enva a Mara. Mensaje enviado por Jos (intento 1)

Mara, stas son las coordenadas del tesoro: Latitud 40 25' 12,3168" (N) Longitud 3 41' 19,7160" (O) 733C889072D4EAB4586FD9988B0066CD86D1964D Cuando Mara recibe el mensaje, le aplica la funcin hash a la data y obtiene un digest como resultado. Si el digest es igual al que envi Jos, puede estar segura que no hubo alteraciones al contenido. En cambio, si Marcos hubiese interceptado el mensaje y modificado las coordenadas, Mara se hubiese dado cuenta porque el digest del mensaje modificado sera distinto al digest del mensaje original. Pero digamos que Marcos intercept el mensaje, modific las coordenadas, y modific tambin el digest para que concordara con su nuevo mensaje. Mensaje modificado por Marcos Mara, stas son las coordenadas del tesoro: Latitud 1 15' 10,3168" (S) Longitud 80 20' 19,7160" (E) EB2948DDBA0C5653DD40BD142AEC322C4F0948AB Al aplicar la funcin hash sobre el mensaje modificado, Mara obtendra el digest generado por Marcos, y pensara que est recibiendo el mensaje original. Para evitar este tipo de problemas, se utiliza una combinacin de funciones hash con funciones de encriptacin de llave pblica. Una funcin de encriptacin toma un mensaje como entrada y genera un mensaje completamente distinto como salida. Aunque parecen similares a las funciones hash, las funciones de encriptacin son de dos vas. Esto quiere decir que si tomamos un mensaje encriptado, y le aplicamos una funcin determinada, podemos obtener el mensaje original de vuelta. Las funciones de encriptacin de llave pblica funcionan de la siguiente manera:

Jos contiene una llave privada, que mantiene en secreto, y una llave pblica, que mantiene en un lugar accesible al resto del mundo. Si Jos encripta un mensaje utilizando su llave privada, slo la llave pblica de Jos podr desencriptarlo. Si alguien utiliza la llave pblica de Jos para encriptar un mensaje, slo Jos podr desencriptarlo utilizando su llave privada. Un mensaje encriptado utilizando la llave pblica de Jos no puede ser desencriptado utilizando esa misma llave pblica.

Ahora que Jos tiene conocimiento de las funciones de encriptacin, decide hacer lo siguiente: primero, utiliza una funcin hash para generar un digest de su mensaje. Luego, toma el digest y lo encripta utilizando su llave privada. Esto es lo que se conoce como firma digital. Mensaje Original -> Mara, stas son las coordenadas del tesoro: Latitud 40 25' 12,3168" (N) Longitud 3 41' 19,7160" (O) Message Digest -> 733C889072D4EAB4586FD9988B0066CD86D1964D

Firma Digital -> pmAXOqDHWczGgcsWuJdyaAp499YLpL4A9AwzYhrIS/Bp2B4npaYaN7y7mHBcNuia Finalmente, Jos aade la firma digital al final del documento, y se lo enva a Mara.

Mensaje enviado por Jos (intento 2) Mara, stas son las coordenadas del tesoro: Latitud 40 25' 12,3168" (N) Longitud 3 41' 19,7160" (O) pmAXOqDHWczGgcsWuJdyaAp499YLpL4A9AwzYhrIS/Bp2B4npaYaN7y7mHBcNuia Ahora Marcos no podr modificar el mensaje sin que Mara se de cuenta, aunque modifique tambin la firma digital. Si Mara utiliza la llave pblica de Jos para desencriptar una firma digital que no ha sido producida con la llave privada de Jos, slo obtendr basura. Luego, cuando genere el digest del mensaje, jams ser igual al enviado en la firma digital modificada.

Aunque Marcos ya no puede modificar el mensaje, s puede interceptarlo y leerlo, y conocer as las coordenadas del tesoro. Para evitar esto, Jos, despus de escribir el mensaje y firmarlo digitalmente, decide encriptarlo utilizando la llave pblica de Mara. Mensaje enviado por Jos (intento final) tctVX01uaWnlBsk2RhAzsG5g/XbOj3Xt8l2F2HuJrT6WwRh7n/SFCgDOhODBAOr8UMQ4hemKCm0 U CNfjwTqipyMwSaw+xYqBkOGqi+/oEqgo07BlZs+TAGHthD4uB7lzSKUl+ZuUT+mbmrwQQLClcW UL 87PMJMff0jMDlaUVzG1b1RVUPKIIx+x8w0oqp1tZBa0ENWQQVpt7suncBCBB9O/Urelc37IwNef1 BEBoe0X+JiN0L6AZ5A== De esta forma, slo Mara es capaz de leer el mensaje. Estos son los pasos que realizara Mara al recibir este mensaje:

1. Desencriptar el mensaje utilizando su llave privada. As obtendra la data del mensaje y la firma digital. 2. Desencriptar la firma digital utilizando la llave pblica de Jos. As obtendra el message digest que fue enviado por Jos. 3. Generar un message digest con la data del mensaje, y comparar con el message digest enviado por Jos.

Existe todava un problema. Digamos que Jos y Mara viven en extremos opuestos del planeta. Como Jos no puede darle su llave pblica a Mara en persona, Mara debe aceptar la llave pblica a travs de un medio digital. Aprovechando esta situacin, Marcos le enva a Mara su propia llave pblica, y le hace creer que es la llave pblica de Jos. Ahora Marcos podr enviarle mensajes falsos a Mara, hacindose pasar por Jos. Cuando Mara reciba estos mensajes, utilizar la llave pblica de Marcos (pensando que es la de Jos), y ser engaada.

En este escenario, el problema es que Mara no tiene cmo asegurar que la llave pblica de Jos sea autntica. Para resolverlo, HTTPS utiliza el concepto de certificados digitales.

Existen ciertas organizaciones a nivel mundial conocidas como autoridades certificadoras, abreviadas como CA (Certificate Authorities). La labor de estas organizaciones es asegurar que las llaves pblicas correspondan realmente a la persona que dicen pertenecer. Para esto, las CA toman la llave pblica de la persona, junto con alguna informacin de identificacin, y la firman utilizando su propia llave pblica, creando as el "Certificado Digital" de esa persona. Adems, las autoridades certificadoras tienen la capacidad de desacreditar certificados que han sido expuestos, en caso que la llave privada de la persona sea robada. Siguiendo con nuestro ejemplo, cada vez que Mara reciba un mensaje de parte de Jos, har lo siguiente: 1. Buscar el certificado digital de Jos en una de las autoridades certificadoras. 2. Desencriptar el certificado digital utilizando la llave pblica de la CA. As obtendr la llave pblica de Jos e informacin adicional sobre l. 3. Utilizar la llave pblica de Jos para desencriptar la firma digital del mensaje. As obtendr el digest enviado por Jos. 4. Generar un message digest con la data del mensaje, y comparar con el message digest enviado por Jos. Aunque todo esto parezca complicado, estos procesos son manejados por las libreras SSL que vienen integradas con la mayora de los servidores y clientes web. Para el usuario final, el nico cambio notable entre HTTP y HTTPS es que las direcciones url empezarn con "https://".