Tema 6. Protocolos de Nivel de Aplicación

Transcripción

1 Tema 6. Protocolos de Nivel de Aplicación Ingeniería de protocolos Curso 2012/13 Jaime Benjumea Mondéjar Dpto. Tecnología Electrónica (Univ. de Sevilla) 1

2 DNS. Introducción Página Web de la Universidad de Sevilla? Suponiendo que usamos el protocolo IP, la respuesta correcta sería: Es difícil aprenderse 4 números para cada sitio web que quiera acceder. Pero el nivel de red (IP) sólo sabe manejarse con números de 32-bits SOLUCIÓN: Utilizar algún mecanismo que permita traducir un nombre (más sencillo de recordar) y lo traduzca a una dirección IP. Sistema DNS

3 DNS. Introducción Cómo organizar un sistema que, conociendo un nombre de un servidor, pueda obtener su dirección IP? OPCIÓN 1: Estructura de nombres no jerárquica (centralizada) Un único punto de información (servidor) Maq1 IP1 Maq2 IP2 Un fichero de texto en el que aparecen todos los nombres y su correspondiente dirección IP. Clientes: Realizan copias periódicas del fichero que tiene el servidor Es el esquema original en Internet, había pocos nodos y era el esquema más sencillo, pero es poco escalable. Al crecer el número de nodos, aumentaba la burocracia en la gestión del nodo principal, requería actualizaciones más frecuentes de los clientes, aumentaba el tráfico hacia el nodo principal, constituía un punto crítico de la red. Es necesario diseñar un sistema nuevo: DNS (Domain Name Service).

4 DNS. Introducción OPCIÓN 2: Estructura de nombres jerárquica (distribuida). En el sistema DNS, cada servidor solo mantiene una base de datos con los datos de SU ámbito. Nodo principal (raíz del árbol) Servidor DNS: Contiene SU parte de la estructura DNS; hace consultas a otros servidores Tráfico entre servidores DNS. Ordenador final: Sólo hace consultas a SU servidor DNS. Tráfico de un ordenador final con su servidor DNS. Los ordenadores finales (a través del resolver ), sólo interactúan con su servidor DNS y nunca con el resto de la jerarquía. Cada servidor DNS mantiene los datos de su parte y acepta consultas ya sea de otros servidores como de ordenadores finales. Si no conoce un dato, lo buscará en la jerarquía.

5 DNS. Estructura. Nodo raíz: root Profundidad máxima: 127 niveles org es cnm us com Dominios de primer nivel (TLD) Nodos intermedios (de cualquier color): Dominios: Todos tienen una etiqueta, excepto la raíz. Tienen un grupo de servidores asociados imse titan dte www eii www www Hojas (en cualquier nivel): Se suele corresponder con el nombre (hostname) de un ordenador. Se trata de una estructura jerárquica, en forma de árbol, la raíz de este árbol se denomina dominio raíz (root domain). Los dominios de primer nivel (Top Level Domain) son de dos tipos: gtld (Generic Top-Level Domain): Son los que no especifican ninguna información geográfica. Los hay de uso libre:.com,.net,.org y de uso restringido (.edu: Univ. US,.gov: Gobierno US,.mil: Ejercito US). Otros (sponsored TLD o stld):.cat,.info,.name,.pro,.xxx. cctld (Country Code Top-Level Domain): Dominios geográficos en los que se indica la procedencia del dominio..es para España,.uk para Reino Unido,.eu para Europa,.us para Estados Unidos (si no usan gtld), etc. Su uso queda determinado por cada país. IANA es la que da de alta un cctld en la estructura DNS (siempre que exista en el ISO3166). Y el dominio.arpa que se verá después. Los dominios se leen desde las hojas a la raíz: FQDN vs dominio relativo. Ejemplo de FQDN:

6 DNS. Estructura burocrática Para que un nombre de dominio exista en Internet, debe estar enganchado a la estructura de DNS. Internet Assigned Numbers Authority (IANA) es responsable, entre otras cosas (ej: direccionamiento IP), de la coordinación global de los servidores raíz. IANA mantiene la raíz, creando y destruyendo los TLD. No gestiona los TLD dado que cede (delega) la gestión a un com. es org Red.ES ( Registry: Mantiene las bases de datos de los TLD, hay uno para.org, otro para.net, para.es, etc. En los gtld, IANA concede esa gestión por un periodo de tiempo limitado (varios años). En los cctld es distinto dado que se suele ceder la gestión al propio país. Solo hay uno por dominio. Verisign ( Public Interest Registry ( Los registry no suministran, necesariamente, servicios a usuarios finales. Los registry (especialmente en el caso de cctld) definen las políticas de uso del dominio (ej: personas o entidades con vínculos con España). Registrar (registrador): Son empresas que actúan como intermediarios entre el usuario final (registrant) y el registry. Venden el dominio al usuario final (distintos precios, distintos servicios añadidos). Existen varios por dominio y una empresa puede ser registrar de varios dominios (a veces existe una acreditación). Registrant: Nombre que recibe el propietario (usuario final) del dominio. Paga periódicamente para mantener el dominio vivo. Registrer: a.k.a whois. Es un directorio en el que aparecen los datos del propietario de un dominio. Lo aloja el registry y lo actualiza el registrar a instancias del registrant.

7 DNS delegación Los dominios se delegan a entidades que lo gestionan (que a su vez pueden delegar más). Ejemplo:.es lo gestiona Red.ES, y.us.es lo gestiona la US. Cuando se delega, el padre simplemente indicará a quién preguntar para obtener datos del dominio delegado. Se puede crear un sub-dominio sin delegarlo. Ej: dte.us.es Una zona es el conjunto de datos que gestiona una entidad, no necesariamente se corresponde con el dominio. (La zona.es tiene menos datos que el dominio.es). Una vez establecida la delegación se definen los servidores que darán respuesta a esa zona (ambos tipos con el mismo rigor): Principal (Master): Es el que tiene los mapas originales. Secundario (Slave): Mantiene una copia actualizada del principal.

8 DNS Resolución de nombres Un servidor intentará responder con lo que tenga (mapas propios y caché). Si no sabe algo, debe buscarlo (ej: Preguntar a los servidores raíz, éstos le indican cómo llegar a.es Pregunta a los servidores.es, éstos indicarán cómo llegar a.cnm.es Pregunta a srv cnm.es, éstos indicarán cómo llegar a.imse.cnm.es Pregunta a servidores de.imse.cnm.es por éstos dan la respuesta de sus propios mapas: Tipos de preguntas: recursivas vs iterativas. Mapeo IP a nombre de host: Necesario para control de acceso. Nuevo dominio: in-addr.arpa. Ej: murillo.eii.us.es ( ) aparece en ese mapa como in-addr.arpa

9 DNS Caching y TTL Persigue el objetivo de no sobrecargar a los servidores con preguntas que se acaban de hacer. Si no existiera, por cada consulta fuera de mi zona, tendría que preguntar a la raíz. Con cada pregunta el servidor aprende. ( Aprendo la dirección de servidor web de la Escuela pero, Además aprendo cómo llegar a us.es (sin pasar por.es ni. ) y Cómo llegar a.es (sin pasar por. ). Esta información en cache se considera válida por TTL segundos: Un valor pequeño, sobrecarga nuestro servidor. Un valor grande, el tiempo de posible incoherencia es mayor.

10 DNS Registro SOA imse.cnm.es. IN SOA ns.imse.cnm.es. postmaster.imse.cnm.es. ( ; Serial ; Refresh 3600 ; Retry ; Expire ) ; Minimum SOA: Mantiene información sobre esa zona. Se indica, para el domino, en primer lugar cuál es el servidor principal, en este caso ns.imse.cnm.es e información de contacto (postmaster@imse.cnm.es). Serial: Numero incremental para que los secundarios sepan si deben actualizarse (ej: YYYYMMDDnn, pero puede usarse otro esquema). Refresh: Indica cada cuanto se debe actualizar un secundario. Retry: Indica cada cuanto se reintenta en caso de fallos. Expire: Tiempo máximo sin contactar con el principal (vaciar tablas). Minimum: Ahora: Tiempo de vida de respuestas negativas. Antes: Tiempo de vida por defecto.

11 imse.cnm.es. IN NS imse.cnm.es. IN NS imse.cnm.es. IN NS imse.cnm.es. IN NS imse.cnm.es. IN NS imse.cnm.es. IN NS DNS Registros NS y MX ns.imse.cnm.es. ns2.imse.cnm.es. dns1.cica.es. dns2.cica.es. onix.us.es. ultra.cnm.es. Indican los servidores de nombres del dominio indicado. No hay ningún orden de prelación, todos valen lo mismo. Se deben distribuir geográficamente, en distintas redes. Pueden ser máquinas de otros dominios. imse.cnm.es. IN MX imse.cnm.es. IN MX 100 mx.imse.cnm.es. 200 mxback.imse.cnm.es. Indican los servidores de correo que aceptan dirigido a ese dominio. Se establece un orden de prelación, se debe entregar el correo al servidor que tenga una prioridad menor. No tienen por qué estar todos en el dominio.

12 DNS Registros A, CNAME y PTR ns IN A mx IN A titan IN A Establece la relación nombre de máquina con la IP. Los nombres de la izquierda pueden ser FQDN o relativos, por ejemplo, a la zona. www IN CNAME titan Permite establecer alias. En ausencia de FQDN, se añade el dominio por defecto. El ejemplo indica que es un alias de la dirección titan.imse.cnm.es in-addr.arpa. IN PTR titan.imse.cnm.es in-addr.arpa. IN PTR pcext3.imse.cnm.es in-addr.arpa. IN PTR pcport01.imse.cnm.es. Permiten establecer la relación, dirección IP a Nombre de máquina. Se usa el dominio in-addr.arpa. Este dominio funciona parecido el resto (se delega y tiene entradas NS y SOA).

13 FORMATO DEL MENSAJE DNS-PDU id flags N. of questions N. of answer RR N. of authority RR N. of additional RR Questions (var.) Answers RR (var.) Authority RR (var.) Aditional RR (var.) Id: Es un identificador que pone el cliente y copia el servidor en su respuesta. Flags: QR(1b), Indica si es petición (0) o respuesta(1). OPCODE(4b): Tipo de pregunta (lo pone el cliente). AA(1b): Indica si es autoritativo (1) o no (0). TC(1b): Indica si la respuesta está truncada. RD(1b): Indica si se requiere recursividad Z(3b): Originalmente eran 0. RA(1b): Indica si se ofrece recursividad. RCODE(4b): Código respuesta. NOTA: Posteriormente Z se ha usado. Name (var.) Type (16b) Class (16b) TTL (32b) RDLENGTH (32b) RDATA (var.) Name: Indica, con una codificación especial, en nombre al que se refiere la pregunta o respuesta. Type: Tipo de pregunta o respuesta (NS, MX, A, PTR, etc). Class: Clase, habitualmente usamos una IN. TTL: Tiempo de vida en segundos y en 32bits. RDLENGTH Y RDATA: La longitud y los datos de la respuesta. 13

14 Ejemplo real: Pregunta por al servidor de nombres institucional de la US y la respuesta que ése da. (QR=1) El servidor DNS de la US no es autoritativo para y así debe indicarlo. La pregunta tenía solicitud de recursividad. Este DNS acepta la recursividad (pero sólo porque estoy en RIUS) Esto es una respuesta, pero se replica la pregunta que la provocó (buscar una entrada A para Observar cómo se codifica: (long: 3, www), 06676f6f676c65 (long:6,google), (long: 2, es). La pregunta desencadena 4 respuestas: (1) es un alias (CNAME) de (2) es un CNAME de (3) y (4) tiene dos entradas A distintas. Pos: 0xc Sitios donde se puede encontrar una respuesta autoritativa (en respuesta adicionales, pueden aparecer las IP de estas entradas NS). c00c: Si Name empieza por 11 se trata de un puntero (formato comprimido) a otra ubicación dentro de la PDU de DNS. 14

15 Indica el dominio por defecto. Definición del SOA, es sustituida por $ORIGIN Registros MX, son los servidores de correo de la zona. Entradas A, incluye una entrada localhost, y las de los NS y MX, entre otros. Si el nombre no termina en., se añade el $ORIGIN, DNS Ejemplo: zona imse.cnm.es $ORIGIN imse.cnm.es. $TTL IN SOA ns.imse.cnm.es. postmaster.imse.cnm.es. ( ; Serial ; Refresh 1 dia 7200 ; Retry 2 horas ; Expire 30 dias ) ; Minimum 2 dias (172800) IN NS ns.imse.cnm.es. IN NS ns2.imse.cnm.es. IN NS dns1.cica.es. IN NS dns2.cica.es. IN NS onix.us.es. IN NS ultra.cnm.es. IN MX 100 mx.imse.cnm.es. IN MX 200 mxback.imse.cnm.es. IN A ; localhost entry. Se recomienda tener la entrada localhost.imse.cnm.es ; localhost IN A ; ; ns IN A ns2 IN A mx IN A mxback IN A titan IN A titan IN MX 100 mx.imse.cnm.es. titan IN MX 200 mxback.imse.cnm.es. www IN CNAME titan pop IN CNAME titan imap IN CNAME titan Indica el TTL por defecto para toda la zona Lista de NS de la zona, algunos están fuera del dominio, otro está en el padre. imse.cnm.es, además de un dominio, tiene una entrada A No sólo los dominios, sino que los hosts también pueden tener entradas MX. Estos son los alias de titan

16 DNS Ejemplo: zona in-addr.arpa y raiz $ORIGIN in-addr.arpa. $TTL IN SOA ns.imse.cnm.es. postmaster.imse.cnm.es. ( ; Serial ; Refresh 1 dia 7200 ; Retry 2 horas ; Expire 30 dias ) ; Minimum 2 dias IN NS ns.imse.cnm.es. IN NS ns2.imse.cnm.es. IN NS erik.cica.es. IN NS erika.cica.es. IN NS onix.us.es. IN NS ultra.cnm.es. ; ; 6 IN PTR ns.imse.cnm.es. 8 IN PTR ns2.imse.cnm.es. 5 IN PTR mx.imse.cnm.es. 7 IN PTR mxback.imse.cnm.es. 30 IN PTR titan.imse.cnm.es. Ejemplo de la zona in-addr.arpa. Se define como cualquier otra zona, pero tiene entradas PTR en vez de A, tampoco tiene entradas MX. Es importante no olvidar el. en la parte de la derecha. ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache. <file>" ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC ; under anonymous FTP as ; file /domain/named.root ; on server FTP.INTERNIC.NET ; -OR- RS.INTERNIC.NET ; ; last update: Jan 29, 2004 ; related version of root zone: ; ; ; formerly NS.INTERNIC.NET ; IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET A ; ; formerly NS1.ISI.EDU ; NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET A Zona raiz (named.root) Esta zona indica al servidor DNS, cómo llegar a la raíz. El fichero se debe descargar de internic periódicamente. El TTL es infinito.

17 NSLOOKUP Permite hacer consultas directamente a un servidor DNS. Disponible en Unix y Windows. Órdenes más útiles: set query=[any A SOA NS PTR ] (permite buscar un registro concreto o que nos devuelva todos los disponibles). set [no]recurse (permite establecer o no una consulta recursiva). server [IP FQDN] (permite especificar el servidor al que preguntar). > set query=any > imse.cnm.es. Server: ns.imse.cnm.es Address: imse.cnm.es internet address = imse.cnm.es preference = 100, mail exchanger = mx.imse.cnm.es imse.cnm.es preference = 200, mail exchanger = mxback.imse.cnm.es imse.cnm.es nameserver = ns.imse.cnm.es imse.cnm.es nameserver = ns2.imse.cnm.es imse.cnm.es nameserver = dns1.cica.es imse.cnm.es nameserver = dns2.cica.es imse.cnm.es nameserver = onix.us.es imse.cnm.es nameserver = ultra.cnm.es imse.cnm.es origin = ns.imse.cnm.es mail addr = postmaster.imse.cnm.es serial = refresh = (1D) retry = 7200 (2H) expire = ( ) minimum ttl = (2D) El formato de salida es algo diferente, pero dice lo mismo. imse.cnm.es nameserver = ns.imse.cnm.es imse.cnm.es nameserver = ns2.imse.cnm.es imse.cnm.es nameserver = dns1.cica.es imse.cnm.es nameserver = dns2.cica.es imse.cnm.es nameserver = onix.us.es imse.cnm.es nameserver = ultra.cnm.es mx.imse.cnm.es internet address = mxback.imse.cnm.es internet address = ns.imse.cnm.es internet address = ns2.imse.cnm.es internet address = dns1.cica.es internet address = dns2.cica.es internet address = onix.us.es internet address = ultra.cnm.es internet address = Herramienta online: /nslookup.php

18 DNS relaciones padre-hijo La delegación de un dominio, no significa independizarse del padre. Es necesaria una coordinación entre ambos (antes y después). Ejemplo. Delegar el dominio infor.imse.cnm.es infor.imse.cnm.es. IN NS serv1.infor.imse.cnm.es. infor.imse.cnm.es. IN NS serv2.infor.imse.cnm.es. Paso 1: Crear el dominio: Se crean las entradas NS que indiquen los NS del nuevo subdominio. Paso 2: Se configura un servidor principal (serv1) y otro secundario (serv2) y se rellenan las tablas para el nuevo dominio y zona. Problema: Cómo llego a infor.imse.cnm.es?, pues preguntando a imse.cnm.es, y cómo sabe imse.cnm.es las IP de los NS de infor?, Tenemos un problema! serv1.infor.imse.cnm.es. IN A serv2.infor.imse.cnm.es. IN A Paso 3: La zona imse.cnm.es, aunque se trate de algo fuera de su gestión debe conocer las entradas A de los NS (glue record), pero sólo si están en el hijo.

19 SMTP Y MIME El correo electrónico es una herramienta muy usada, existen tres partes: RFC 5321: Describe cómo se distribuye un correo electrónico (SMTP=Simple Mail Transfer Protocol). RFC 5322: Define el formato de un correo electrónico simple. RFC 2045 a 2049: Define cómo se envían adjuntos en un correo (MIME=MultiPurpose Internet Mail Extensions). to: alguien@us.es Entrega al buzón del usuario alguien@us.es Cliente de correo (UA) protocolo SMTP Servidor de correo (ISP) protocolo SMTP Servidor de correo (US) El servidor del ISP hace de relay, comprueba que el destinatario no es suyo y localiza al servidor de correo donde está ubicado el buzón del destinatario. Cliente de correo (UA) Protocolo POP o IMAP

20 SMTP DNS y SMTP El servicio SMTP está muy ligado al DNS, es necesario para localizar la parte que está detrás de y saber si tiene entrada MX o sólo entrada A. Si existen entradas MX, son estas las que se prueban. Se empieza por el que tiene un número menor: Si se produce un error permanente (5xx), el mensaje no se puede entregar y se devuelve. Si el error es transitorio (4xx) o se producen t/o con el servidor, se pasa al siguiente MX de la lista. Si se entrega en un MX secundario, éstos se comprometen a entregarlo o bien al buzón del usuario o bien al servidor principal.

21 RFC 5322 formato de un correo Received: from titan.imse.cnm.es (titan [ ]) by mx.imse.cnm.es (8.13.3/ ) with ESMTP id j481vahk for Sun, 8 May :57: (MEST) Received: from zproxy.gmail.com (zproxy.gmail.com [ ]) by titan.imse.cnm.es (8.13.3/8.13.3) with ESMTP id j481vykr005533for <benjumea@imse.cnm.es>; Sun, 8 May :57: (MEST) Received: by zproxy.gmail.com with SMTP id 34so nzf for <benjumea@imse.cnm.es>; Sat, 07 May :57: (PDT) Received: by with SMTP id 5mr943816nzw; Sat, 07 May :57: (PDT) Received: by with HTTP; Sat, 7 May :57: (PDT) Message-ID: <80617e ce8bc@mail.gmail.com> Date: Sun, 8 May :57: From: J <xxxxxxxxxxx@gmail.com> To: benjumea@imse.cnm.es Subject: Saludos Mime-Version: 1.0 Content-Type: text/plain; charset=iso Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mx.imse.cnm.es id j481vahk El formato genérico de cualquier correo electrónico comienza con una sección de cabeceras (en las que figura el From, el To, la fecha, el asunto), y otros datos identificativos. Lo siguiente es una línea en blanco OBLIGATORIA. Finalmente el cuerpo del mensaje que contiene texto y, si se usa MIME, también ficheros adjuntos. Un saludo desde Gmail. Bye. LÍNEA EN BLANCO OBLIGATORIA! Este es el formato del correo, pero cómo se envía?: RFC5321

22 SMTP Comando HELO/EHLO Serv> 220 titan.imse.cnm.es ESMTP Sendmail /8.13.3; Sun, 8 May :16: (MEST) Client> HELO mx.imse.cnm.es Serv> 250 titan.imse.cnm.es Hello mx [ ], pleased to meet you HELO/EHLO (de Hello) es el primer comando que se debe poner, con éste el cliente del correo le indica al servidor cuál es su dominio. En principio debería indicarse el nombre real del cliente con este comando, pero en la práctica se puede poner cualquier cosa. En términos generales, los códigos que me va a devolver el servidor ante cualquier comando (no sólo EHLO) son (se ponen los más importantes): 2xx: Indica que se ha aceptado el comando anterior. 3xx: Indica que se ha aceptado parcialmente el comando anterior. 4xx: Indica que se ha producido un error temporal que impide aceptar ese comando, pero que si se intenta más tarde el mismo comando, puede que no falle. Por ejemplo un disco lleno. 5xx: Indica que se ha producido un error permanente y que si se repitiera de nuevo la misma secuencia de comandos, se volverá a producir el mismo error.

23 SMTP comando MAIL FROM Client> MAIL FROM: Serv> Sender ok Se indica el remitente del mensaje, al que se le va a devolver el mensaje si su entrega falla. A veces se requiere que el dominio (detrás de ) exista, en este caso, si no existe se devuelve un código de error (temporal o permanente). Casi nunca se comprueba que exista el usuario remitente. OJO!, una cosa es la dirección que aparece aquí y otra la que aparece en las cabeceras del (y por lo tanto la que aparece en el cliente de correo UA-). NO TIENEN POR QUÉ COINCIDIR y además, no se suele forzar a que coincidan. Qué sucede con las listas de correo?

24 SMTP Comando RCPT TO Client> RCPT TO: Serv> Recipient ok Indica el destinatario (sea local o remoto) al que se le debe entregar ese correo. No tiene por que coincidir con los campos To o CC del correo. Qué sucede con el Bcc? No tiene por qué aceptarse todo, por ejemplo puedo rechazar la entrega si el cliente no se ha autentificado correctamente: Client> RCPT TO: <benjumea@dte.us.es> Serv> <benjumea@dte.us.es>... Relaying denied. Proper authentication required. En este caso el destinatario se ha rechazado por tratarse de un destino remoto sin que el cliente de correo se haya autentificado. Es un error permanente indicando que si lo vuelvo a intentar de la misma manera, se rechazará igualmente.

25 SMTP Comando DATA y QUIT Client> Serv> DATA 354 Enter mail, end with "." on a line by itself Es el comando que permite comenzar a escribir el . La respuesta que se devuelve es 3xx significando que está esperando a ver el mensaje y determinar si se acepta. El correo se escribirá en ASCII de 7 bits ( a no ser que soporte 8 bits, caso que no vamos a ver), se indica el fin del correo con. en una única línea. Si se quiere poner eso en el mensaje, lo que hay que poner es.. Si se acepta, deberá indicarse tras la señal de fin de . Serv>. Client> j481yhg Message accepted for delivery El comando QUIT se debe enviar para solicitar el cierre de la conexión.

26 SMTP Ejemplo de transacción Ambos from coinciden, pero no tiene por qué ser así! Mensaje de correo que se va a entregar. Serv> 220 titan.imse.cnm.es ESMTP Sendmail /8.13.3; Sun, 8 May :41: (MEST) Client> HELO mx Serv> 250 titan.imse.cnm.es Hello mx [ ], pleased to meet you Client> MAIL FROM: <benjumea@imse.cnm.es> Serv> <benjumea@imse.cnm.es>... Sender ok Client> RCPT TO: <benjumea@dte.us.es> Serv> <benjumea@dte.us.es>... Recipient ok Client> DATA Serv> 354 Enter mail, end with "." on a line by itself Client> From: Jaime Benjumea -IMSE- <benjumea@imse.cnm.es> Client> To: Jaime Benjumea -DTE- <benjumea@dte.us.es> Client> Subject: Hola Jaime. Client> Client> Esto es una prueba de envio de correo simple. Client>. Serv> j481f2rz Message accepted for delivery Client> QUIT Serv> titan.imse.cnm.es closing connection 250 nos indica que se ha aceptado el mensaje sin error, este servidor nos garantiza que hará todo lo posible para que ese correo llegue a su destino. Pero si eso me lo dice un servidor secundario, puede encontrase luego que no lo puede entregar definitivamente (máquina caída, usuario desconocido), en ese caso DEBE informar al remitente (al que se pusiera en el MAIL FROM, no al del From de las cabeceras del correo).

27 SMTP cabeceras Received Las cabeceras Received se añaden en cada salto, se deben leer desde el final al principio (se insertan como una LIFO). Sólo nos podemos fiar de las que ponemos nosotros. En este ejemplo: Indica que se ha recibido a través de un sistema web (1) Received: from titan.imse.cnm.es (titan [ ]) by mx.imse.cnm.es (8.13.3/ ) with ESMTP id j481vahk for <benjumea@imse.cnm.es>; Sun, 8 May :57: (MEST) Received: from zproxy.gmail.com (zproxy.gmail.com [ ]) by titan.imse.cnm.es (8.13.3/8.13.3) with ESMTP id j481vykr for <benjumea@imse.cnm.es>; Sun, 8 May :57: (MEST) Received: by zproxy.gmail.com with SMTP id 34so nzf for <benjumea@imse.cnm.es>; Sat, 07 May :57: (PDT) Received: by with SMTP id 5mr943816nzw; Sat, 07 May :57: (PDT) Received: by with HTTP; Sat, 7 May :57: (PDT) Message-ID: <80617e ce8bc@mail.gmail.com> Date: Sun, 8 May :57: From: J <xxxxxxxxxxx@gmail.com> To: benjumea@imse.cnm.es Subject: Saludos Mime-Version: 1.0 Content-Type: text/plain; charset=iso Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mx.imse.cnm.es id j481vahk **** CUERPO DEL MENSAJE **** El correo pasa por estafetas internas de gmail (2,3). El correo lo recibe la estafeta principal de esa zona, la IP origen es (4) El paso (5) es interno en la red destino (antivirus). [De todas las cabeceras, sólo 4 y 5 son fiables 100%] Cabeceras que habitualmente muestra un cliente de correo (UA) Visualizar mensaje (mozilla): Ctrl-U

28 SMTP Regla de Oro: Sólo nos podemos fiar de las cabeceras que hayan puesto nuestras estafetas, el resto pueden ser falsas. fiabilidad de las cabeceras Cabeceras de nuestro servidor, nos podemos fiar. OJO!, esto es lo que se ha enviado como parámetro de HELO/EHLO, no tiene por qué ser verdad. La 2ª cabecera Received indica que la IP origen es de TDE, institución que no tiene nada que ver con la US. Por lo tanto, es muy probable que estas cabeceras sean falsas: La dos cabeceras received son inventadas, el propio atacante las ha generado para hacernos creer que el origen es murillo. Message-id, también es falso. El From es inventado, no existe tal dirección. Received: from titan.imse.cnm.es (titan [ ]) by mx.imse.cnm.es (8.13.3/ ) with ESMTP id j48gkcrh for Sun, 8 May :46: (MEST) Received: from us.es (2.Red pooles.rima-tde.net [ ]) by titan.imse.cnm.es (8.13.3/8.13.3) with SMTP id j48gftc for <benjumea@imse.cnm.es>; Sun, 8 May :41: (MEST) Received: from murillo.eii.us.es (murillo.eii.us.es [ ]) by us.es with SMTP; 8 May :27: Received: from localhost (localhost [ ]) by murillo with ESMTP; 8 May :27: Date: Sun, 8 May :31: (MEST) Message-Id: < j48GVIq @murillo.eii.us.es> From: Spammer <spammer@us.es> To: Jaime Benjumea <benjumea@imse.cnm.es> Subject: Publicidad. Esto es pura y simplemente publicidad. Un saludo. Este es el dato real de la IP que se ha conectado. Ejemplo: Falsificación de cabeceras para confundir sobre el origen de un correo. (Una interpretación incorrecta de estas cabeceras podrían hacer suponer que el origen del correo es murillo.eii.us.es) CONCLUSIÓN: El se ha generado inyectando el correo directamente en la estafeta principal del dominio imse.cnm.es. El origen es una IP de TDE:

29 MIME Introducción Un correo electrónico es un conjunto de cabeceras, una línea en blanco y el cuerpo del mensaje. El RFC5322 establecía que el correo además de lo anterior, debía transmitirse en ASCII de 7-bits y una longitud máxima de 1000 caracteres (998 si quitamos \r\n). Los RFC 2045 a 2049 (aunque algunos de ellos se han actualizado) sirven para poder transmitir ASCII extendido y ficheros binarios. Se trata de añadir cabeceras adicionales y codificación para gestionar el envío de ficheros adjuntos (binarios o no) y la codificación en caracteres distintas del US-ASCII.

30 MIME Cabeceras relevantes Mime-version: Actualmente 1.0. Content-type: Le indica al cliente de correo (UA) el tipo y subtipo del mensaje o trozo de mensaje. Por defecto: Content-type: text/plain; charset=us-ascii. Ejemplos: Content-Type: application/x-tar; name="practica1.tar, Content-Type: application/pdf; name="evalbasicourv.pdf. Content-Description: Es un campo de información sobre el o una determinada parte de este. Content-Transfer-Encoding: Indica el tipo de codificación que se ha utilizado en esa (parte) del correo: 7bit: Se refiere al US-ASCII (de 7 bits), no sirve para enviar ni binarios ni caracteres especiales. 8bit y binary: Ligeramente diferentes, permiten el envío de ASCII de 7 bits, y por tanto, caracteres acentuados (p.ej.). Los MTA nuevos lo soportan, posibles problemas con los antiguos. quoted-printable y base64: Los vemos ahora.

31 MIME quoted-printable vs base64 Permiten transferir ASCII de 8 bits y ficheros binarios sobre un de 7bits. Quoted-printable: Se utiliza si la mayor parte del texto se puede codificar con ASCII de 7 bits (facilita el análisis manual): Los caracteres del 29 al 127 (imprimibles de 7bits), van tal cual. El resto: Se representan con =XX donde XX es el número hexadecimal de ese carácter, Ejemplo: Transmisión de una eñe. será Transmisi=F3n de una e=f1e. Base64: Se usa para codificar un fichero cualquiera: El fichero binario se divide en bloques de 24bits(3x8bits). Cada bloque se codifica con una letra (tomando los bits de 6 en 6) según la tabla adjunta. Se transmiten esas letras, formando líneas de 72 caracteres. Si los bits no son múltiplo de 24, se añaden bits a cero hasta formar un numero entero de grupos de 6-bits y se añaden unos o dos = como relleno. Imagen: TCP/IP Illustrated, Volume 1: The Protocols, By W. Richard Stevens

32 MIME / Adjuntos Se trata de un mensaje con un fichero adjunto (normas.pdf). Indica que el contenido tiene varias partes (tipo multipart): Mixed: Indica que el correo tiene varias partes en un orden determinado. Alternative: Indica que el contenido de cada parte es el mismo, pero con formato distinto (ej. HTML vs TEXTO) Información de esta parte del . Un fichero tipo PDF, codificado en base 64 y con nombre normas.pdf Fichero (truncado) codificado en Base64, nótese el padding del final. MIME-Version: 1.0 Date: Sat, 6 Apr :20: Message-ID: <CAKg2sRfn_ErCpOtB1r2amrQniA@mail.gmail.com> Subject: HOLA From: Jaime Benjumea <XXXXXXX@gmail.com> To: Jaime Benjumea <jaimebm@us.es> Content-Type: multipart/mixed; boundary=20cf b589f04d9b6f cf b589f04d9b6f069 Content-Type: text/plain; charset=iso Este tiene un adjunto. -- Jaime Benjumea --20cf b589f04d9b6f069 Content-Type: application/pdf; name="normas.pdf" Content-Disposition: attachment; filename="normas.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjQgMCBvYmoNPDwgDS9MJpemVkIDEgDS9PIDcgDS9IIFsgMTM0 MiAyMTUgXSANL0wgMzU3NDU0IA0vRSAzNTU1ODIgDS9OIDEM1NzI1NyANPj4gDWVuZG9i [ ] MzYyOD48MDhmYjk4NGFmZGE5Y2UzOTg3ZGU2ZmYwOWJlOTJmZDI+XQ0GDQ== --20cf b589f04d9b6f069-- Boundary: Indica la cadena de separación entre las distintas partes. OJO a las coincidencias dentro del mensaje. Este es el cuerpo del Texto plano y ASCII de 7bits. Aquí comienza otra parte. El separador es la cadena boundary con -- al principio. Estos dos - indican que es la última parte.

33 MIME / Ejemplo 2 Se trata de un correo electrónico enviado como HTML y texto y que además tiene un documento adjunto. Indica que el correo se compone de varias partes en orden y que tienen contenido diferente. Content-type anidado: la parte 1ª del mutipart anterior es subtipo alternative, es el mismo contenido pero con formato diferente. Será el UA el que decida qué contenido se presenta, texto o HTML (pero sólo uno de ellos), el adjunto también debe mostrarse. Siguiente contenido alternative. Fin del contenido alternative. Siguiente contenido mixed Fin del contenido mixed. MIME-Version: 1.0 Date: Sun, 7 Apr :54: Message-ID: <CAKg2bSG-nAQBkQa7vgpepRG1xpJo4N5dRxDg@mail.gmail.com> Subject: Texto, html y adjunto From: Jaime Benjumea <benjumea@dte.us.es> To: Jaime Benjumea <jaimebm@us.es> Content-Type: multipart/mixed; boundary=20cf3079bd622775e504d9b9eeab --20cf3079bd622775e504d9b9eeab Content-Type: multipart/alternative; boundary=20cf3079bd622775db04d9b9eea9 --20cf3079bd622775db04d9b9eea9 Content-Type: text/plain; charset=iso Este mensaje se manda en texto plano y HTML. --20cf3079bd622775db04d9b9eea9 Content-Type: text/html; charset=iso Este mensaje se manda en texto plano y HTML.<br> --20cf3079bd622775db04d9b9eea cf3079bd622775e504d9b9eeab Content-Type: application/vnd.openxmlformats-officedocument.presentation [ ]; name="tema_4_correo_electronico.pptx" Content-Disposition: attachment; filename="tema_4_correo_electronico.pptx" Content-Transfer-Encoding: base64 [ ] --20cf3079bd622775e504d9b9eeab-- Separador del contenido mixed. Separador del contenido alternative Estos son los dos contenidos alternativos. Texto y HTML, pero ambos dicen lo mismo.

34 MIME Caracteres extendidos en cabeceras Las cabeceras, a no ser que el MTA soporte 8bits, siguen transmitiéndose con 7bits. Qué ocurre con los caracteres ASCII extendidos en las cabeceras? Puede ser necesario que en el asunto, el From o el To aparezcan estos caracteres. SOLUCIÓN. Se codifican, si es necesario, determinadas partes de las cabeceras con este esquema: encoded-word = "=?" charset "?" encoding "?" encoded-text "?= charset es el juego de caracteres, encoding: q=quoted-printable, b=base64. Los espacios se sustituyen por _, los _ por su codificación. Restricciones con otros. Subject: Elaboración de guías ECTS Subject: =?iso ?q?elaboraci=f3n_de_gu=edas_ects?= Subject: Abierto el plazo de petición de libros Subject: Abierto el plazo de =?ISO ?Q?petici=F3n_de_libros?= Subject: Este_es_un_texto_extraño Subject: =?ISO ?Q?Este=5Fes=5Fun=5Ftexto=5Fextra=F1o?= Subject: No_necesariamente_se_codifica. Subject: No_necesariamente_se_codifica.

35 Protocolos de acceso a correo Cliente de correo (UA) Servidor de correo (US) Protocolo POP o IMAP SMTP: Solo permite distribuir el correo, pero no leerlo. Métodos para acceder al correo electrónico: Directamente al buzón (como fichero local) a Requiere acceso con shell al servidor. Mediante un protocolo específico para acceso al correo: POP: Post Office Protocol (RFC 1939): Simple a modelo descargar y borrar. IMAP: Internet Mail Access Protocol (RFC 1730): Ofrece más características que POP, aunque es más complejo Permite la manipulación de mensajes que están almacenados en el servidor. WebMail: Gmail, Outlook.com, Yahoo! Mail, etc.

36 Protocolo POP3 Es un protocolo simple, sólo permite un buzón (Inbox) en el servidor. El servidor asigna un identificador único a cada mensaje (opcional). Está pensado para funcionar en modo descargar y borrar : El cliente de correo se descarga el correo y luego lo borra del servidor. Implica que, una vez descargado, ese correo solo está disponible en el cliente en el que se descargó. No obstante, se puede descargar un mensaje sin borrarlo: Permite que el correo siga disponible si se accede desde otro cliente (ej. casa y trabajo). Todo el correo se almacena en un único buzón a problemas de rendimiento. No se guarda (en el servidor) información sobre el estado de los mensajes. Usa el puerto 110 (sin SSL) o el 995 (con SSL).

37 Protocolo POP3 Fase de autorización: USER / PASS. -ERR en caso de error. Fase de transacción: STAT: Indica el número de s y tamaño. LIST: Numera los mensajes (sesión) y tamaño. RETR: Descarga ese correo. DELE: Marca el correo para borrar. NOOP: No hacer nada. Otras órdenes (opcionales): UIDL: Muestra identificación persistente. TOP: Devuelve solo cabeceras. Fase de actualización (UPDATE): Se entra al enviar el cliente QUIT. Se borran los mensajes marcados. Puede dar error (pero se sale). S: +OK POP3 perditon ready on e_entrada b8c C: USER jaimebm S: +OK USER jaimebm set, mate C: PASS MiClave27 S: +OK You are so in C: STAT S: +OK C: LIST S: +OK 2 messages: S: S: S:. C: UIDL S: +OK S: 1 c824c610868a50511e5e0000da53751c S: 2 a c5051bc660000da53751c S:. C: RETR 2 S: +OK 1946 octets S: [ ] S:. C: DELE 2 S: +OK Marked to be deleted. C: QUIT S: +OK Logging out. NOTA: El UA es Thunderbird.

38 Protocolo IMAP Permite crear varios buzones o carpetas (mailbox) Está diseñado para que los mensajes permanezcan en el servidor: Permite el acceso desde varios clientes. Guarda el estado de los mensajes (identificador, banderas de estado). Usa el puerto 143

39 Características IMAP Existe un buzón principal: INBOX. Permite crear buzones (algo parecido a un sistema de ficheros). Los correos se guardan en esos buzones. Cada correo puede tener un conjunto de banderas asignadas. El servidor asigna a cada correo en un buzón un identificador persistente (o indica que ha cambiado). Permite suscribirse a determinados buzones. Permite recuperar solo una parte de un correo. Se pueden copiar correos entre buzones. Existe un mecanismo para informar al cliente de cambios en el buzón (p.ej. Un nuevo correo).

40 Interacción cliente-servidor El cliente envía órdenes precedidas por una etiqueta (ej: 7 select "INBOX ). El servidor: Responde con esa etiqueta + estado (OK/NO/BAD). Si existe información adicional, se responde como información no etiquetada (etiqueta=*). A veces (IDLE) el cliente puede quedar a la espera de una respuesta asíncrona del servidor (ej: nuevo mensaje). Existen distintos estados en cada sesión: No autenticado. Autenticado. Seleccionado. Cierre de sesión.

41 Banderas IMAP Se guardan en cada mensaje y permiten señalar si se ha marcado para borrar, si es nuevo, se ha leído Forman parte de la especificación del protocolo: \Seen (Mensaje ha sido leído). \Answered (Mensaje ha sido respondido). \Flagged (Mensaje está marcado como urgente o especial). \Deleted (Mensaje marcado para borrado) \Draft (El mensaje no se ha terminado de componer (marcado como borrador)) \Recent (El mensaje acaba de llegar, o ha llegado antes de iniciar la sesión)

42 Sesión IMAP (1) S: OK [CAPABILITY IMAP4 IMAP4REV1 STARTTLS] perdition ready on e_entrada1 0002a2b2 C: 2 login "jaimebm" "MiClave27" S: * CAPABILITY IMAP4rev1 IDLE [ ] S: 2 OK You are so in C: 5 lsub "" "*" S: * LSUB () "/" "Archivador" S: * LSUB () "/" "Drafts" S: * LSUB () "/" "SPAM" S: * LSUB () "/" "Sent" S: * LSUB () "/" "Trash" S: * LSUB () "/" "INBOX" S: 5 OK Lsub completed. C: 7 select "INBOX" S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded) S: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded \*)] Flags permitted. S: * 1 EXISTS S: * 0 RECENT S: * OK [UIDVALIDITY ] UIDs valid S: * OK [UIDNEXT 536] Predicted next UID S: 7 OK [READ-WRITE] Select completed.

43 C: 9 UID fetch 536:* (FLAGS) S: * 1 FETCH (UID 535 FLAGS (\Seen)) S: 9 OK Fetch completed. C: 10 IDLE S: + idling [ Tic-Tac-Tic-Tac-Tic-Tac] S: * OK Still here [ Tic-Tac-Tic-Tac-Tic-Tac] S: * 2 EXISTS S: * 1 RECENT C: DONE S: 10 OK Idle completed. 13 UID fetch 536:* (FLAGS) * 2 FETCH (UID 536 FLAGS (\Recent)) 13 OK Fetch completed. Sesión IMAP (2) UID FETCH: Permite obtener determinados datos sobre determinados mensajes (en este caso, las banderas de los mensajes con UID >=536) IDLE: Es una extensión. Permite que el cliente permanezca a la espera de actualizaciones del buzón.

44 Sesión IMAP (3) C: 14 UID fetch 536 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type)]) S: * 2 FETCH (UID 536 RFC822.SIZE 1946 FLAGS (\Recent) BODY[HEADER.FIELDS (FROM TO CC BCC SUBJECT DATE MESSAGE-ID PRIORITY X-PRIORITY REFERENCES NEWSGROUPS IN-REPLY-TO CONTENT-TYPE)] {226} Message-ID: <51508C09.6@dte.us.es> Date: Mon, 25 Mar :40: From: Jaime Benjumea <benjumea@dte.us.es> To: jaimebm@us.es Subject: Este es cortito Content-Type: text/plain; charset=iso ; format=flowed ) S: 14 OK Fetch completed. UID Fetch también se puede usar para recuperar determinadas partes de un correo. Por ejemplo, determinadas cabeceras. También permite obtener datos del correo: las banderas activas, el tamaño, el identificador.

45 Sesión IMAP (y 4) C: 23 UID fetch 536 (UID BODY.PEEK[HEADER.FIELDS (Content-Type Content-Transfer-Encoding)] BODY.PEEK[TEXT]<0.2048>) S: * 2 FETCH (UID 536 BODY[HEADER.FIELDS (CONTENT-TYPE CONTENT-TRANSFER- ENCODING)] {96} Content-Type: text/plain; charset=iso ; format=flowed Content-Transfer-Encoding: 7bit BODY[TEXT]<0> {65} Este es un mensaje que ocupa muy poco. -- Jaime Benjumea ) S: 23 OK Fetch completed. C: 27 UID fetch 537:* (FLAGS) S: * 2 FETCH (UID 536 FLAGS (\Recent)) S: 27 OK Fetch completed. 32 logout * BYE Logging out 32 OK Logout completed.

46 Otras órdenes en IMAP CREATE /DELETE/RENAME. SUSCRIBE/UNSUSCRIBE. LIST. APPEND. SEARCH. STORE COPY EXPUNGE.

47 ANEXO 47

48 HTTP. Introducción Definido en RFC1945 (1.0) y en RFC2616 (1.1), HTTP (Hypertext Transfer Protocol) es el protocolo de nivel de aplicación que transporta las páginas web. Se implementa mediante una estructura típica de cliente-servidor. Visualización mediante navegador web (Mozilla, Iexplorer, Opera, etc): Muestra las páginas (OJO: HTML!=HTTP). Interpreta el contenido de las páginas y realiza peticiones adicionales Petición1 HTTP Respuesta 1 HTTP Petición2 HTTP Respuesta 2 HTTP Servidor web (Apache, IIS, etc): Alberga las páginas (estáticas y dinámicas). Responde a las peticiones del cliente HTTP es stateless, la petición 2 no guarda datos de la anterior. La versión 1.0 no soportaba conexiones persistentes a pérdida de eficiencia al tener que pedir cada item (p.ej. un gif) abriendo una nueva conexión TCP. La versión 1.1 añade el soporte de conexiones persistentes y más métodos (será la versión que estudiemos). Usa el puerto 80 (en su versión insegura) y el 443 (si se utiliza SSL) Formato URL-HTTP Protocolo de acceso. Otros: ftp, https Nombre del servidor Puerto (opcional) Path de acceso al objeto (html, gif, etc) Parámetros enviados al objeto (script) PROXY EXPLÍCITO PROXY TRANSPARENTE El acceso directo (80/tcp) se prohíbe. Cliente Proxy Servidor El cliente conoce expresamente su existencia. El cliente nunca accede directamente al servidor web, siempre lo hace el proxy (resolución DNS en proxy). El proxy puede almacenar temporalmente (caché compartido) las páginas y ofrecerlas posteriormente sin tener que acceder al servidor web. Cliente Las salidas a 80/tcp se redireccionan al proxy Proxy El cliente ni conoce su existencia ni puede evitar su uso. Servidor El cliente nunca accede directamente al servidor web, siempre lo hace el proxy (pero la resolución DNS también es necesaria en el cliente). El resto de funciones son similares al proxy explícito. 48

49 Cabeceras HTTP. Ejemplo de funcionamiento GET / HTTP/1.1 Host: User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-us; rv:1.7.3) Gecko/ Accept: text/xml,application/xml,application/xhtml+xml,text/html Accept-Encoding: gzip,deflate Accept-Charset: ISO ,utf-8 Keep-Alive: 300 Connection: keep-alive Indica el path solicitado. Petición HTTP (página principal) Es un gif, se descargará en una petición independiente: GET /art/logodte.gif HTTP/ OK Date: Wed, 31 Aug :51:59 GMT Server: Apache/ (Unix) PHP/ mod_ssl/ OpenSSL/0.9.7g Last-Modified: Thu, 23 Sep :52:40 GM ETag: "f257-1f b908 Accept-Ranges: bytes Content-Length: 7987 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html <HTML> (contenido de la página web) Respuesta HTTP (página principal) Las peticiones y las repuestas llevarán unas cabeceras y, opcionalmente, un contenido (datos). Primero se descarga la página, y luego cada gif u objeto que haya en ella. Cada petición es independiente; si se usa HTTP/1.0 se hace en conexiones TCP distintas, si se usa HTTP/1.1 se puede hacer varias en una misma conexión.

