Workshop de HTTP leaked version 1

Tamaño: px

Comenzar la demostración a partir de la página:

Download "Workshop de HTTP leaked version 1"

José Carlos Rubio Muñoz
hace 10 años
Vistas:

1 66.62 Redes de Computadoras Workshop de HTTP leaked version 1 Matsunaga, Nicolás 1 esto significa que está más que incompleto 1. er cuatrimestre 2012

2 ÍNDICE Índice 1. Objetivo del apunte 2 2. Introducción 2 3. Consultas con telnet Prueba 1 - Consulta Básica Prueba 2 - Redirección Prueba 3 - HTTP/ Prueba 4 - Virtualhosts Prueba 5 - Autenticación Prueba 6 - HEAD Prueba 7 - Método inexistente PGET Prueba 8 - Proxy a un no-proxy Prueba 9 - método CONNECT

3.5. Prueba 5 - Autenticación........................ 6 3.6. Prueba 6 - HEAD............................ 7 3.7. Prueba 7 - Método inexistente PGET.

3 1 Objetivo del apunte 1. Objetivo del apunte El objetivo de este apunte será introducir al alumno en el mundo real en el uso del protocolo HTTP, que es uno de los componentes de Internet más importantes. 2. Introducción Para las prácticas de este taller utilizaremos la siguientes herramientas: telnet: es un utilitario de entorno Linux/Unix/Windows que para establecer conexiones TCP en modo texto. 3. Consultas con telnet En esta sección veremos las consultas más típicas que pueden hacerse con el utilitario telnet. Por el momento nos restringiremos a realizar operaciones de tipo GET. Convención de colores en magenta indicaremos el Full-Request en verde resaltaremos algunos headers relacionados con una respuesta exitosa en rojo resaltaremos algunos headers relacionados con una respuesta no exitosa en azul resaltaremos el entity-body 3.1. Prueba 1 - Consulta Básica GET / HTTP/1.0 GET / HTTP/1.0 Date: Sun, 10 Jun :36:37 GMT Last-Modified: Sun, 10 Jun :36:27 GMT ETag: "86974-a-4c21bce3f40c0" Content-Length: 10 Anda bien 2

Introducción Para las prácticas de este taller utilizaremos la siguientes herramientas: telnet: es un utilitario de entorno Linux/Unix/Windows que para establecer conexiones TCP en modo texto. 3.

4 3.2 Prueba 2 - Redirección Aquí observamos que la petición fue exitosa y vemos como el server nos cierra la conexión. Además implementa correctamente HTTP 1.0 que especifica que la respuesta debe contener al header Content-Length. En servidores que no implementan correctamente, la longitud podría llegar a deducirse por el cierre de la conexión 2. Cuando especificamos un sólamente un directorio como URI, el servidor HTTP busca el archivo por default en dicho directorio. En este caso fue el index.html, pero esto depende de la configuración del servidor web Prueba 2 - Redirección GET /otros HTTP/1.0 GET /otros HTTP/1.0 HTTP/ Moved Permanently Date: Sun, 10 Jun :39:27 GMT Location: Content-Length: 325 Content-Type: text/html; charset=iso <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>moved Permanently</h1> <p>the document has moved <a href=" <hr> <address>apache/2.2.3 (CentOS) Server at default.example.com Port 80</address> </body></html> Aquí observamos que la respuesta es una redirección permanente. En este caso se debe a que el URI relativo /otros se refiere a un directorio y entonces el servidor HTTP interpreta que quisimos poner /otros/. Éso nos lo comunica a través del header Location. GET /otros/ HTTP/1.0 GET /otros/ HTTP/1.0 Date: Sun, 10 Jun :40:11 GMT Last-Modified: Sun, 10 Jun :39:14 GMT ETag: "86995-f-4c21bd " 2 aunque podría ser el caso de que la conexión se cortó y nunca se sabría si todo el contenido fue transferido 3

Cuando especificamos un sólamente un directorio como URI, el servidor HTTP busca el archivo por default en dicho directorio. En este caso fue el index.

