FACULTAD DE INGENIERA

UNIVERSIDAD DE BUENOS AIRES

66.48 Seminario de Redes de Computadora

Trabajo Prctico N 1 HTTP

Hyper Text Transfer Protocol
Integrantes: - Santiago Boeri (79529) - Hernn Castagnola (79555) - Christian Picot (80297) - Toms Shulman (84050) Profesores: - Marcelo Utard - Pablo Ronco - Javier Bozzuto

Introduccin: En este trabajo prctico examinaremos como es el protocolo primario usado para la transferencia de paginas web desde un servidor hacia un navegador web. Actualmente la transferencia de pginas web ocupa el 75% del trfico de Internet. Arquitectura Conceptualmente la Web consiste en un gran set de documentos llamados pginas 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 adems de texto grficos, imgenes, 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 gua de cmo deben estar ubicados los elementos de la pagina resultante. Uniform Resource Locators Cada pgina 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 tendra la siguiente forma: http:// hostname (FQDN o IP) [:port] / path [; parmetros] [?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, ;parmetros son cadenas que especifican parmetros 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 comunicacin 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 comunicacin 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 caractersticas: Nivel de aplicacin: http opera en el nivel de aplicacin. Utiliza TCP para asumir confiabilidad y conexin, pero no provee confiabilidad o retransmisin por si mismo.

Pedido/Respuesta: una vez que la sesin 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 sesin anterior. Transferencia bidireccional: http permite la transferencia desde un navegador a un servidor. Capacidad de negociacin. 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 direccin IP y usa la direccin IP para establecer una conexin TCP al servidor. Una vez que la conexin 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 lnea de texto que empieza con GET seguida de la URL por ejemplo GET http://www.fi.uba.ar/materias GET es un mtodo 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.

EJEMPLOS DE PEDIDOS

MENSAJES DE RESPUESTA Un mensaje de respuesta completo consta de una lnea 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- Versin es el numero de versin 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 explicacin del codigo recibido. En la siguiente tabla se organizan los cdigos en diferentes categoras

EJEMPLOS DE RESPUESTAS

Escenario 1 HTTP 1.0 Vs. HTTP 1.1 En este escenario, vamos a exponer las principales diferencias que existen entre la versin anterior del protocolo HTTP (versin 1.0) y la actual (versin 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 travs del puerto 80. Las conexiones NO son persistentes, es decir cuando se finaliza la transmisin 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 jerrquicos.

HTTP V 1.1

Utiliza TCP para realizar las conexiones a travs del puerto 80. Las conexiones son persistentes, y una conexin tcp solo es finalizada cuando se lo requiera explcitamente. 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 jerrquicos. Mejoras: En cuanto a las mejoras implementadas, podemos comentar lo siguiente: Conexiones persistentes Favorece a la disminucin de trfico dentro de la red, ya que para cada pgina se podra mantener una nica conexin tcp y descargar todos sus elementos en ella. Esto evitara tener que abrir una conexin para cada elemento de la pgina con la consecuente sobrecarga de header innecesario.

Adicionalmente se estara optimizando el uso de tcp dado que el mismo favorece las conexiones ms duraderas para maximizar el aprovechamiento del ancho de banda. En el caso de establecer muchas conexiones por pequeo intervalo de tiempo hace que la misma trabaje casi siempre dentro de la zona de slow-start. Al uso de conexiones persistentes tambin 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 versin anterior del protocolo si un equipo montaba ms 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 direccin ip. De esa manera al introducir en la versin actual del protocolo un campo dentro del encabezado denominado host, se puede discriminar dentro de una misma direccin IP mltiples 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 requera HTTP 1.0.

Soporte para Proxys jerrquicos El soporte que presentaba anteriormente para cache, era simple y escaso. Se basaba en utilizar los campos expires, pragma, If-Modified-Since y LastModified, sin embargo la especificacin completa para cache y proxies es definida explcitamente recin para la versin actual del protocolo. Esta mejora optimiza mas el trfico dejando a los proxies administrar los recursos obtenidos previamente del servidor.

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 pgina 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

1) En el primer punto se consulto la pgina de prueba utilizando un cliente 1.1 y un servidor 1.0, con lo cual comprobamos que para cada elemento que se peda se generaba una nueva conexin, que finalizaba cuando ese elemento llegaba a destino al cliente. El pedido se generaba con la versin 1.1 por el cliente, pero el servidor contestaba con 1.0 y es por eso que adems aparece el campo host, aunque el servidor web no lo toma en cuenta.

Cliente HTTP 1.1 Servidor HTTP 1.0

2) En este punto se consulto la pgina de prueba utilizando un cliente 1.0 y un servidor 1.0, con lo cual comprobamos que para cada elemento que se peda se generaba una nueva conexin, tal como lo pudimos comprobar en el primer caso. Aqu el mensaje de peticin 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 tambin se cierra la conexin una vez terminada la respuesta por parte del servidor, y es por eso que el siguiente elemento se peticiona abriendo otra conexin tcp desde otro numero de puerto.

CLIENTE HTTP 1.0 SERVIDOR HTTP 1.0

