Trabajo Práctico N 1 HTTP Hyper Text Transfer Protocol

Transcripción

1 FACULTAD DE INGENIERÍA UNIVERSIDAD DE BUENOS AIRES Seminario de Redes de Computadora Trabajo Práctico N 1 HTTP Hyper Text Transfer Protocol Integrantes: - Santiago Boeri (79529) - Hernán Castagnola (79555) - Christian Picot (80297) - Tomás Shulman (84050) Profesores: - Marcelo Utard - Pablo Ronco - Javier Bozzuto

2 Introducción: En este trabajo práctico examinaremos como es el protocolo primario usado para la transferencia de paginas web desde un servidor hacia un navegador web. Actualmente la transferencia de páginas web ocupa el 75% del tráfico de Internet. Arquitectura Conceptualmente la Web consiste en un gran set de documentos llamados páginas web que son accesibles desde internet. Cada pagina web es clasificada como un documento hypermedia. El prefijo media se usa para indicar que un documento puede contener además de texto gráficos, imágenes, etc. El prefijo hyper se refiere a que un documento puede contener links que nos refieran hacia otro documento. Un navegador web consiste en un programa aplicativo que un usuario invoca para acceder y ver una pagina web. El navegador, entonces se convierte en un cliente que contacta a un servidor web para adquirir una copia de la pagina especificada. Una pagina que contenga una mezcla de texto y otros ítems se representa usando Hypertext Markup Language (HTML). Un documento html es un archivo que contenga texto y comandos. Estos comandos, llamados tags, dan una guía de cómo deben estar ubicados los elementos de la pagina resultante. Uniform Resource Locators Cada página web tiene asignado un único nombre que la identifica. El nombre es llamado URL. Este empieza con el protocolo de transferencia. Siendo http el protocolo de transferencia la URL tendría la siguiente forma: hostname (FQDN o IP) [:port] / path [; parámetros] [?query] donde los corchetes denotan ítems opcionales. El :port es necesario solo cuando el puerto usado no es el well know port 80, path es una cadena que identifica un documento particular en el servidor, ;parámetros son cadenas que especifican parámetros adicionales dados por el cliente,?query es una cadena opcional cuando el navegador manda una pregunta. La forma de la URL anterior se la conoce como absoluta. Cuando el servidor ya ha sido determinado y la comunicación con el ya esta establecida el hostname se omite en la URL y esa forma se la conoce como URL relativa. Hypertext Transfer Protocol El protocolo usado para la comunicación entre un navegador y un servidor web o entre maquinas intermedias y servidores web se lo conoce como Hypertext Transfer Protocol (http). http tiene las siguientes características: Nivel de aplicación: http opera en el nivel de aplicación. Utiliza TCP para asumir confiabilidad y conexión, pero no provee confiabilidad o retransmisión por si mismo.

3 Pedido/Respuesta: una vez que la sesión se ha establecido un lado pide una http donde el otro lado responde Stateless: el servidor no lleva un historial de un pedido anterior o una sesión anterior. Transferencia bidireccional: http permite la transferencia desde un navegador a un servidor. Capacidad de negociación. http permite a los navegadores y servidores negociar detalles tales como el set de caracteres usados durante la transferencia. Cache: para mejorar el tiempo se respuesta un navegador guarda una copia de la pagina que recibe. Si un usurario pide una pagina, http permite al navegador interrogar al servidor si la pagina cambio desde que hecho una copia. Soporte de intermediarios: http permite que una maquina en el medio del camino entre el navegador y el web server actué como proxy server que guarde paginas web y responda a los navegadores consultando primero a su cache. HTTP GET Request En el caso mas simple, un navegador contacta a una servidor web directamente para obtener una pagina. El navegador extrae el hostname de la URL, usa DNS para mapear el nombre en una dirección IP y usa la dirección IP para establecer una conexión TCP al servidor. Una vez que la conexión esta establecida el navegador y el web server usan HTTP para comunicarse; el navegador manda un pedido para recibir una pagina determinada y el servidor responde con una copie de la pagina. El navegador manda un comando HTTP GET como pedido de una pagina web al servidor. El pedido consiste en una línea de texto que empieza con GET seguida de la URL por ejemplo GET GET es un método de solicitud pero existen diversos tipos de solicitudes como OPTIONS, HEAD, POST, PUT, PATCH, COPY, MOVE, DELETE, LINK, UNLNK, TRACE, WRAPPED y otras extensiones que se puedan definir sin modificar el protocolo aunque ni se puede suponer que el receptor los reconozca.

