MECSA evalúa la capacidad que un servidor de correo demuestra para proteger la privacidad y seguridad de las comunicaciones de email con otros proveedores, analizando qué estándares de seguridad soporta para la protección de dichas comunicaciones.
StartTLS [RFC3207, RFC7817] es una extensión del protocolo SMTP [RFC5321] (Simple Mail Transfer Protocol) utilizado para habilitar el cifrado TLS [RFC5246] (Transport Layer Security) en las comunicaciones entre el cliente y el servidor (remitente y destinatario). Durante la comunicacion SMTP el servidor anuncia su compatibilidad con StartTLS en la respuesta al comando EHLO enviado por el cliente. Llegado a este punto, el cliente continuará enviando el comando STARTTLS para indicar que quiere iniciar una negociación de TLS. Durante esta negociación se realizarán los siguientes pasos
Ejemplo de dialogo SMTP extraído de RFC3207:
S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.imc.org SMTP service ready
C: EHLO mail.example.com
S: 250-mail.imc.org offers a warm hug of welcome
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 DSN
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
C: EHLO mail.example.com
S: 250-mail.imc.org touches your hand gently for a moment
S: 250-8BITMIME
S: 250 DSN
Los certificados X.509 se usan para verificar la identidad y/o clave pública de los participantes en una comunicación (por ejemplo, durante la negociación de TLS). Los certificados X.509 (a veces también llamados certificados SSL) toman su nombre del formato de certificado adoptado por Netscape cuando diseñó la primera versión del protocolo SSL. Un certificado X.509 actúa como contenedor de cierta información específica sobre la identidad a la que se ha emitido el certificado y la identidad del emisor. Entre los campos más importantes almacenados en un certificado X.509 se encuentran los siguientes:
Versión: versión del formato x.509.
Número de serie: número único asignado al emisor.
Información del algoritmo: descripción del algoritmo usado para firmar el certificado.
Issuer distinguished name: nombre del emisor del certificado (suele ser una Autoridad de Certificación, CA)
Periodo de validez del certificado: Fechas de inicio y fin de validez del certificado.
Subject distinguished name: nombre de la entidad a la cual se ha emitido el certificado.
Subject public key information: clave pública del dueño del certificado.
El formato del certificado se establece en la RFC5280 . Los métodos de acceso al certificado y las maneras de procesarlo se definen en RFC4210 . RFC3739 define lo que se llama un Certificado Calificado, relacionado con la Directiva europea sobre firma electrónica (Directiva 1999/93 / CE) .
SPF [ RFC7208 , RFC7372 ] (Sender Policy Framework) es un protocolo que permite a los proveedores de correo electrónico anunciar una lista de hosts (direcciones IP) autorizados a enviar correos electrónicos en su nombre. Siguiendo el protocolo SMTP, cuando un cliente se identifica a sí mismo (comandos HELO o EHLO ) debe indicar un nombre de host o una dirección IP. De la misma manera, cuando el cliente inicia la transmisión de un correo electrónico debe enviar el comando MAIL-FROM indicando la dirección de correo electrónico del remitente.
Ambos campos, el nombre de host (o dirección IP) del comando HELO (o EHLO) y la dirección de correo electrónico (MAIL-FROM) deben ser confrontados con los parámetros del registro SPF publicado por el proveedor de correo electrónico correspondiente con el objectivo de verificar si el cliente tiene permiso para enviar correos electrónicos en nombre de dicho proveedor de correo electrónico. Las políticas SPF son publicadas como registros TXT en el dominio DNS del proveedor de correo electrónico. Ejemplo: registro SPF del dominio et.dcslab.eu :
v=spf1 a mx ip4:139.191.36.5 -all
v=spf1 versión
a aceptar la IP si está incluida en el registro DNS tipo A de et.dcslab.eu
mx aceptar la IP si pertenece a un MX de et.dcslab.eu
ip4:139.191.36.5 aceptar la IP si está dentro del rango indicado
-all el valor por defecto es Fallo
DKIM [RFC6376] (DomainKeys Identified Mail) es un mecanismo de autenticación utilizado para verificar el origen legítimo de un correo electrónico.
Usa firmas digitales para verificar la identidad del emisor. El proveedor de correo electrónico genera un par de claves pública/privada para un dominio y publica la clave pública en un registro DNS. Cada vez que se envía un correo electrónico, éste se firma con la clave privada. Una vez que el destinatario recibe el mensaje, puede validar la firma utilizando el registro publicado. De esta manera el destinatario puede verificar ambos elementos.
Ejemplo de cabeceras DKIM en un mensaje recibido:
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=et.dcslab.eu; s=102016; t=1476792726; bh=HS0o/CkH/ZCpSrfolDyH8IR5hX6n8GxWLzY59OuvtWo=; h=Date:From:From:Subject; b=OOlOO/jae1cPF2pllIF2QiENPJdUvGL70FdPMkKa89qkhXdvr D89eZwK6OZzEdLYncAbYCrEVi58jFqFAjKBcASrRpjSQXTJX6hM cRNZ295/1xp8vR/J9CQl9baqGxhYWID8Z0OrN/tbwXNN2UiNTmk MIm90UDJHdQnw/rd9rX4=
En el ejemplo previo, para recuperar la clave y comprobar la firma DKIM se envía una petición DNS de tipo TXT al dominio: 102016._domainkey.et.dcslab.eu.
DMARC [ RFC7489 ] (Domain-based Message Authentication, Reporting and Conformance) es un mecanismo que permite a los proveedores publicar políticas relativas a la aplicación de SPF y DKIM.
En particular, permite a los proveedores de correo electrónico indicar qué hacer cuando un mensaje no cumple con su políticas SPF o DKIM (rechazar, poner en cuarentena, nada) e indicar una dirección de correo electrónico para la recepción de informes.
También se puede usar para definir una política de aceptación/rechazo de un cierto porcentaje de mensajes fallidos para permitir un despliegue gradual de estas tecnologías. Ejemplo, registro DMARC del dominio et.dcslab.eu :
v=DMARC1; p=reject; rua=mailto:dmarc_reports@et.dcslab.eu
v=DMARC1 versión de DMARC
p=reject política a aplicar por el receptor: none/quarantine/reject
rua=mailto.. dirección donde enviar los informes
DNS-based Authentication of Named Entities [RFC6698, RFC7218, RFC7671, RFC7672] (DANE) es un mecanismo que vincula certificados x.509 (o claves públicas) a servicios, especificando el puerto, protocolo y dominio donde se encuentra el servicio al que se refiere. Dicho vínculo entre el certificado y el servicio se publica como un registro DNS de tipo TLSA. DANE puede ser aplicado a cualquier servicio. En el caso de las comunicaciones por correo electrónico, el RFC7672 describe la aplicación de DANE y DNSSEC a las comunicaciones (SMTP) entre MTAs. Un elemento importante es que dicho RFC recomienda utilizar DANE-TA o DANE-EE con DNSSEC.
Un registro de TLSA contiene 4 valores: Usage-Field, Selector-Field, Matching-Type-Field y Associated-Data. A continuación se describen los diferentes campos que se pueden encontrar en un registro TLSA.
Por ejemplo, el registro de TLSA para un servidor SMTP que se ejecuta en el puerto predeterminado (25) del host mx.example.com utilizando DANE-EE y publicando el SHA2-256 de la clave pública (SPKI) del certificado, sería:
_25._tcp.mx.example.com TLSA 3 1 1 1cf...6ab
Usage-Field
Selector-Field: Especifica que parte del certificado x.509 debe usarse en la evaluación contra los datos asociados al registro TLSA
Matching-Type-field: Indica el formato de los datos asociados
Associated-Data:
Domain Name System Security Extensions [RFC4033, RFC6014, RFC6840] (DNSSEC) es un protocolo utilizado para autenticar las respuestas de los servidores DNS. Este mecanismo se usa para evitar que las aplicaciones utilicen registros DNS alterados o falsificados. El protocolo puede autenticar un conjunto de registros DNS a través de la verificación de una firma criptográfica asociada. Para lograr su propósito, DNSSEC introduce los siguientes tipos de registros adicionales:
Para habilitar DNSSEC el servidor debe tener dos pares de claves (públicas y privadas). El primer par se compone por las claves de firma de zona pública y privada (ZSK), mientras que el segundo par son las claves de firma de clave (KSK). Con el ZSK privado, el servidor firma digitalmente todo el RRSET en el DNS (grupo de registros DNS del mismo tipo, por ejemplo, MX, TXT, etc.) y almacena sus firmas en un registro RRSIG. El ZSK público es necesario para verificar sus firmas y se publica como un registro DNSKEY. El registro DNSKEY de la clave ZSK pública está firmado con la clave privada KSK. El la clave KSK pública también se publica como un registro de DNSKEY y está autofirmado, es decir, está firmado con la clave KSK privada. Esta secuencia de pasos establece la confianza dentro de la zona.
Como el DNS es un servicio jerárquico, la confianza dentro de una zona debe estar conectada con la zona principal. Para este propósito, el servidor codifica la clave KSK pública y publica este hash como un registro DS en su zona principal.
