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
ÍNDICE Índice 1. Objetivo del apunte 2 2. Introducción 2 3. Consultas con telnet 2 3.1. Prueba 1 - Consulta Básica...................... 2 3.2. Prueba 2 - Redirección......................... 3 3.3. Prueba 3 - HTTP/1.1......................... 4 3.4. Prueba 4 - Virtualhosts......................... 5 3.5. Prueba 5 - Autenticación........................ 6 3.6. Prueba 6 - HEAD............................ 7 3.7. Prueba 7 - Método inexistente PGET................. 7 3.8. Prueba 8 - Proxy a un no-proxy.................... 8 3.9. Prueba 9 - método CONNECT.................... 9 1
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 2012 10:36:37 GMT Last-Modified: Sun, 10 Jun 2012 10:36:27 GMT ETag: "86974-a-4c21bce3f40c0" Content-Length: 10 Anda bien 2
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. 3.2. Prueba 2 - Redirección GET /otros HTTP/1.0 GET /otros HTTP/1.0 HTTP/1.1 301 Moved Permanently Date: Sun, 10 Jun 2012 10:39:27 GMT Location: http://default.example.com/otros/ Content-Length: 325 Content-Type: text/html; charset=iso-8859-1 <!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="http://default.example.com/otros/">here</a>.</p> <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 2012 10:40:11 GMT Last-Modified: Sun, 10 Jun 2012 10:39:14 GMT ETag: "86995-f-4c21bd8337880" 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
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. 3.3. Prueba 3 - HTTP/1.1 HTTP/1.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.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: 192.168.92.136 Host: 192.168.92.136 Date: Sun, 10 Jun 2012 10:42:29 GMT 3 Recordemos que los códigos 4XY corresponden a errores causados por el usuario. 4
3.4 Prueba 4 - Virtualhosts Last-Modified: Sun, 10 Jun 2012 10:36:27 GMT ETag: "86974-a-4c21bce3f40c0" Content-Length: 10 Anda bien Cuando le agregamos el header Host la petición es exitosa. 3.4. 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 2012 10:43:53 GMT Last-Modified: Mon, 23 May 2011 19: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 2012 10:45:28 GMT Last-Modified: Mon, 23 May 2011 19:42:49 GMT ETag: "8696e-18-4a3f6ad24e040" Content-Length: 24 5
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/1.1 401 Authorization Required Date: Sun, 10 Jun 2012 10:53:13 GMT WWW-Authenticate: Basic realm="webpage Top Secret" Content-Length: 485 Content-Type: text/html; charset=iso-8859-1 <!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 2012 11:00:33 GMT Last-Modified: Sun, 10 Jun 2012 10:48:26 GMT ETag: "86997-30-4c21bf91a5280" Content-Length: 48 si ves esto sabes el secreto para aprobar redes 6
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 :). 3.6. 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 2012 11:10:32 GMT Last-Modified: Sun, 10 Jun 2012 11:10:33 GMT ETag: W/"86996-5404-4c22226a70800" Content-Length: 21508 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 21508 Bytes. 3.7. Prueba 7 - Método inexistente PGET Ahora vamos a pedirle una consulta de Proxy a un servidor HTTP. PGET http://www.google.com/ HTTP/1.0 PGET http://www.google.com/ HTTP/1.0 HTTP/1.1 501 Method Not Implemented Date: Sun, 10 Jun 2012 17:15:14 GMT Allow: GET,HEAD,POST,OPTIONS,TRACE Content-Length: 295 Content-Type: text/html; charset=iso-8859-1 <!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
3.8 Prueba 8 - Proxy a un no-proxy </p> <hr> <address>apache/2.2.3 (CentOS) Server at www.google.com 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. 3.8. Prueba 8 - Proxy a un no-proxy GET http://www.google.com/ HTTP/1.0 GET http://www.google.com/ HTTP/1.0 Date: Sun, 10 Jun 2012 17:28:41 GMT Last-Modified: Sun, 10 Jun 2012 10: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 www.google.com connect: Network is unreachable Para terminar de convencernos que le saca el network path hacemos un request de http://www.google.com/otros/ pero nos delvolverá el recurso /otros/. GET http://www.google.com/otros/ HTTP/1.0 GET http://www.google.com/otros/ HTTP/1.0 Date: Sun, 10 Jun 2012 17:31:42 GMT Last-Modified: Sun, 10 Jun 2012 10:39:14 GMT 8
3.9 Prueba 9 - método CONNECT ETag: "86995-f-4c21bd8337880" Content-Length: 15 otro contenido 3.9. Prueba 9 - método CONNECT CONNECT www.facebook.com:443/ HTTP/1.0 # telnet 127.0.0.1 3128 Trying 127.0.0.1... Connected to coriolis.uyr.com.ar (127.0.0.1). CONNECT www.facebook.com:443/ HTTP/1.0 HTTP/1.0 200 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