4 EJEMPLOS DE PEDIDOS

5 MENSAJES DE RESPUESTA Un mensaje de respuesta completo consta de una línea de estado seguida por una o mas cabeceras (headers) generales, de respuesta y de entidad seguidas por un cuerpo (opcional) de entidad. Un mensaje de respuesta completo comienza con una Status-Line que tiene el siguiente formato: Status-Line= HTTP-Version SP Status-Code SP Reason-Phrase CRLF El valor de HTTP- Versión es el numero de versión HTTP utilizado por el emisor. Status-Code es un entero de 3 digitos que indica la respuesta a una solicitud recibida y Reason-Phrase proporciona una breve explicación del codigo recibido. En la siguiente tabla se organizan los códigos en diferentes categorías

6 EJEMPLOS DE RESPUESTAS

7

8 Escenario 1 HTTP 1.0 Vs. HTTP 1.1 En este escenario, vamos a exponer las principales diferencias que existen entre la versión anterior del protocolo HTTP (versión 1.0) y la actual (versión 1.1). Destacamos algunos puntos claves, que luego intentaremos confirmar mediante las experiencias realizadas. HTTP V 1.0 Utiliza TCP para realizar las conexiones a través del puerto 80. Las conexiones NO son persistentes, es decir cuando se finaliza la transmisión de un elemento, esta se cierra. No especifica un nombre de host, por lo cual no es compatible con multihomed hosts. Sin soporte para Proxys jerárquicos. HTTP V 1.1 Utiliza TCP para realizar las conexiones a través del puerto 80. Las conexiones son persistentes, y una conexión tcp solo es finalizada cuando se lo requiera explícitamente. Agrega al header un campo denominado host, en el cual se debe especificar donde reside el recurso a obtener. Esto brinda compatibilidad con multi-homed hosts. Agrega soporte para Proxys jerárquicos. Mejoras: En cuanto a las mejoras implementadas, podemos comentar lo siguiente: Conexiones persistentes Favorece a la disminución de tráfico dentro de la red, ya que para cada página se podría mantener una única conexión tcp y descargar todos sus elementos en ella. Esto evitaría tener que abrir una conexión para cada elemento de la página con la consecuente sobrecarga de header innecesario.

9 Adicionalmente se estaría optimizando el uso de tcp dado que el mismo favorece las conexiones más duraderas para maximizar el aprovechamiento del ancho de banda. En el caso de establecer muchas conexiones por pequeño intervalo de tiempo hace que la misma trabaje casi siempre dentro de la zona de slow-start. Al uso de conexiones persistentes también se adiciona el pipeling de solicitudes al servidor, de manera que no se espera la respuesta del mismo para un elemento para mandar el siguiente requerimiento. Soporte para multi-homed hosts En la versión anterior del protocolo si un equipo montaba más de una pagina web bajo la misma ip, era imposible para un cliente indicar a cual de ellas iba destinado el mensaje, dado que el destino era una dirección ip. De esa manera al introducir en la versión actual del protocolo un campo dentro del encabezado denominado host, se puede discriminar dentro de una misma dirección IP múltiples sitios web. Esta mejora es fundamental dado que las direcciones ip son escasas y la posibilidad de asociar mas de un sitio a una misma ip es una posibilidad de ahorro importante, evitando tener para cada sitio web una ip distinta como así lo requería HTTP 1.0. Soporte para Proxys jerárquicos El soporte que presentaba anteriormente para cache, era simple y escaso. Se basaba en utilizar los campos expires, pragma, If-Modified-Since y Last- Modified, sin embargo la especificación completa para cache y proxies es definida explícitamente recién para la versión actual del protocolo. Esta mejora optimiza mas el tráfico dejando a los proxies administrar los recursos obtenidos previamente del servidor.

10 Maqueta del escenario 1: Se utilizó un servidor Apache en Linux para el HTTP 1.1 y un servidor basado en Java en Windows/Linux para el HTTP 1.0. Se utilizó Firefox como cliente web. Se capturaron los datos en el cliente utilizando Wireshark. Capturas Realizamos el pedido de una página web bajo distintas configuraciones Cliente HTTP 1.1 Servidor HTTP 1.0 Cliente HTTP 1.0 Servidor HTTP 1.0 Cliente HTTP 1.0 Servidor HTTP 1.1 Cliente HTTP 1.1 Servidor HTTP 1.1 Cliente HTTP 1.1 Servidor HTTP 1.1 con los objetos almacenados en el navegador Cliente HTTP 1.1 Servidor HTTP 1.1 pedido de un recurso no disponible