3) En este punto se consulto la pgina de prueba utilizando un cliente 1.0 y un servidor 1.1, con lo cual comprobamos que para cada elemento que se peda se generaba una nueva conexin, tal como lo pudimos comprobar en el primer y segundo caso. Aqu el mensaje de peticin 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 tambin se cierra la conexin una vez terminada la respuesta por parte del servidor, y eso por eso que el siguiente elemento se peticiona abriendo otra conexin tcp desde otro numero de puerto. Este ejemplo presenta el mismo resultado prctico que el anterior.

CLIENTE HTTP 1.0 SERVIDOR HTTP 1.1

4) En este punto se consulto la pgina de prueba utilizando un cliente 1.1 y un servidor 1.1, con lo cual debera utilizarse una nica conexin para establecer todas las peticiones para esa pagina, dado que tanto el cliente como el servidor son compatibles con la versin 1.1. Adicionalmente vemos que existe la presencia del campo connection: Keep alive, lo que le indica al servidor que la conexin no debe cerrarse. Sin embargo podemos observar que en este caso tambin se cierra la conexin 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 sesin TCP; o simplemente el timout configurado bajo el campo keepAlive se venci, por lo que el resultado es el cierre de la conexin.

CLIENTE HTTP 1.1 SERVIDOR HTTP 1.1

5) En este punto se consulto la pgina de prueba una vez ms, utilizando un cliente 1.1 y un servidor 1.1. Como esta ya se haba cargado, con la informacin 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 pgina no cambio, con lo que no se transfiere ningn elemento desde el servidor al cliente. Junto con la respuesta del servidor se incluye la orden de cerrar la conexin, dado que no tiene sentido mantenerla abierta.

CLIENTE HTTP 1.1 SERVIDOR HTTP 1.1 EL CONTENIDO YA ESTA EN EL CACHE DEL NAVEGADOR

6) En este punto se consulto un recurso de la pgina de prueba una vez ms, 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 peticin de cierre de la conexin.

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 versin anterior del protocolo, y como fueron resueltas en esta ultima versin. Adems vimos que en el caso del punto 4, esperamos que se utilice una nica conexin 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 versin 1.0. Una explicacin para esto es que si bien esta nueva versin soporta el fenmeno de conexiones persistentes, nada dice que no puede actuar con una adecuada configuracin de las opciones que brinda como su antecesor.

Escenario 2: HTTP Proxy Un Proxy es una aplicacin que escucha requerimientos de un cliente para un determinado servicio y los reenva 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 polticas 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 ms velocidad de respuesta en la navegacin, 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 polticas 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 polticas, el servidor Proxy devuelve una pgina por defecto indicando que el recurso no estar disponible. Intercepting Proxy Este mtodo 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 direccin del Proxy. Tambin se lo denomina Proxy Transparente. El servidor Proxy, de no ser transparente, se debe configurar explcitamente en el navegador web, y generalmente tiene asociado el puerto TCP 8080 o TCP 3128. 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 configuracin de cada equipo resulta difcil, generalmente se implementa tambin un Intercepting Proxy. Proxies Jerrquicos Estas configuraciones se realizan en organizaciones que poseen una estructura con sub-organizaciones. En este caso, el Proxy Server de una suborganizacin, si no dispone de un recurso en su cache, consulta al Proxy de la organizacin 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 ms costoso. Esta opcin surge a partir de HTTP1.1.

Describiremos a continuacin 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 conexin al puerto TCP 3128 desde un puerto efmero para realizar los pedidos HTTP. Se muestra tambin que en el GET se utiliza el FQDN completo adems del recurso especfico, ya que el pedido no se hace directamente al servidor web si no que se realiza a travs del servidor Proxy. Tambin se puede observar que el navegador solicita que la conexin con el Proxy se mantenga. (ProxyConnection: Keep-Alive)

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. Prximos 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 Pide al Proxy el recurso, y de Fuerza la descarga acuerdo a la configuracin de nuevamente desde el la validez de los datos de su servidor web. cache interno, lo sirve desde el cache o lo recupera del servidor web nuevamente. Captura de Proxy jerrquico

Conclusiones Escenario 2: Pudimos ver el funcionamiento bsico 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 informacin, 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 travs de la unin de los protocolos HTTP y SSL (Secure Socket Layers). Mediante este ltimo protocolo se genera un canal encriptado para dicha aplicacin usando el puerto de transporte TCP 443. Es usado principalmente para: Transacciones comerciales Operaciones bancarias Transmisin de datos de manera privada Administracin remota Webmail Estos servicios requieren un marco de seguridad en la comunicacin ya que implican movimientos de informacin crtica. El objetivo de este canal encriptado es lograr: 1. Privacidad: Garantizar que la informacin slo pueda ser leda por los miembros de la conversacin. 2. Autenticacin: Evitar que se falsifiquen los mensajes por algn impostor (ataques man in the middle). El servidor siempre debe autenticarse mediante un despliegue de infraestructura de claves pblicas (PKI). 3. Integridad de los datos: Que la informacin llegue completa y sin corrupcin 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 propsito general que yace sobre TCP y da servicio de encriptamiento a la capa de aplicacin. Podra ser ubicado en el nivel 6 de la arquitectura OSI (como los protocolos MIME, ASN.1), ya que cumple funciones de presentacin al encriptar datos. A su vez tambin cumple con funciones del nivel 5 de la misma arquitectura ya que permite establecer sesiones, pausarlas y retomarla en otro momento adems de aprovechar en una misma sesin el establecimiento de varias conexiones. El uso de SSL no est restringido nicamente a HTTP (443). Otros protocolos tambin 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:

Aplicacin

Protocolo SSL Record (Autenticacin) 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:

214 Bytes Opcional

2da. llave compartida (confidencialidad)

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 tamaos 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: aplicacin), versiones de SSL soportadas y longitud del fragmento. Protocolo SSL Handshake (Privacidad) Este protocolo es el primero en utilizarse para generar una sesin SSL. Permite a las partes autenticarse mutuamente (el cliente por lo general no es obligado a hacerlo), negociar algoritmos de cifrado y de generacin de MAC y llaves de sesin para cifrar el intercambio de mensajes en forma bidireccional (server cliente y viceversa).

La idea consiste en utilizar un primer dilogo mediante cifrado asimtrico (usando la clave pblica para dirigir mensajes al servidor) para generar una clave compartida de sesin. Una vez generada, el dialogo va encriptado en ambos sentidos mediante dicha clave (simtrica). xxxxxx Ksesin
Cliente Server

Ksesin

Kpblica

Kprivada xxxxxx

Data

Cliente

Server

Data

Ksesin

Ksesin

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 autenticacin mutua una vez establecida una sesin segura. Client Hello, cliente enva: Algoritmos de cifrado y funciones de hash soportadas Numero aleatorio (time stamp de 32 bits + 28B de nros aleatorios) que servir junto a otro nmero aleatorio dado por el servidor para generar la clave de sesin favoreciendo el No Replay Versin SSL Session ID (0 = nueva sesin) Server Hello, Certificate, Server Hello done; el servidor enva Certificado digital de identidad (clave pblica) X.509 (cadena de certificadoras) Elige el algoritmo de cifrado y la funcin de hash que cree ms 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 sesin y se comienza a hablar en cifrado Client Key Exchange, Change Cipher_spec el cliente informa: La verificacin del certificado La clave de sesin encriptada con la llave pblica del servidor Los prximos datos sern encriptados con dicha clave compartida Server Change Cipher_spec el server informa: Los prximos datos sern encriptados con dicha clave compartida

Protocolo SSL Change Cipher_spec (hablar en cifrado) Sirve para avisar que los datos siguientes sern 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 conexin. (ej: MAC incorrecta, handshake failure, Certificadora desconocida) b) Advertencias: Avisa anomalas que puedan surgir pero que no afectan la seguridad. (ej.: close notify)

Se describe a continuacin tres capturas de HTTPS realizadas entre un cliente y varios servidores que soportan dicho protocolo de acuerdo a la siguiente maqueta:

Captura al servidor webmail de fi.uba.ar

Host iniciando conexin a https://webmail.fi.uba.ar

En esta captura es apreciable que una vez establecida la conexin 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 prrafos anteriores. Despus de haber finalizado dicho protocolo y haber comenzado a hablar en cifrado, el cliente repentinamente inicia la finalizacin de la conexin de capa de TCP al puerto 443. A su vez el servidor enva un mensaje de alerta. Paradjicamente, a esta altura del dilogo, 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:

Este mensaje indica que hay un problema con el certificado de clave publica del servidor y requiere de la autorizacin del usuario para continuar. Lo ms 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 sesin 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 conexin a https://login.live.com

Una vez ms se comprueba el uso del HandShaking para establecer los parmetros de conexin 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 sesin en el servidor. La ausencia de alertas probablemente se deba a que el web browser reconoce a la Autoridad Emisora del Certificado de clave pblica del Servidor como confiable. Dicha Autoridad no es ms ni menos que VeriSign, un referente en todo lo que respecta a Certificaciones en Internet. Adems dicho certificado consta de una cadena de tres certificaciones para darle an mayor autenticidad. En segundo lugar es interesante destacar que el time stamp (que se utiliza para crear una clave compartida de sesin) generado en el Cliente no tiene ninguna correlacin con la fecha actual favoreciendo de esta manera el No Replay.

Captura de Host iniciando sesin de MSN

Host iniciando conexin al servidor MSN

Nuevamente en esta captura hecha en base a la iniciacin de una conexin al MSN Messenger se puede apreciar la difusin que tiene el protocolo HTTPS y que no slo se restringe a navegadores web. En esta ocasin el Cliente, como en las anteriores veces, realiza el HandShaking e intercambia cierta informacin 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 va HTTPS, el resto de la informacin: 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 pblica del servidor. Se destac una tcnica para favorecer el No Replay a partir de la generacin de un time stamp descorrelacionado con la fecha actual ms 28 Bytes aleatorios. Y se pudo observar que HTTPS es de uso general y que no est nicamente restringido a web-browsers.