Formato del Mail: __________________
| Cabecera
| <-- Campo: Valor ; otracosa: algo;
|--------------- |
MIME VERSION: 1.0
|
|
Content Type: ... (Tipo MIME del mensaje)
| Cuerpo
|
|__________________|
Normalmente los mail se mandan codificados en 7 bits (aunque tambien se pueden enviar en 8 bits si se le especifica), pero nunca se pueden mandar caracteres con valor ASCII menor a 32, aunque se puede conseguir pasando a la información a base64.
Para mandar "cosas" (como pueden ser imagenes, sonidos, etc), se introduce
el campo de "Content Type" del MIME con la forma "tipo/subtipo".
Otro campo importante es el "Content_Transfer_Encoding", que puede
tomar los valores {7 bits, 8 bits, base64 o quoted_pr_table}, y son la
forma en que se codifica el mensaje.
Ejemplo:
Content_Type: application/x-shockware-flash-preview : name = "o-birdbird.swf"
Content_Transfer_Encoding : base64
fztdTge0lkd.eljjgañldkfjeognneñxiESoieñl0Elgmp4sñ,vm
jfg9emgDoenñ93'ñmfkeokvmañefasoi38.kmfasdfkenvld
...
Existe un tipo de MIME se denomina multipart y puede ser:
Multipart / -- Signed <- SMIME
|- Mixed
|- Related
| - Alternative
El Mixed es la forma de indicat que el mail se compone de una colección de entidades MIME:
Cabecera: MIME_Version: 1.0
Content_Type: multipart/mixed
El reto de campos van definidos en cada uno de los objetos MIME.
Content_Type: multipart / mixed ; boundary = ######churro##### <- Delimitador entre objetos
Un ejemplo de la composición de las partes MIME podria ser:
MIME Version: 1.0
Content Type: multipart / mixed
Mensaje opcional (el mailer no lo deberia sacar)
--churro (el boundary)
Content Type: text / plain
Hola.
--churro
Content Type: image / png
Content Transfer Encoding: base64
jfkdsahoieu9803lkjsdiASeSdrmeo3Haksejoi...
--churro-
Si se añaden unos tipos al MIME se consigue el SMIME que sirve para cifrar el correo, un mensaje cifrado seria:
MIME Version: 1.0
Content Type: application / x-PKCS7-MIME
Content Transfer Encoding: base64
alñskdff93nlkaSdneESjidsjfaESA34jñijñlasdfnohgjnrepo1·njhpo,df
asdoi4rbvmn-re3:fdERhhjr$mgisñlaErmo4mhgMkjfasou4nnghfd34
...
Una vez descifrado, puede haber un multipart, o cualquier otra
cosa, por lo que una vez descifrado se elimina la linea en blanco y las
dos anteriores (Content Type y Content Transfer Encoding) y queda un mail
normal.
Si el mail va firmado, tiene que cumplir que el lector tiene que poder leerlo aunque no pueda verificar la firma, entonces el mail tiene que tener dos partes, por una parte el mail en si, y por la otra la firma:
MIME Version: 1.0
Content Type: multipart / signed ; protocol = "application / x-PKCS7-Signature"
; micalg = Shai; boundary = "tarari"
--tarari
MAIL (a lo que se le va a realizar la firma) <- Podria ser un multipart
--tarari
Content Type: application / x-PKCS7-Signature
Content Tranfer Encoding: base64
ljkasfdhg378thgsDFSerqawlñkjrt8ybfxñhldgs$lñkhdfzsadF4iht0832ñhlasfop
afsñlhfdasiò3rqpoytablñdagn.-bvEhi32489y'0hñlafkvbdfasohgrlknbfn-.jklde
asñlhk43-gASñlheraopreqwHilñ48relñkzlasdknaeouierSHDñlrqwpo8agñkuh
afsdñ lhkaef8poy34SDAGJerhoñ3-lgGSAknleop48y09afhñly5hlñiearbkañkd
--tarari-
El PKCS7 da la posibilidad de transportar datos y certificados (en un
entorno criptografico, aunque no tienen porque ir encriptados). Pueden
ir:
- Data (tal cual)
- Signed Data (datos firmados)
- Enveloped Data (datos encriptados)
- Signed and Enveloped Data (datos firmados y encriptados)
Lo normal es mandar la copia del certificado con que se ha firmado el
mail, para poder comprobar la firma.
Hay dos formas de hacerlo (las anteriores), pero no son excluyentes entre si.
Las extremo a extremo las utilizan las aplicaciones de los usuarios
y las de enlace se realizan en la capa de enlace de la red, por lo que
sirve para cualquier tipo de información.
.
.
En el de enlace es la transmisión es segura, pero del software de red hasta la aplicación la información ya está descifrada, por lo que puede ser menos segura que la extremo a extremo, pero tiene la ventaja que cualquier aplicación puede aprovechar esa información. Por ahora es dificil de extender la de enlace a una red grande, mientras que la extremo a extremo, simplemente se cifra y se envia.
Cifradores de Sesión
SSL: Es un cifrador para web, aunque tambien hat para telnet,
ftp, etc. (es propiedad de Netscape)
TLS: Es una "variante" del SSL aunque es de un organismo publico.
IPSEC: No es el unico, pero es el más "serio"
Aplicación ----,
,---- Aplicación
<-- Extremo a Extremo
____________
|
| _____________
| TCP
| |
| |
TCP |
|---------- |
|
| |----------- |
| IP
! --, |_________| ,-- |
IP |
<-- Enlace
|---------- | |
| |----------- |
| Ethernet |
|____________| |
Ethernet |
|____________|
|_____________|
\______________________/
SSL
Tiene básicamente tres propositos:
-Confidencialidad
-Autentificación del servidor
-Autentificación del cliente (optativa)
La idea basica es que se pueda comunicar una serie de clientes de forma
confidencial, y además sepan quien es el servidor (el servidor se
autentifica ante el cliente).
Por ejemplo, al consultar la cuenta en el banco, el cliente quiere
saber seguro que es el banco con quien conecta, y el banco podria querer
saber quien es el cliente, si no lo autentifica por otros metodos.
El SSL tiene una fase inicial donde se produce la identificación:
Al conectar el cliente y el servidor se ponen de acuerdo en los algoritmos
de cifrado a utilizar, en cuanto comprueban que los dos pueden utilizar
los mismos, el servidor envia un certificado al cliente, y este lo comprueba
(con la clave publica de la autoridad certificadora comprueba que la firma
es correcta) y obtiene la clave publica que hay en el certificado.
NOTA: Los datos del certificado del servidor son iguales que los personales, pero en el nombre (CN) aparece (por convenio) el nombre del servidor en internet.
Una vez tener la clave publica, se comprueba si el servidor tiene la clave privada, esto se consigue enviando algo cifrado con la clave publica (esto se llama lanzar un reto) y si puede descifrarla es que tiene la clave, y por tanto sabemos que es el servidor con quien queremos conectar. Lo que se envia cifrado suele ser la clave de sesión, así se puede comenzar una comunicación confidencial con esta llave, y al ser ya una comunicación segura se puede pedir el user y el password, que se van a enviar cifrados y no hay peligro.
Otra forma de autentificación puede ser en una red donde todos pueden tener una clave publica, entonces el certificado del cliente puede servir como autentificación y se siguen los mismos (o casi) pasos que en la autentifiación del servidor, solo que se responde al reto con la información que se envió descifrada.