11 1) En el primer punto se consulto la página de prueba utilizando un cliente 1.1 y un servidor 1.0, con lo cual comprobamos que para cada elemento que se pedía se generaba una nueva conexión, que finalizaba cuando ese elemento llegaba a destino al cliente. El pedido se generaba con la versión 1.1 por el cliente, pero el servidor contestaba con 1.0 y es por eso que además aparece el campo host, aunque el servidor web no lo toma en cuenta. Cliente HTTP 1.1 Servidor HTTP 1.0

12 2) En este punto se consulto la página de prueba utilizando un cliente 1.0 y un servidor 1.0, con lo cual comprobamos que para cada elemento que se pedía se generaba una nueva conexión, tal como lo pudimos comprobar en el primer caso. Aquí el mensaje de petición es armado desde el cliente con el formato de 1.0, por lo que no aparece el campo de host. De la misma manera que en punto anterior también se cierra la conexión una vez terminada la respuesta por parte del servidor, y es por eso que el siguiente elemento se peticiona abriendo otra conexión tcp desde otro numero de puerto. CLIENTE HTTP 1.0 SERVIDOR HTTP 1.0

13 3) En este punto se consulto la página de prueba utilizando un cliente 1.0 y un servidor 1.1, con lo cual comprobamos que para cada elemento que se pedía se generaba una nueva conexión, tal como lo pudimos comprobar en el primer y segundo caso. Aquí el mensaje de petición es armado desde el cliente con el formato de 1.0, por lo que no aparece el campo de host. De la misma manera que en punto anterior también se cierra la conexión una vez terminada la respuesta por parte del servidor, y eso por eso que el siguiente elemento se peticiona abriendo otra conexión tcp desde otro numero de puerto. Este ejemplo presenta el mismo resultado práctico que el anterior. CLIENTE HTTP 1.0 SERVIDOR HTTP 1.1

14 4) En este punto se consulto la página de prueba utilizando un cliente 1.1 y un servidor 1.1, con lo cual debería utilizarse una única conexión para establecer todas las peticiones para esa pagina, dado que tanto el cliente como el servidor son compatibles con la versión 1.1. Adicionalmente vemos que existe la presencia del campo connection: Keep alive, lo que le indica al servidor que la conexión no debe cerrarse. Sin embargo podemos observar que en este caso también se cierra la conexión una vez descargado el recurso. Esto tiene dos posibles explicaciones: O bien el servidor contesto con un valor en el campo connection: close, con lo cual se inicia el cierre de la sesión TCP; o simplemente el timout configurado bajo el campo keep- Alive se venció, por lo que el resultado es el cierre de la conexión. CLIENTE HTTP 1.1 SERVIDOR HTTP 1.1

15 5) En este punto se consulto la página de prueba una vez más, utilizando un cliente 1.1 y un servidor 1.1. Como esta ya se había cargado, con la información del mensaje utilizado por el cliente, el servidor resuelve que el contenido que le solicitan no ha sido modificado, por lo que responde con un mensaje del tipo 304 (Not modified). Esta respuesta hace que el cliente se dé cuenta de que la página no cambio, con lo que no se transfiere ningún elemento desde el servidor al cliente. Junto con la respuesta del servidor se incluye la orden de cerrar la conexión, dado que no tiene sentido mantenerla abierta. CLIENTE HTTP 1.1 SERVIDOR HTTP 1.1 EL CONTENIDO YA ESTA EN EL CACHE DEL NAVEGADOR

16 6) En este punto se consulto un recurso de la página de prueba una vez más, utilizando un cliente 1.1 y un servidor 1.1. Se trata de obtener del servidor un recurso inexistente, por lo que el mismo contesta con un mensaje 404 (No encontrado) y una petición de cierre de la conexión. CLIENTE HTTP 1.1 SERVIDOR HTTP 1.1 EL RECURSO NO ESTA DISPONIBLE Luego de analizadas las distintas situaciones presentadas y analizando las capturas, podemos ver las limitaciones de la versión anterior del protocolo, y como fueron resueltas en esta ultima versión. Además vimos que en el caso del punto 4, esperamos que se utilice una única conexión para mantener todo el dialogo entre el servidor y el cliente y sin embargo esto no ocurrió, y el comportamiento fue similar al de la versión 1.0. Una explicación para esto es que si bien esta nueva versión soporta el fenómeno de conexiones persistentes, nada dice que no puede actuar con una adecuada configuración de las opciones que brinda como su antecesor.

