tema 6. protocolos de nivel de aplicación · 1 tema 6. protocolos de nivel de aplicació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)

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).

http://www.google.es/





http://www.google.com/

http://www.google.com/

http://www.l.google.com/

http://www.l.google.com/

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

[email protected]

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

To: [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:


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


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


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


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)


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


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


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


Subject: HOLA

From: Jaime Benjumea <[email protected]>


Content-Type: multipart/mixed; boundary=20cf307813380b589f04d9b6f069

--20cf307813380b589f04d9b6f069


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


Subject: Texto, html y adjunto



Content-Type: multipart/mixed; boundary=20cf3079bd622775e504d9b9eeab

--20cf3079bd622775e504d9b9eeab

Content-Type: multipart/alternative; boundary=20cf3079bd622775db04d9b9eea9

--20cf3079bd622775db04d9b9eea9


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}


Date: Mon, 25 Mar 2013 18:40:25 +0100



Subject: Este es cortito

Content-Type: text/plain; charset=ISO-8859-1; format=flowed

)


• 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


BODY[TEXT]<0> {65}

Este es un mensaje que ocupa muy poco.

--

Jaime Benjumea

)


C: 27 UID fetch 537:* (FLAGS)

S: * 2 FETCH (UID 536 FLAGS (\Recent))


32 logout

* BYE Logging out

32 OK Logout completed.

Otras órdenes en IMAP

• CREATE /DELETE/RENAME.

• SUSCRIBE/UNSUSCRIBE.

• LIST.

• APPEND.

• SEARCH.

• STORE

• COPY

• EXPUNGE.

ANEXO

47

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


Accept: image/png,*/*;q=0.5

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300


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


Last-Modified: Fri, 11 Apr 1997 08:52:18 GMT

ETag: "1080b-8292-334dfbc2“

Accept-Ranges: bytes

Content-Length: 33426


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


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


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


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


Connection: Keep-Alive, Keep-Alive


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.

http://wp.netscape.com/newsref/std/cookie_spec.html

tema 6. protocolos de nivel de aplicación · 1 tema 6. protocolos de nivel de aplicación...

Documents