5 3.3 Prueba 3 - HTTP/1.1 Content-Length: 15 otro contenido Ahora funciona correctamente. El rehacer la consulta con el URI especificado por el header Location nosotros hicimos a mano, pero el browser lo hace automáticamente Prueba 3 - HTTP/1.1 HTTP/ Bad Request Date: Sun, 10 Jun :40:53 GMT Content-Length: 310 Content-Type: text/html; charset=iso <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>400 Bad Request</title> </head><body> <h1>bad Request</h1> <p>your browser sent a request that this server could not understand.<br /> </p> <hr> <address>apache/2.2.3 (CentOS) Server at default.example.com Port 80</address> </body></html> Aquí intentamos hacer una petición similar a la de la subsección 3.1 pero sólo cambiando la versión de HTTP/1.0 a HTTP/1.1. Y vemos que no funciona porque se en HTTP 1.1 es obligatorio el uso del header Host. Lo que nos da es un código de estado 4XY 3, en particular el 400 que significa que la petición no está bien hecha. Host: Host: Date: Sun, 10 Jun :42:29 GMT 3 Recordemos que los códigos 4XY corresponden a errores causados por el usuario. 4

1 400 Bad Request Date: Sun, 10 Jun 2012 10:40:53 GMT Content-Length: 310 Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.

6 3.4 Prueba 4 - Virtualhosts Last-Modified: Sun, 10 Jun :36:27 GMT ETag: "86974-a-4c21bce3f40c0" Content-Length: 10 Anda bien Cuando le agregamos el header Host la petición es exitosa Prueba 4 - Virtualhosts Una funcionalidad que brinda HTTP 1.1 es el VirtualHosting. Esto permite que haya varios sitios hosteados en una misma IP. La discriminación para permitir elegir el sitio se hace a través del header Host. A continuación veremos dos Request- Lines idénticas () que dan resultados distintos ya que apuntan a distintos virtualhosts (ocio.example.com y trabajo.example.com). Host: ocio.example.com Host: ocio.example.com Date: Sun, 10 Jun :43:53 GMT Last-Modified: Mon, 23 May :42:31 GMT ETag: "8696d-12-4a3f6ac1237c0" Content-Length: 18 aca hacemos fiaca Host: trabajo.example.com Host: trabajo.example.com Date: Sun, 10 Jun :45:28 GMT Last-Modified: Mon, 23 May :42:49 GMT ETag: "8696e-18-4a3f6ad24e040" Content-Length: 24 5

A continuación veremos dos Request- Lines idénticas () que dan resultados distintos ya que apuntan a distintos virtualhosts (ocio.example.com y trabajo.example.com). Host: ocio.example.com Host: ocio.

7 3.5 Prueba 5 - Autenticación uy.. hay que laburar :( 3.5. Prueba 5 - Autenticación GET /secreto/ HTTP/1.0 GET /secreto/ HTTP/1.0 HTTP/ Authorization Required Date: Sun, 10 Jun :53:13 GMT WWW-Authenticate: Basic realm="webpage Top Secret" Content-Length: 485 Content-Type: text/html; charset=iso <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>401 Authorization Required</title> </head><body> <h1>authorization Required</h1> <p>this server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn t understand how to supply the credentials required.</p> <hr> <address>apache/2.2.3 (CentOS) Server at default.example.com Port 80</address> </body></html> GET /secreto/ HTTP/1.0 Authorization: Basic YWx1bW5vOmVzdHVkaWFy GET /secreto/ HTTP/1.0 Authorization: Basic YWx1bW5vOmVzdHVkaWFy Date: Sun, 10 Jun :00:33 GMT Last-Modified: Sun, 10 Jun :48:26 GMT ETag: " c21bf91a5280" Content-Length: 48 si ves esto sabes el secreto para aprobar redes 6

DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.

8 3.6 Prueba 6 - HEAD Para saber cual es el secreto para aprobar la materia, busquen en Google base64 decoder y copien y peguen YWx1bW5vOmVzdHVkaWFy. Recuerden que en el URI la autenticación se ponía user:password o en este caso para darle más sentido user:secret :) Prueba 6 - HEAD Con el método HEAD sólo traigo los header que hubiese obtenido de hacer una operación GET. HEAD /otros/karl640.jpg HTTP/1.0 HEAD /otros/karl640.jpg HTTP/1.0 Date: Sun, 10 Jun :10:32 GMT Last-Modified: Sun, 10 Jun :10:33 GMT ETag: W/" c22226a70800" Content-Length: Content-Type: image/jpeg X-Pad: avoid browser bug Aquí podemos ver que el recurso al que apuntamos es una imagen jpeg cuyo tamaño es Bytes Prueba 7 - Método inexistente PGET Ahora vamos a pedirle una consulta de Proxy a un servidor HTTP. PGET HTTP/1.0 PGET HTTP/1.0 HTTP/ Method Not Implemented Date: Sun, 10 Jun :15:14 GMT Allow: GET,HEAD,POST,OPTIONS,TRACE Content-Length: 295 Content-Type: text/html; charset=iso <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>501 Method Not Implemented</title> </head><body> <h1>method Not Implemented</h1> <p>pget to /index.html not supported.<br /> 7