17 Escenario 2: HTTP Proxy Un Proxy es una aplicación que escucha requerimientos de un cliente para un determinado servicio y los reenvía hacia un servidor remoto. Un HTTP Proxy realiza esta tarea pero para el protocolo HTTP. Los objetivos de utilizar un Proxy pueden ser diversos, pero principalmente se utilizan en organizaciones/instituciones para proveer un acceso a sitios de Internet seguro y en cumplimiento de las políticas adecuadas de uso de la red corporativa. Existen diferentes tipos de Proxy HTTP: Cache Proxy Este tipo de servidor se utiliza para almacenar una copia del recurso HTTP en un cache local, con el fin de evitar que ese mismo recurso sea descargado de la Internet nuevamente por otro cliente, si el contenido original del servidor web no cambió. Esto no solo economiza el uso de ancho de banda de Internet si no que proporciona más velocidad de respuesta en la navegación, ya que el contenido se obtiene de recursos de la red local. Filtering Proxy Este tipo de servidor se utiliza con el fin de limitar el acceso a recursos de Internet que no cumplen con políticas de uso adecuado. Puede incluir filtros por expresiones regulares, sitios prohibidos o sitios marcados en una base de datos como no apropiados. Generalmente, ante un pedido que no cumple con las políticas, el servidor Proxy devuelve una página por defecto indicando que el recurso no estará disponible. Intercepting Proxy Este método intercepta las peticiones HTTP en una red sin el conocimiento del usuario y las redirige al servidor Proxy. El usuario no configura en su navegador la dirección del Proxy. También se lo denomina Proxy Transparente. El servidor Proxy, de no ser transparente, se debe configurar explícitamente en el navegador web, y generalmente tiene asociado el puerto TCP 8080 o TCP Estos tipos de Proxy no son exclusivos, si no que pueden ser complementarios unos de otros. Generalmente en corporaciones/instituciones hay un servidor Proxy por defecto que todos los clientes deben configurar para poder acceder a Internet, que combina un Cache Proxy con un Filtering Proxy. En escenarios donde la configuración de cada equipo resulta difícil, generalmente se implementa también un Intercepting Proxy. Proxies Jerárquicos Estas configuraciones se realizan en organizaciones que poseen una estructura con sub-organizaciones. En este caso, el Proxy Server de una suborganización, si no dispone de un recurso en su cache, consulta al Proxy de la organización antes que salir directamente a Internet. Esto es conveniente ya que de esta forma se puede evitar el uso de un enlace WAN, que es generalmente más costoso. Esta opción surge a partir de HTTP1.1.

18 Describiremos a continuación unas capturas que se realizaron a un Cache Proxy de acuerdo a la siguiente maqueta: Se utilizo el Servidor Proxy Squid y el mismo diagrama del escenario anterior. Primer Pedido Captura CLIENTE PROXY (Desde el cliente) En esta captura se puede observar como el cliente inicia la conexión al puerto TCP 3128 desde un puerto efímero para realizar los pedidos HTTP. Se muestra también que en el GET se utiliza el FQDN completo además del recurso específico, ya que el pedido no se hace directamente al servidor web si no que se realiza a través del servidor Proxy. También se puede observar que el navegador solicita que la conexión con el Proxy se mantenga. (Proxy- Connection: Keep-Alive)

19 Captura PROXY SERVIDOR (Desde el servidor) En esta captura podemos observar que el servidor Proxy solicita el recurso como si fuese un simple cliente HTTP. Próximos pedidos del mismo recurso por parte del cliente (u otros clientes que utilicen el mismo Proxy.). TIPO DE PEDIDO F5 (Actualizar) Ctrl+F5 (Pragma: no-cache) Respuesta Captura de Proxy jerárquico Pide al Proxy el recurso, y de acuerdo a la configuración de la validez de los datos de su cache interno, lo sirve desde el cache o lo recupera del servidor web nuevamente. Fuerza la descarga nuevamente desde el servidor web.