50 HTTP. Peticiones y respuestas PETICIÓN: La genera el cliente web (navegador) y la interpreta el servidor o el proxy OJO: Retorno de carro y cambio de línea (\r\n) Método: Indica la forma en la que se hace una petición, los más interesantes son: GET: Es el mecanismo habitual para descargarse una página o un GIF, o un script que genera dinámicamente la página. POST: Se utiliza para enviar datos al servidor, por ejemplo un adjunto a través de webmail (será procesado por algún tipo de script en el servidor). HEAD: Tiene las mismas funciones que GET, pero no se descargan datos, sólo las cabeceras. TRACE: Funciona como diagnóstico, el servidor devuelve las cabeceras recibidas. URI: Objeto que nos vamos a descargar (path absoluto). Version-HTTP: En la práctica, dos posibilidades. HTTP/1.0 ó HTTP/1.1 Método <SP> URI <SP> Version-HTTP <CRLF> Figura: Petición HTTP Cabecera_1 <CRLF> Cabecera_N<CRLF> <CRLF> Datos En una petición también puede haber datos: upload de un fichero RESPUESTA: La genera el servidor web y la interpreta el proxy o el navegador Version HTTP: Igual que antes. Code: Código de error, en formato interpretable por una máquina: 1xx: Informativo, el proceso continúa. 2xx: Éxito, se ha aceptado la petición. 3xx: Redirección. Falta algo para poder terminar la petición. 4xx: Error del cliente. La petición parece ser no válida (incluye errores 404, no encontrado; 403: Prohibido. 5xx: Error del servidor. La petición parece válida pero no puede atenderse (incluye errores 500, error interno del servidor). Reason: Es un mensaje en formato ASCII que indica una explicación del error, supuestamente dirigido a personas. No tiene por qué estar escrito en inglés. Version-HTTP <SP> Code <SP> Reason <CRLF> Cabecera_1 <CRLF> Cabecera_N<CRLF> <CRLF> Datos Figura: Respuesta HTTP

51 HTTP. Petición GET Las peticiones GET permiten al navegador solicitar un objeto (HTML, GIF, páginas dinámicas, CGI ) PETICIÓN Cliente Web (Mozilla) GET /gifs/logoimse1.gif HTTP/1.1 Host: Indica el servidor, es un campo obligatorio. Uso: Servidores virtuales User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-us; rv:1.7.3) Gecko/ Accept: image/png,*/*;q=0.5 Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: Pragma: no-cache Cache-Control: no-cache Se indica el path absoluto de la petición. Además la versión de HTTP soportada Navegador Qué tipo MIME acepto?, image/png (q=1) es el preferido pero si no, vale el resto (q=0.5) Prefiero codificación ISO , pero acepto otras. Hace referencia a solicitudes de conexión persistentes en protocolos 1.0; HTTP/1.1 por defecto establece las conexiones como persistentes a no ser que se indique Connection: close Esta cabecera indica de dónde se ha obtenido la referencia al objeto que se solicita. Hace referencia al comportamiento de las caché. La cabecera Pragma está especificada para compatibilidad con versiones antiguas, la cabecera cache-control es la específica para 1.1 Esto se transmitirá en varios segmentos TCP, pero eso es transparente para la aplicación. HTTP/ OK Date: Wed, 31 Aug :51:59 GMT Fecha, la pone el servidor, siempre en GMT. Server: Apache/ (Unix) PHP/ mod_ssl/ OpenSSL/0.9.7g Last-Modified: Fri, 11 Apr :52:18 GMT ETag: "1080b dfbc2 Accept-Ranges: bytes Content-Length: Keep-Alive: timeout=15, max=98 Connection: Keep-Alive Content-Type: image/gif Tipo de objeto (MIME), en este caso es un gif. Respuesta, el código 2xx indica que tuvo éxito, el mensaje OK es sólo para tratamiento manual. Datos del servidor Última modificación, permite decidir si debo descargarlo otra vez. Es un identificador único, permite saber si un objeto se ha modificado (cabeceras If-*) Si el servidor permite una descarga parcial (función resume), se indica así. Longitud en bytes (necesario para conex. no persistente), problemas en páginas dinámicas. Servidor Web (Apache y otros módulos) GIF89a..U... RESPUESTA Aquí comienza el fichero gif, codificado directamente en binario. 51

52 HTTP. Peticiones HEAD y TRACE $ telnet 80 HEAD / HTTP/1.1 Host: Línea en blanco Esta petición no descargará la página sólo las cabeceras que se generarían. Petición HEAD Respuesta Respuesta a la petición ejecutada con éxito. La cabeceras contienen datos útiles para el navegador o el proxy (en este caso referentes a no guardar la pagina en cache). Aquí iría la página web, si la petición hubiera sido GET HTTP/ OK Date: Thu, 01 Sep :57:39 GMT Server: Apache X-Powered-By: PHP/4.3.2 Set-Cookie: PHPSESSID=aed768bc a4e34d0bc; path=/ Expires: Thu, 19 Nov :52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Type: text/html; charset=iso Línea en blanco Petición TRACE bash-2.03$ telnet 80 TRACE * HTTP/1.1 Host: X-MiCabecera: Test loopback. Línea en blanco Respuesta Esta cabecera me la he inventado, HTTP permite hacer eso. HTTP/ OK Date: Thu, 01 Sep :54:38 GMT Server: Apache Transfer-Encoding: chunked Content-Type: message/http Línea en blanco TRACE * HTTP/1.1 Host: X-MiCabecera: Test loopback. Ahora las cabeceras son más cortas. Esto es un eco de lo que ha recibido el servidor web. Son datos (una copia de la cabecera recibida). bash-2.03$ telnet 80 TRACE / HTTP/1.1 Host: X-MiCabecera: Test loopback Respuesta HTTP/ OK Transfer-Encoding: chunked Date: Thu, 01 Sep :07:37 GMT Content-Type: message/http Server: Sun-ONE-Web-Server/6.1 Como accedo a otro servidor, las cabeceras son otras. Aquí hay cabeceras que no hemos puesto, eso significa que existe un proxy (transparente) entre nosotros y TRACE / HTTP/1.1 Host: Connection: keep-alive X-micabecera: Test loopback X-forwarded-for: Esta cabecera el indica al servidor que la petición realmente viene de (dado que quien finalmente ha accedido a 52 fue un proxy).