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)
DNS. Introducción
¿Página Web de
la Universidad
de Sevilla?
• Suponiendo que usamos el protocolo
IP, la respuesta correcta sería:
150.214.9.142
• 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.
¡www.us.es!
Sistema DNS 150.214.9.142
DNS. Introducción
OPCIÓN 1: Estructura de nombres no jerárquica (centralizada)
Maq1 IP1
Maq2 IP2
Un único punto de
información (servidor)
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).
¿Cómo organizar un sistema que, conociendo un nombre de un servidor, pueda obtener su dirección IP?
Un fichero “de texto” en el que
aparecen todos los nombres y
su correspondiente dirección IP.
DNS. Introducción
OPCIÓN 2: Estructura de nombres jerárquica (distribuida).
Nodo principal (raíz del árbol)
Ordenador final:
Sólo hace consultas
a SU servidor DNS.
Servidor DNS: Contiene SU parte
de la estructura DNS; hace
consultas a otros servidores
Tráfico entre servidores 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.
En el sistema DNS, cada servidor solo mantiene una base de datos con los datos de SU ámbito.
DNS. Estructura
es
.
titan
Profundidad
máxima: 127
niveles
Nodo raíz: root
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
• 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: “www.DTE.US.es.”
org com
cnm us
dte eii imse
www www
www
Hojas (en cualquier nivel): Se suele
corresponder con el nombre
(hostname) de un ordenador.
DNS. Estructura burocrática
es org
.
com
Red.ES
(www.nic.es)
Verisign
(www.verisign.com)
• 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…
• 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.
Public
Interest
Registry
(www.pir.org)
• 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.
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.
DNS
Resolución de nombres • Un servidor intentará responder con lo que tenga
(mapas propios y caché).
• Si no “sabe” algo, debe buscarlo (ej: www.imse.cnm.es): – 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 www.imse.cnm.es, éstos dan la respuesta de sus propios mapas: 150.214.7.30
• 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 (150.214.142.14) aparece en ese mapa como “14.142.214.150.in-addr.arpa”
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. (www.eii.us.es) – 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.
DNS
Registro SOA imse.cnm.es. IN SOA ns.imse.cnm.es. postmaster.imse.cnm.es. (
2005050600 ; Serial
86400 ; Refresh
3600 ; Retry
2592000 ; Expire
172800) ; 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 ([email protected]).
• 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.
DNS
Registros NS y MX imse.cnm.es. IN NS ns.imse.cnm.es.
imse.cnm.es. IN NS ns2.imse.cnm.es.
imse.cnm.es. IN NS dns1.cica.es.
imse.cnm.es. IN NS dns2.cica.es.
imse.cnm.es. IN NS onix.us.es.
imse.cnm.es. IN NS 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 100 mx.imse.cnm.es.
imse.cnm.es. IN MX 200 mxback.imse.cnm.es.
• Indican los servidores de correo que aceptan email 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.
DNS
Registros A, CNAME y PTR
ns IN A 150.214.7.6
mx IN A 150.214.7.5
titan IN A 150.214.7.30
• 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
www.imse.cnm.es es un alias
de la dirección
titan.imse.cnm.es
30.7.214.150.in-addr.arpa. IN PTR titan.imse.cnm.es.
203.7.214.150.in-addr.arpa. IN PTR pcext3.imse.cnm.es.
183.7.214.150.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
flags id
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.
•NOTA: Posteriormente Z se ha usado.
•RA(1b): Indica si se ofrece recursividad.
•RCODE(4b): Código respuesta.
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.
FORMATO DEL MENSAJE DNS-PDU
14
Ejemplo real: Pregunta por www.google.es 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 www.google.es 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 www.google.es).
Observar cómo se codifica: 03777777 (long: 3, www), 06676f6f676c65 (long:6,google), 026573 (long: 2, es).
c00c: Si “Name” empieza por 11… se trata de
un puntero (formato comprimido) a otra
ubicación dentro de la PDU de DNS.
Pos: 0xc
La pregunta www.google.es desencadena 4 respuestas: (1)
www.google.es es un alias (CNAME) de www.google.com. (2)
www.google.com es un CNAME de www.l.google.com. (3) y (4)
www.l.google.com tiene dos entradas A distintas.
Sitios donde se puede encontrar una respuesta autoritativa (en respuesta
adicionales, pueden aparecer las IP de estas entradas NS).
DNS Ejemplo: zona imse.cnm.es
$ORIGIN imse.cnm.es.
$TTL 172800
@ IN SOA ns.imse.cnm.es. postmaster.imse.cnm.es. (
2005050600 ; Serial
86400 ; Refresh 1 dia
7200 ; Retry 2 horas
2592000 ; Expire 30 dias
172800 ) ; 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 150.214.7.5
; localhost entry. Se recomienda tener la entrada localhost.imse.cnm.es
;
localhost IN A 127.0.0.1
;
;
ns IN A 150.214.7.6
ns2 IN A 150.214.7.8
mx IN A 150.214.7.5
mxback IN A 150.214.7.7
titan IN A 150.214.7.30
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
Indica el dominio
por defecto.
Definición del SOA, la
@ es sustituida por
$ORIGIN
Lista de NS de la
zona, algunos
están fuera del
dominio, otro
está en el padre.
Registros MX, son los
servidores de correo
de la zona.
imse.cnm.es,
además de un
dominio, tiene una
entrada A
Entradas A, incluye
una entrada localhost,
y las de los NS y MX,
entre otros.
No sólo los
dominios, sino que
los hosts también
pueden tener
entradas MX.
Estos son los alias
de “titan”
Si el nombre
no termina en
“.”, se añade el
$ORIGIN,
DNS
Ejemplo: zona in-addr.arpa y raiz $ORIGIN 7.214.150.in-addr.arpa.
$TTL 172800
@ IN SOA ns.imse.cnm.es. postmaster.imse.cnm.es. (
2005050500 ; Serial
86400 ; Refresh 1 dia
7200 ; Retry 2 horas
2592000 ; Expire 30 dias
172800 ) ; 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.
; 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: 2004012900
;
;
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201 Ejemplo de la zona 7.214.150.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.
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.
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: 150.214.7.6
imse.cnm.es internet address = 150.214.7.5
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 = 2005051200
refresh = 86400 (1D)
retry = 7200 (2H)
expire = 2592000 (2592000)
minimum ttl = 172800 (2D)
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 = 150.214.7.5
mxback.imse.cnm.es internet address = 150.214.7.7
ns.imse.cnm.es internet address = 150.214.7.6
ns2.imse.cnm.es internet address = 150.214.7.8
dns1.cica.es internet address = 150.214.5.83
dns2.cica.es internet address = 150.214.4.35
onix.us.es internet address = 150.214.186.69
ultra.cnm.es internet address = 158.109.6.3
El formato de salida es algo diferente, pero
dice lo mismo.
Herramienta online:
http://www.kloth.net/services
/nslookup.php
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 150.214.7.200
serv2.infor.imse.cnm.es. IN A 150.214.7.201
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.
• 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).
Cliente de
correo (UA) Servidor de
correo (ISP)
Servidor de
correo (US)
email to: [email protected]
protocolo
SMTP
protocolo
SMTP
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.
Entrega al buzón del usuario
Cliente de
correo (UA)
Protocolo
POP o IMAP
SMTP Y MIME
SMTP
DNS y SMTP
• El servicio SMTP está muy ligado al DNS, es necesario
para localizar la parte que está detrás de la “@”, 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.
RFC 5322
formato de un correo Received: from titan.imse.cnm.es (titan [150.214.7.30])
by mx.imse.cnm.es (8.13.3/8.12.11) with ESMTP id j481vahk005566
for <[email protected]>; Sun, 8 May 2005 03:57:36 +0200 (MEST)
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by
titan.imse.cnm.es (8.13.3/8.13.3) with ESMTP id j481vYkR005533for
<[email protected]>; Sun, 8 May 2005 03:57:35 +0200 (MEST)
Received: by zproxy.gmail.com with SMTP id 34so1353966nzf for
<[email protected]>; Sat, 07 May 2005 18:57:28 -0700 (PDT)
Received: by 10.36.23.5 with SMTP id 5mr943816nzw; Sat, 07 May 2005
18:57:28 -0700 (PDT)
Received: by 10.36.5.6 with HTTP; Sat, 7 May 2005 18:57:28 -0700 (PDT)
Message-ID: <[email protected]>
Date: Sun, 8 May 2005 03:57:28 +0200
From: J <[email protected]>
Subject: Saludos
Mime-Version: 1.0
Content-Type: text/plain;
charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mx.imse.cnm.es id j481vahk005566
Un saludo desde Gmail.
Bye.
• 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.
¡LÍNEA EN BLANCO OBLIGATORIA!
Este es el formato
del correo, ¿pero
cómo se envía?:
RFC5321
SMTP
Comando HELO/EHLO Serv> 220 titan.imse.cnm.es ESMTP Sendmail 8.13.3/8.13.3; Sun, 8 May 2005 03:16:59 +0200 (MEST)
Client> HELO mx.imse.cnm.es
Serv> 250 titan.imse.cnm.es Hello mx [150.214.7.5], 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.
SMTP
comando MAIL FROM
Client> MAIL FROM: <[email protected]>
Serv> 250 2.1.0 <[email protected]>... 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 la “@”) 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 email (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?
SMTP
Comando RCPT TO
Client> RCPT TO: <[email protected]>
Serv> 250 2.1.5 <[email protected]>... 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: <[email protected]>
Serv> 550 5.7.1 <[email protected]>... 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.
SMTP
Comando DATA y QUIT
Client> DATA
Serv> 354 Enter mail, end with "." on a line by itself
Serv> .
Client> 250 2.0.0 j481YHg1027935 Message accepted for delivery
• Es el comando que permite comenzar a escribir el email. 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 email.
El comando QUIT se debe enviar para solicitar el cierre de la
conexión.
Serv> 220 titan.imse.cnm.es ESMTP Sendmail 8.13.3/8.13.3; Sun, 8 May 2005 03:41:02 +0200 (MEST)
Client> HELO mx
Serv> 250 titan.imse.cnm.es Hello mx [150.214.7.5], pleased to meet you
Client> MAIL FROM: <[email protected]>
Serv> 250 2.1.0 <[email protected]>... Sender ok
Client> RCPT TO: <[email protected]>
Serv> 250 2.1.5 <[email protected]>... Recipient ok
Client> DATA
Serv> 354 Enter mail, end with "." on a line by itself
Client> From: Jaime Benjumea -IMSE- <[email protected]>
Client> To: Jaime Benjumea -DTE- <[email protected]>
Client> Subject: Hola Jaime.
Client>
Client> Esto es una prueba de envio de correo simple.
Client> .
Serv> 250 2.0.0 j481f2rZ000107 Message accepted for delivery
Client> QUIT
Serv> 221 2.0.0 titan.imse.cnm.es closing connection
SMTP
Ejemplo de transacción
Mensaje de
correo que se va
a entregar.
Ambos “from”
coinciden,
¡pero no tiene
por qué ser así!
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).
SMTP
cabeceras Received Received: from titan.imse.cnm.es (titan [150.214.7.30])
by mx.imse.cnm.es (8.13.3/8.12.11) with ESMTP id j481vahk005566
for <[email protected]>; Sun, 8 May 2005 03:57:36 +0200 (MEST)
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195])
by titan.imse.cnm.es (8.13.3/8.13.3) with ESMTP id j481vYkR005533
for <[email protected]>; Sun, 8 May 2005 03:57:35 +0200 (MEST)
Received: by zproxy.gmail.com with SMTP id 34so1353966nzf for <[email protected]>;
Sat, 07 May 2005 18:57:28 -0700 (PDT)
Received: by 10.36.23.5 with SMTP id 5mr943816nzw; Sat, 07 May 2005
18:57:28 -0700 (PDT)
Received: by 10.36.5.6 with HTTP; Sat, 7 May 2005 18:57:28 -0700 (PDT)
Message-ID: <[email protected]>
Date: Sun, 8 May 2005 03:57:28 +0200
From: J <[email protected]>
Subject: Saludos
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mx.imse.cnm.es id j481vahk005566
**** CUERPO DEL MENSAJE ****
Cabeceras que habitualmente
muestra un cliente de correo (UA)
• 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).
• El correo pasa por estafetas internas de gmail (2,3).
• El correo lo recibe la estafeta principal de esa zona,
la IP origen es 64.233.162.195. (4)
• El paso (5) es interno en la red destino (antivirus).
[De todas las cabeceras, sólo 4 y 5 son fiables 100%]
1
2
3
4
5
Visualizar mensaje
(mozilla): Ctrl-U
SMTP
fiabilidad de las cabeceras Received: from titan.imse.cnm.es (titan [150.214.7.30])
by mx.imse.cnm.es (8.13.3/8.12.11) with ESMTP id j48GkcRH024345
for <[email protected]>; Sun, 8 May 2005 18:46:38 +0200 (MEST)
Received: from us.es (2.Red-80-34-1.pooles.rima-tde.net [80.34.1.2])
by titan.imse.cnm.es (8.13.3/8.13.3) with SMTP id j48GfTC2022102
for <[email protected]>; Sun, 8 May 2005 18:41:52 +0200
(MEST)
Received: from murillo.eii.us.es (murillo.eii.us.es [150.214.142.14]) by
us.es with SMTP; 8 May 2005 18:27:33 +0200
Received: from localhost (localhost [127.0.0.1]) by murillo with
ESMTP; 8 May 2005 18:27:30 +0200
Date: Sun, 8 May 2005 18:31:18 +0200 (MEST)
Message-Id: <[email protected]>
From: Spammer <[email protected]>
To: Jaime Benjumea <[email protected]>
Subject: Publicidad.
Esto es pura y simplemente publicidad.
Un saludo.
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.
Este es el dato
real de la IP que
se ha conectado.
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.
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 email se ha generado
inyectando el correo directamente en la
estafeta principal del dominio imse.cnm.es. El
origen es una IP de TDE: 80.34.1.2
Regla de Oro: Sólo nos podemos fiar de las cabeceras que hayan puesto nuestras estafetas, el resto pueden ser falsas.
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.
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 email 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.
MIME
quoted-printable vs base64
• Permiten transferir ASCII de 8 bits y ficheros binarios sobre un email 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
MIME-Version: 1.0
Date: Sat, 6 Apr 2013 22:20:41 +0200
Message-ID: <[email protected]>
Subject: HOLA
From: Jaime Benjumea <[email protected]>
To: Jaime Benjumea <[email protected]>
Content-Type: multipart/mixed; boundary=20cf307813380b589f04d9b6f069
--20cf307813380b589f04d9b6f069
Content-Type: text/plain; charset=ISO-8859-1
Este email tiene un adjunto.
--
Jaime Benjumea
--20cf307813380b589f04d9b6f069
Content-Type: application/pdf; name="normas.pdf"
Content-Disposition: attachment; filename="normas.pdf"
Content-Transfer-Encoding: base64
JVBERi0xLjQNJeLjz9MNCjQgMCBvYmoNPDwgDS9MJpemVkIDEgDS9PIDcgDS9IIFsgMTM0
MiAyMTUgXSANL0wgMzU3NDU0IA0vRSAzNTU1ODIgDS9OIDEM1NzI1NyANPj4gDWVuZG9i
[…]
MzYyOD48MDhmYjk4NGFmZGE5Y2UzOTg3ZGU2ZmYwOWJlOTJmZDI+XQ0GDQ==
--20cf307813380b589f04d9b6f069--
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)
Boundary: Indica la
cadena de separación
entre las distintas partes.
OJO a las coincidencias
dentro del mensaje.
Este es el cuerpo
del e-mail: Texto
plano y ASCII de
7bits.
Aquí
comienza
otra parte. Información de esta parte
del email. Un fichero tipo
PDF, codificado en base 64
y con nombre “normas.pdf”
Fichero (truncado)
codificado en
Base64, nótese el
padding del final.
Estos dos “-” indican que
es la última parte.
El separador
es la cadena
boundary con
“--” al principio.
MIME-Version: 1.0
Date: Sun, 7 Apr 2013 01:54:54 +0200
Message-ID: <[email protected]>
Subject: Texto, html y adjunto
From: Jaime Benjumea <[email protected]>
To: Jaime Benjumea <[email protected]>
Content-Type: multipart/mixed; boundary=20cf3079bd622775e504d9b9eeab
--20cf3079bd622775e504d9b9eeab
Content-Type: multipart/alternative; boundary=20cf3079bd622775db04d9b9eea9
--20cf3079bd622775db04d9b9eea9
Content-Type: text/plain; charset=ISO-8859-1
Este mensaje se manda en texto plano y HTML.
--20cf3079bd622775db04d9b9eea9
Content-Type: text/html; charset=ISO-8859-1
Este mensaje se manda en texto plano y HTML.<br>
--20cf3079bd622775db04d9b9eea9--
--20cf3079bd622775e504d9b9eeab
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--
Se trata de un correo electrónico
enviado como HTML y texto y que
además tiene un documento adjunto.
MIME / Ejemplo 2
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.
Estos son los
dos contenidos
alternativos.
Texto y HTML,
pero ambos
dicen lo mismo.
Separador del
contenido
“mixed”.
Fin del
contenido
“alternative”.
Siguiente
contenido
“alternative”.
Siguiente
contenido
“mixed”
Fin del
contenido
“mixed”.
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.
Separador del contenido“alternative”
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-8859-1?Q?Elaboraci=F3n_de_gu=EDas_ECTS?=
Subject: Abierto el plazo de petición de libros
Subject: Abierto el plazo de =?ISO-8859-1?Q?petici=F3n_de_libros?=
Subject: Este_es_un_texto_extraño
Subject: =?ISO-8859-1?Q?Este=5Fes=5Fun=5Ftexto=5Fextra=F1o?=
Subject: No_necesariamente_se_codifica.
Subject: No_necesariamente_se_codifica.
Protocolos de acceso a correo
• 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.
Servidor de
correo (US)
Cliente de
correo (UA)
Protocolo
POP o IMAP
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).
Protocolo POP3
S: +OK POP3 perditon ready on e_entrada1 00029b8c
C: USER jaimebm
S: +OK USER jaimebm set, mate
C: PASS MiClave27
S: +OK You are so in
Fase de autorización:
• USER / PASS.
• -ERR en caso de error.
C: STAT
S: +OK 2 3861
C: LIST
S: +OK 2 messages:
S: 1 1915
S: 2 1946
S: .
C: UIDL
S: +OK
S: 1 c824c610868a50511e5e0000da53751c
S: 2 a8492110128c5051bc660000da53751c
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.
Fase de transacción:
• STAT: Indica el número de emails 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.
NOTA: El UA es Thunderbird.
Fase de actualización (UPDATE):
• Se entra al enviar el cliente “QUIT”.
• Se borran los mensajes marcados.
• Puede dar error (pero se sale).
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
• 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).
Características IMAP
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.
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)
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 1296933927] UIDs valid
S: * OK [UIDNEXT 536] Predicted next UID
S: 7 OK [READ-WRITE] Select completed.
Sesión IMAP (2) 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.
• 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.
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: <[email protected]>
Date: Mon, 25 Mar 2013 18:40:25 +0100
From: Jaime Benjumea <[email protected]>
Subject: Este es cortito
Content-Type: text/plain; charset=ISO-8859-1; 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.
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-8859-1; 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.
Otras órdenes en IMAP
• CREATE /DELETE/RENAME.
• SUSCRIBE/UNSUSCRIBE.
• LIST.
• APPEND.
• SEARCH.
• STORE
• COPY
• EXPUNGE.
48
HTTP. Introducción
Petición1 HTTP
Respuesta 1 HTTP
Petición2 HTTP
Respuesta 2 HTTP
HTTP es “stateless”, la petición 2 no guarda datos de la anterior.
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
Servidor web (Apache, IIS,
etc):
• Alberga las páginas (estáticas
y dinámicas).
• Responde a las peticiones del
cliente
• 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.
http://host[:port][abs_path[?query]]
Nombre del servidor Puerto (opcional) Path de acceso al objeto (html, gif, etc)
Protocolo de acceso.
Otros: ftp, https
Parámetros enviados
al objeto (script)
• 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
• 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.
Proxy Cliente Servidor
PROXY EXPLÍCITO
Proxy Cliente Servidor
El acceso
directo (80/tcp)
se prohíbe.
Las salidas a 80/tcp se
redireccionan al proxy
• El cliente ni conoce su existencia ni puede evitar su uso.
• 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.
PROXY TRANSPARENTE
HTTP. Ejemplo de funcionamiento GET / HTTP/1.1
Host: www.dte.us.es
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040914
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8
Keep-Alive: 300
Connection: keep-alive
Petición HTTP
(página principal)
HTTP/1.1 200 OK
Date: Wed, 31 Aug 2005 09:51:59 GMT
Server: Apache/1.3.33 (Unix) PHP/4.3.11 mod_ssl/2.8.22 OpenSSL/0.9.7g
Last-Modified: Thu, 23 Sep 2004 11:52:40 GM
ETag: "f257-1f33-4152b908“
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)
Cabecera
s
Respuesta HTTP
(página principal)
Es un gif, se descargará en
una petición independiente:
GET /art/logodte.gif
• 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.
Indica el path
solicitado.
HTTP. Peticiones y respuestas
Método <SP> URI <SP> Version-HTTP <CRLF>
Cabecera_1 <CRLF>
Cabecera_N<CRLF>
<CRLF>
Datos
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
Figura: Petición HTTP
OJO: Retorno de carro
y cambio de línea (\r\n)
En una petición también puede
haber datos: upload de un fichero
PETICIÓN: La genera el cliente web (navegador) y la interpreta el servidor o el proxy
RESPUESTA: La genera el servidor web y la interpreta el proxy o el navegador
Version-HTTP <SP> Code <SP> Reason <CRLF>
Cabecera_1 <CRLF>
Cabecera_N<CRLF>
<CRLF>
Datos
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.
Figura: Respuesta HTTP
51
HTTP. Petición GET Las peticiones GET permiten al navegador solicitar un objeto (HTML, GIF, páginas dinámicas, CGI )
GET /gifs/logoimse1.gif HTTP/1.1
Host: www.imse.cnm.es
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040914
Accept: image/png,*/*;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.imse.cnm.es/
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Date: Wed, 31 Aug 2005 09:51:59 GMT
Server: Apache/1.3.33 (Unix) PHP/4.3.11 mod_ssl/2.8.22 OpenSSL/0.9.7g
Last-Modified: Fri, 11 Apr 1997 08:52:18 GMT
ETag: "1080b-8292-334dfbc2“
Accept-Ranges: bytes
Content-Length: 33426
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive
Content-Type: image/gif
GIF89a..U.......
Cliente Web
(Mozilla)
PETICIÓN
Se indica el path absoluto de la petición. Además la versión de HTTP soportada
Indica el servidor, es un campo obligatorio. Uso: Servidores virtuales
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-8859-1, 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
Respuesta, el código 2xx indica que tuvo éxito, el mensaje OK es sólo para tratamiento manual.
Fecha, la pone el servidor, siempre en GMT.
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.
Tipo de objeto (MIME), en este caso es un gif.
Aquí comienza el fichero gif, codificado directamente en binario.
Esto se transmitirá
en varios segmentos
TCP, pero eso es
transparente para la
aplicación.
RESPUESTA
Servidor
Web
(Apache y
otros
módulos)
52
HTTP. Peticiones HEAD y TRACE $ telnet www.eii.us.es 80
HEAD / HTTP/1.1
Host: www.eii.us.es
Línea en blanco
HTTP/1.1 200 OK
Date: Thu, 01 Sep 2005 15:57:39 GMT
Server: Apache
X-Powered-By: PHP/4.3.2
Set-Cookie: PHPSESSID=aed768bc843381609741254a4e34d0bc; path=/
Expires: Thu, 19 Nov 1981 08: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-8859-1
Respuesta
Respuesta a la petición
ejecutada con éxito.
Aquí iría la página
web, si la petición
hubiera sido GET Línea en blanco
La cabeceras contienen datos
útiles para el navegador o el
proxy (en este caso referentes a
no guardar la pagina en cache).
Esta petición no
descargará la
página sólo las
cabeceras que
se generarían.
Petición
HEAD
bash-2.03$ telnet www.eii.us.es 80
TRACE * HTTP/1.1
Host: www.eii.us.es
X-MiCabecera: Test loopback.
Petición
TRACE
Respuesta
HTTP/1.1 200 OK
Date: Thu, 01 Sep 2005 16:54:38 GMT
Server: Apache
Transfer-Encoding: chunked
Content-Type: message/http
TRACE * HTTP/1.1
Host: www.eii.us.es
X-MiCabecera: Test loopback.
Línea en blanco Esto es un eco de lo que
ha recibido el servidor
web. Son datos (una
copia de la cabecera
recibida).
Ahora las cabeceras
son más cortas.
Esta cabecera me la
he inventado, HTTP
permite hacer eso. Línea en blanco
bash-2.03$ telnet www.terra.es 80
TRACE / HTTP/1.1
Host: www.terra.es
X-MiCabecera: Test loopback
Respuesta HTTP/1.1 200 OK
Transfer-Encoding: chunked
Date: Thu, 01 Sep 2005 17:07:37 GMT
Content-Type: message/http
Server: Sun-ONE-Web-Server/6.1
TRACE / HTTP/1.1
Host: www.terra.es
Connection: keep-alive
X-micabecera: Test loopback
X-forwarded-for: 150.214.142.14
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 www.terra.es
Esta cabecera el indica al servidor
que la petición realmente viene de
150.214.142.14 (dado que quien
finalmente ha accedido a
www.terra.es fue un proxy).
53
HTTP. Petición condicional
• Muchas páginas no se modifican todos los días, mucho menos las imágenes, logos, etc.
• El navegador suele tener un espacio en el que almacena las peticiones recientes (caché) de forma que si ya tiene un
objeto, sólo se descarga si se ha modificado.
GET /gifs/logoimse1.gif HTTP/1.1
Host: www.imse.cnm.es
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040914
Accept: image/png,*/*;q=0.5Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.imse.cnm.es/
If-Modified-Since: Fri, 11 Apr 1997 08:52:18 GMT
If-None-Match: "1080b-8292-334dfbc2“
Cache-Control: max-age=0
Petición
• La petición condicional permite expresar una
condición para que se descargue el documento
completo.
• Son peticiones GET, en este caso, normales pero
con cabeceras If-Modified que modifican el
comportamiento habitual del servidor
En este caso, el navegador como tiene guardado
(del acceso de la trasparencia del GET) el
fichero gif, en vez de descargarlo
incondicionalmente añade estos tags (que los
tiene guardados de la respuesta anterior)
HTTP/1.1 304 Not Modified
Date: Wed, 31 Aug 2005 09:54:51 GMT
Server: Apache/1.3.33 (Unix) PHP/4.3.11 mod_ssl/2.8.22 OpenSSL/0.9.7g
Connection: Keep-Alive, Keep-Alive
Keep-Alive: timeout=15, max=97
ETag: "1080b-8292-334dfbc2"
Respuesta
No se enviará el objeto porque el de la caché es
válido (actual).
Sólo se devuelve 304 si (NO) se
cumplen ambas condiciones (en teoría).
54
HTTP. Cookies
• Son un mecanismo para añadir “estados” al HTTP. Permite que el navegador almacene ciertos datos y que éste
luego los muestre.
• Permite almacenar sesiones, rastrear datos de navegación, ... ( a veces se consideran intrusivas a la privacidad).
• Está definido por Netscape y mejorado en RFC2965. Veremos el primero (usado en PHP).
Set Cookie: NAME=VALUE; expires= DATE; path=PATH; domain=DOMAIN_NAME; secure
Nombre y valor de la
cookie, es el único
parámetro obligatorio.
Validez de la cookie (si no
se especifica se considera
hasta fin de sesión)
Indica el path donde es válida
la cookie (si no se especifica
se considera el actual)
Indica el dominio
en el que es
válida la cookie
Si la cookie se marca
como segura, sólo debe
usarse con https.
Cookie: NAME1=OPAQUE_STRING1; ...
El nombre es el
especificado
con Set-Cookie
El valor
especificado en
VALUE
Resto de
cookies
pertinentes.
• Las cookies las establece el servidor con esta cabecera, deben enviarse
tantas como cookies queramos establecer.
• Su función es guardar un determinado dato en el cliente, puede ser el
último acceso, el último banner visualizado, o una identificación de sesión
(carrito de la compra).
• El concepto de sesión (expires) es “hasta cerrar el navegador”.
• Set Cookie: Acceso=959595,
• El navegador guarda la cookie localmente.
• Cada vez que acceso a una página, se
comprueba si alguna cookie almacenada
concuerda con el dominio y path al que
accedemos, se envía (varias por cabecera).
• Las cookies que expiran, se borran.
• Cookie:
• La cookies se transmiten de forma insegura a no ser que usemos https a Es sencillo robar una sesión si no se usa https.
• Las cookies se almacenan en el navegador, normalmente con pocas o ninguna restricción de acceso.
• El navegador siempre puede devolver la cookie que quiera (puedo falsificar una cookie).
55
Nombre Uso Significado Ejemplo
Accept Petición Indica los tipos MIME que son aceptables por el que solicita la petición text/html;q=0.9,text/plain;q=0.8
Accept-Charset Petición Indica el juego de caracteres que son aceptables por el solitante. ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding Petición Indica qué condificaciones aceptamos gzip,deflate
Accept-Language Petición Indica qué lenguaje preferimos (orden de preferencia normalmente)
Accept-Ranges Respuesta Indica si el servidor permite descarga parcial de contenido bytes
Cache-Control Respuesta Indica qué se debe hacer con el contenido respecto a las cachés. max-age=20
Connection Ambos Indica si se cierra la conexión (no persistente) o se mantiene después de la
petición.
close
Content-Encoding Repuesta Indica la codificación usada Gzip
Content-Languaje Respuesta Indica el idioma de lo que se devuelve ES
Content-Length Respuesta Indica la longitud en bytes 12433
Content-type Respuesta Indica el tipo de objeto devuelto image/gif
Cookie Petición El navegador muestra una cookie preexisitente
Date Ambos Indica la fecha y hora actual Wed, 31 Aug 2005 09:54:51 GMT
Etag Respuesta Sirve para comprobar si el origen se ha modificado f257-1f33-4152b908
Expires Respuesta Indica cuando se considera no válida la página (a efectos de caché) Thu, 19 Nov 1981 08:52:00 GMT
Host Petición Indica el host al que se hace la petición (es obligatorio para peticiones HTTP/1.1) www.eii.us.es
If-Modified-Since Petición Permite especificar un GET condicional, por fecha Wed, 23 Sep 1998 11:48:00 GMT
If-None-Match Petición Permite especificat un GET condicional, por ETag f257-1f33-4152b908
Last-Modified Respuesta Indica la fecha en la que el servidor cree que se modificó la fuente Wed, 31 Aug 2005 09:54:51 GMT
Referer Petición Indica de dónde se ha obtenido el objeto o página que el cliente está pidiendo
(NB: Se escribe “Referrer”, pero la especificación dice “Referer”)
http://www.imse.cnm.es/
Server Respuesta Campo de texto que identifica al servidor web Apache/1.3.33 (Unix) PHP/4.3.11
mod_ssl/2.8.22 OpenSSL/0.9.7g
Set-Cookie Respuesta Establece una cookie en el navegador, ver RFC2109 y RFC2965 PHPSESSID=aed768bc843381609
741254a4e34d0bc; path=/
User-Agent Petición Indica qué navegador está accediendo al servidor Mozilla/5.0 (X11; U; SunOS sun4u;
en-US; rv:1.7.3) Gecko/20040914
56
Bibliografía • [ALBI2001]: “DNS and BIND, Fourth Edition”; Paul Albitz, Cricket Liu;
O'Reilly, 2001.
• [STEV1993]: “TCP/IP Illustrated, Volume 1: The Protocols.”, W. Richard
Stevens, Addison Wesley, 1993.
• [NETS1999]: “Persistent Client State http Cookies”; Netscape; Netscape,
1999. http://wp.netscape.com/newsref/std/cookie_spec.html.
• [RFC1945]: “Hypertext Transfer Protocol -- HTTP/1.0”; T. Berners-Lee, R.
Fielding, H. Frystyk; RFC, 1996.
• [RFC2045-2049]: “Multipurpose Internet Mail Extensions (MIME)”
• [RFC2616]: “Hypertext Transfer Protocol -- HTTP/1.1”; R. Fielding, J.
Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee; RFC,
1999.
• [RFC2821]: “Simple Mail Transfer Protocol”; J. Klensin; RFC, 2001.
• [RFC2965]: “HTTP State Management Mechanism”; D. Kristol, L. Montulli;
RFC, 2000.
Top Related