20 Conclusiones Escenario 2: Pudimos ver el funcionamiento básico de un cache-proxy, desde el lado del cliente y desde el lado del servidor, la necesidad de cada header y la ventaja de tener un Proxy, sin embargo, no pudimos verificar realmente que un Proxy almacena la información, y en caso de un pedido de otro cliente, la provee de su cache en vez de utilizar el enlace a Internet nuevamente. Escenario 3: HTTPS HTTPS es un protocolo de transferencia de recursos web de manera segura a través de la unión de los protocolos HTTP y SSL (Secure Socket Layers). Mediante este último protocolo se genera un canal encriptado para dicha aplicación usando el puerto de transporte TCP 443. Es usado principalmente para: Transacciones comerciales Operaciones bancarias Transmisión de datos de manera privada Administración remota Webmail Estos servicios requieren un marco de seguridad en la comunicación ya que implican movimientos de información crítica. El objetivo de este canal encriptado es lograr: 1. Privacidad: Garantizar que la información sólo pueda ser leída por los miembros de la conversación. 2. Autenticación: Evitar que se falsifiquen los mensajes por algún impostor (ataques man in the middle). El servidor siempre debe autenticarse mediante un despliegue de infraestructura de claves públicas (PKI). 3. Integridad de los datos: Que la información llegue completa y sin corrupción en sus datos. De no ser así que sea posible detectarlo por cualquiera de las partes. Cierta integridad ya es proporcionada por la capa transporte mediante TCP. SSL SSL es un servicio de propósito general que yace sobre TCP y da servicio de encriptamiento a la capa de aplicación. Podría ser ubicado en el nivel 6 de la arquitectura OSI (como los protocolos MIME, ASN.1), ya que cumple funciones de presentación al encriptar datos. A su vez también cumple con funciones del nivel 5 de la misma arquitectura ya que permite establecer sesiones, pausarlas y retomarla en otro momento además de aprovechar en una misma sesión el establecimiento de varias conexiones. El uso de SSL no está restringido únicamente a HTTP (443). Otros protocolos también utilizan sus ventajas: FTPS (well known ports TCP 989, 990), TELNETS (992), IMAPS (993) y POP3S (995). La arquitectura de SSL especifica los siguientes protocolos:

21 Aplicación Protocolo SSL Record (Autenticación) Este protocolo es el encargado de transportar en su Payload datos aplicativos o datos de control (handshake, alertas, cambio de algoritmo de cifrado). El tratamiento de los datos es realizado de acuerdo al siguiente esquema: 2 14 Bytes 2da. llave compartida (confidencialidad) Opcional MAC (Message Auth. Code) 1era. llave compartida (integridad) Content type Version mayor de SSL Version menor de SSL Longitud del fragmento (comprimido) Los paquetes de datos son fragmentados en tamaños de hasta 16KB, se los comprime (opcional), se les concatena una M.A.C. (message authentication code: un hash cifrado de los datos que se usa como firma para autenticar cualquiera de los dos remitentes), se encripta el conjunto mediante una llave compartida y se le agrega un header indicando: tipo de contenido (20: cipher change; 21: alert; 22: handshake; 23: aplicación), versiones de SSL soportadas y longitud del fragmento. Protocolo SSL Handshake (Privacidad) Este protocolo es el primero en utilizarse para generar una sesión SSL. Permite a las partes autenticarse mutuamente (el cliente por lo general no es obligado a hacerlo), negociar algoritmos de cifrado y de generación de MAC y llaves de sesión para cifrar el intercambio de mensajes en forma bidireccional (server cliente y viceversa).

22 La idea consiste en utilizar un primer diálogo mediante cifrado asimétrico (usando la clave pública para dirigir mensajes al servidor) para generar una clave compartida de sesión. Una vez generada, el dialogo va encriptado en ambos sentidos mediante dicha clave (simétrica). K sesión Cliente xxxxxx Server K sesión K pública K privada Data Cliente xxxxxx Server Data K sesión K sesión El intercambio protocolar del SSL Handshake se divide a grandes rasgos en dos fases: La fase Hello es usada para ponerse de acuerdo sobre el conjunto de algoritmos para lograr la privacidad y la autenticación mutua una vez establecida una sesión segura. Client Hello, cliente envía: Algoritmos de cifrado y funciones de hash soportadas Numero aleatorio (time stamp de 32 bits + 28B de nros aleatorios) que servirá junto a otro número aleatorio dado por el servidor para generar la clave de sesión favoreciendo el No Replay Versión SSL Session ID (0 = nueva sesión) Server Hello, Certificate, Server Hello done; el servidor envía Certificado digital de identidad (clave pública) X.509 (cadena de certificadoras) Elige el algoritmo de cifrado y la función de hash que cree más seguro de la lista que provee el cliente Session ID (elegida por cliente) La fase de intercambio de claves en que se genera la clave de sesión y se comienza a hablar en cifrado Client Key Exchange, Change Cipher_spec el cliente informa: La verificación del certificado La clave de sesión encriptada con la llave pública del servidor Los próximos datos serán encriptados con dicha clave compartida Server Change Cipher_spec el server informa: Los próximos datos serán encriptados con dicha clave compartida