Prueba 6 - HEAD Con el método HEAD sólo traigo los header que hubiese obtenido de hacer una operación GET. HEAD /otros/karl640.jpg HTTP/1.

9 3.8 Prueba 8 - Proxy a un no-proxy </p> <hr> <address>apache/2.2.3 (CentOS) Server at Port 80</address> </body></html> Lo que observamos es que el servidor da un código 501, método no implementado. Acá vemos que no dió bad request ya que HTTP es extensible. También podemos ver el header Allow donde dice que métodos soporta el server al cual nos conectamos Prueba 8 - Proxy a un no-proxy GET HTTP/1.0 GET HTTP/1.0 Date: Sun, 10 Jun :28:41 GMT Last-Modified: Sun, 10 Jun :36:27 GMT ETag: "86974-a-4c21bce3f40c0" Content-Length: 10 Anda bien Notar que el servidor nos responde con su recurso /. Es decir que saca el network path de la URL. Además verificamos que la máquina ni siquiera tiene una ruta para dicho fqdn. Notar que sí resolvió el nombre porque sino no hubiese podido determinar qué no tiene una ruta hacia ese destino. # ping connect: Network is unreachable Para terminar de convencernos que le saca el network path hacemos un request de pero nos delvolverá el recurso /otros/. GET HTTP/1.0 GET HTTP/1.0 Date: Sun, 10 Jun :31:42 GMT Last-Modified: Sun, 10 Jun :39:14 GMT 8

También podemos ver el header Allow donde dice que métodos soporta el server al cual nos conectamos. 3.8. Prueba 8 - Proxy a un no-proxy GET http://www.google.com/ HTTP/1.

10 3.9 Prueba 9 - método CONNECT ETag: "86995-f-4c21bd " Content-Length: 15 otro contenido 3.9. Prueba 9 - método CONNECT CONNECT HTTP/1.0 # telnet Trying Connected to coriolis.uyr.com.ar ( ). CONNECT HTTP/1.0 HTTP/ Connection established...(acá es donde empieza la parte de tráfico segurizado) Aquí observamos el funcionamiento de HTTP en modo túnel a través de un proxy. De esta manera puede existir una comunicación encriptada end-to-end. Es decir, que NO hay encriptación y desencriptación en cada sistema intermedio. La encriptación es punto a punto, por eso es un túnel. 9

..(acá es donde empieza la parte de tráfico segurizado) Aquí observamos el funcionamiento de HTTP en modo túnel a través de un proxy.

Documentos relacionados

HTTP Introducción. Redes de Datos Ing. Marcelo Utard / Ing. Pablo Ronco FACULTAD DE INGENIERIA UNIVERSIDAD DE BUENOS AIRES

HTTP Introducción. Redes de Datos Ing. Marcelo Utard / Ing. Pablo Ronco FACULTAD DE INGENIERIA UNIVERSIDAD DE BUENOS AIRES Introducción Protocolo de capa de aplicación utilizado para la transferencia de Recursos u objetos. Opera sobre TCP típicamente en el puerto 80 Simple Stateless Genérico Utiliza las extenciones MIME. Transporte