23 Protocolo SSL Change Cipher_spec (hablar en cifrado) Sirve para avisar que los datos siguientes serán transmitidos de manera encriptada. Protocolo SSL Alert Define un sistema de alertas entre los E.S. Especifica dos tipos de alertas: a) Fatales: SSL termina inmediatamente la conexión. (ej: MAC incorrecta, handshake failure, Certificadora desconocida) b) Advertencias: Avisa anomalías que puedan surgir pero que no afectan la seguridad. (ej.: close notify) Se describe a continuación tres capturas de HTTPS realizadas entre un cliente y varios servidores que soportan dicho protocolo de acuerdo a la siguiente maqueta:

24 Captura al servidor webmail de fi.uba.ar Host iniciando conexión a En esta captura es apreciable que una vez establecida la conexión al puerto TCP 443 de webmail.fi.uba.ar, el cliente comienza el Handshaking de SSL tal como se esperaba de acuerdo a lo investigado y comentado en los párrafos anteriores. Después de haber finalizado dicho protocolo y haber comenzado a hablar en cifrado, el cliente repentinamente inicia la finalización de la conexión de capa de TCP al puerto 443. A su vez el servidor envía un mensaje de alerta. Paradójicamente, a esta altura del diálogo, es imposible detectar que tipo de mensaje de alerta fue mandado ya que está encriptado, sin embargo en el web browser apareció el siguiente cartel de advertencia:

25 Este mensaje indica que hay un problema con el certificado de clave publica del servidor y requiere de la autorización del usuario para continuar. Lo más probable es que en el browser cliente no se haya registrado la Autoridad Emisora del certificado de clave del Servidor como una Entidad de confianza y por eso se prefiere dar por terminada la sesión para que el usuario se dé por aludido de dicha falencia y sea él quien se responsabilice de seguir adelante. Captura al servidor webmail de hotmail.com Host iniciando conexión a Una vez más se comprueba el uso del HandShaking para establecer los parámetros de conexión segura. En esta captura hay dos cosas interesantes para destacar: la ausencia de alertas por parte de ambos E.S. y el time stamp que usa el cliente para establecer una segunda sesión en el servidor. La ausencia de alertas probablemente se deba a que el web browser reconoce a la Autoridad Emisora del Certificado de clave pública del Servidor como confiable. Dicha Autoridad no es más ni menos que VeriSign, un referente en todo lo que respecta a Certificaciones en Internet. Además dicho certificado consta de una cadena de tres certificaciones para darle aún mayor autenticidad. En segundo lugar es interesante destacar que el time stamp (que se utiliza para crear una clave compartida de sesión) generado en el Cliente no tiene ninguna correlación con la fecha actual favoreciendo de esta manera el No Replay.

26 Captura de Host iniciando sesión de MSN Host iniciando conexión al servidor MSN Nuevamente en esta captura hecha en base a la iniciación de una conexión al MSN Messenger se puede apreciar la difusión que tiene el protocolo HTTPS y que no sólo se restringe a navegadores web. En esta ocasión el Cliente, como en las anteriores veces, realiza el HandShaking e intercambia cierta información sensible mediante cifrado. Probablemente lo que se intercambia es la clave de la cuenta hotmail. Es interesante destacar que de ser así es lo único que se transmite vía HTTPS, el resto de la información: usuario, lista de contactos y mismo mensajes son transmitidos en limpio. Conclusiones Escenario 3: Se logró demostrar el funcionamiento de HTTP montado en SSL. Fue apreciable el uso del protocolo de SSL HandShaking para establecer comunicaciones encriptadas para pasar datos sensibles. Fue posible documentar el uso del sistema de alarmas ante imprevistos como el desconocimiento por parte del Web Browser de la confiabilidad del certificado de clave pública del servidor. Se destacó una técnica para favorecer el No Replay a partir de la generación de un time stamp descorrelacionado con la fecha actual más 28 Bytes aleatorios. Y se pudo observar que HTTPS es de uso general y que no está únicamente restringido a web-browsers.