Seguridad de red: capa de aplicación
Ahora se ofrecen varios servicios comerciales en línea a través de aplicaciones cliente-servidor. Los formularios más populares son la aplicación web y el correo electrónico. En ambas aplicaciones, el cliente se comunica con el servidor designado y obtiene los servicios.
Al utilizar un servicio de cualquier aplicación de servidor, el cliente y el servidor intercambian mucha información en la intranet o Internet subyacente. Somos conscientes del hecho de que estas transacciones de información son vulnerables a varios ataques.
La seguridad de la red implica proteger los datos contra ataques mientras se encuentran en tránsito en una red. Para lograr este objetivo, se han diseñado muchos protocolos de seguridad en tiempo real. Dicho protocolo debe proporcionar al menos los siguientes objetivos principales:
- Las partes pueden negociar de forma interactiva para autenticarse entre sí.
- Establezca una clave de sesión secreta antes de intercambiar información en la red.
- Intercambie la información en forma encriptada.
Curiosamente, estos protocolos funcionan en diferentes capas del modelo de red. Por ejemplo, el protocolo S / MIME funciona en la capa de aplicación, el protocolo SSL se desarrolla para funcionar en la capa de transporte y el protocolo IPsec funciona en la capa de red.
En este capítulo, analizaremos diferentes procesos para lograr la seguridad de la comunicación por correo electrónico y los protocolos de seguridad asociados. El método para proteger el DNS se explica a continuación. En los capítulos posteriores, se describirán los protocolos para lograr la seguridad web.
Seguridad del correo electrónico
Hoy en día, el correo electrónico se ha convertido en una aplicación de red muy utilizada. Analicemos brevemente la infraestructura del correo electrónico antes de proceder a conocer los protocolos de seguridad del correo electrónico.
Infraestructura de correo electrónico
La forma más sencilla de enviar un correo electrónico sería enviar un mensaje directamente desde la máquina del remitente a la máquina del destinatario. En este caso, es esencial que ambas máquinas estén funcionando en la red simultáneamente. Sin embargo, esta configuración no es práctica ya que los usuarios ocasionalmente pueden conectar sus máquinas a la red.
De ahí surgió el concepto de configurar servidores de correo electrónico. En esta configuración, el correo se envía a un servidor de correo que está disponible permanentemente en la red. Cuando la máquina del destinatario se conecta a la red, lee el correo del servidor de correo.
En general, la infraestructura de correo electrónico consiste en una malla de servidores de correo, también denominados como Message Transfer Agents (MTA) y máquinas cliente que ejecutan un programa de correo electrónico que incluye un agente de usuario (UA) y un MTA local.
Normalmente, un mensaje de correo electrónico se reenvía desde su UA, atraviesa la malla de MTA y finalmente llega al UA en la máquina del destinatario.
Los protocolos utilizados para el correo electrónico son los siguientes:
Protocolo simple de transferencia de correo (SMTP) utilizado para reenviar mensajes de correo electrónico.
El Protocolo de oficina postal (POP) y el Protocolo de acceso a mensajes de Internet (IMAP) se utilizan para recuperar los mensajes por destinatario del servidor.
MÍMICA
El estándar básico de correo electrónico de Internet se escribió en 1982 y describe el formato de los mensajes de correo electrónico intercambiados en Internet. Principalmente admite mensajes de correo electrónico escritos como texto en alfabeto romano básico.
En 1992, se sintió la necesidad de mejorar el mismo. Por lo tanto, se definieron Extensiones de correo de Internet multipropósito (MIME) estándar adicionales . Es un conjunto de extensiones del estándar básico de correo electrónico de Internet. MIME ofrece la posibilidad de enviar correo electrónico utilizando caracteres distintos a los del alfabeto romano básico, como el alfabeto cirílico (utilizado en ruso), el alfabeto griego o incluso los caracteres ideográficos del chino.
Otra necesidad que satisface MIME es enviar contenidos no textuales, como imágenes o videoclips. Debido a estas características, el estándar MIME se adoptó ampliamente con SMTP para la comunicación por correo electrónico.
Servicios de seguridad de correo electrónico
El uso creciente de la comunicación por correo electrónico para transacciones importantes y cruciales exige la provisión de ciertos servicios de seguridad fundamentales como los siguientes:
Confidentiality - El mensaje de correo electrónico no debe ser leído por nadie más que por el destinatario previsto.
Authentication - El destinatario del correo electrónico puede estar seguro de la identidad del remitente.
Integrity - Garantía al destinatario de que el mensaje de correo electrónico no ha sido alterado desde que fue transmitido por el remitente.
Non-repudiation - El destinatario del correo electrónico puede demostrarle a un tercero que el remitente realmente envió el mensaje.
Proof of submission - El remitente del correo electrónico recibe la confirmación de que el mensaje se entregó al sistema de entrega de correo.
Proof of delivery - El remitente recibe una confirmación de que el destinatario recibió el mensaje.
Los servicios de seguridad como la privacidad, la autenticación, la integridad de los mensajes y el no repudio se proporcionan generalmente mediante el uso de criptografía de clave pública.
Normalmente, hay tres escenarios diferentes de comunicación por correo electrónico. Discutiremos los métodos para lograr los servicios de seguridad anteriores en estos escenarios.
Correo electrónico uno a uno
En este escenario, el remitente envía un mensaje de correo electrónico a un solo destinatario. Por lo general, no más de dos MTA están involucrados en la comunicación.
Supongamos que un remitente desea enviar un correo electrónico confidencial a un destinatario. La provisión de privacidad en este caso se logra de la siguiente manera:
El remitente y el receptor tienen sus claves públicas privadas como (S PVT , S PUB ) y (R PVT , R PUB ) respectivamente.
El remitente genera una clave simétrica secreta, K S para el cifrado. Aunque el remitente podría haber utilizado R PUB para el cifrado, se utiliza una clave simétrica para lograr un cifrado y descifrado más rápidos.
El remitente cifra el mensaje con la clave K S y también cifra K S con la clave pública del destinatario, R PUB .
El remitente envía un mensaje cifrado y K S cifrado al destinatario.
El destinatario primero obtiene K S descifrando K S codificado utilizando su clave privada, R PVT .
El receptor descifra el mensaje utilizando la clave simétrica, K S .
Si en este escenario también se necesitan los servicios de integridad, autenticación y no repudio de mensajes, los siguientes pasos se agregan al proceso anterior.
El remitente produce el hash del mensaje y firma digitalmente este hash con su clave privada, S PVT .
El remitente envía este hash firmado al destinatario junto con otros componentes.
El destinatario utiliza la clave pública S PUB y extrae el hash recibido bajo la firma del remitente.
A continuación, el destinatario codifica el mensaje descifrado y ahora compara los dos valores hash. Si coinciden, se considera que se ha logrado la integridad del mensaje.
Además, el destinatario está seguro de que el remitente envía el mensaje (autenticación). Y por último, el remitente no puede negar que no envió el mensaje (no repudio).
Correo electrónico de uno a varios destinatarios
En este escenario, el remitente envía un mensaje de correo electrónico a dos o más destinatarios. La lista es administrada por el programa de correo electrónico del remitente (UA + MTA local). Todos los destinatarios reciben el mismo mensaje.
Supongamos que el remitente desea enviar un correo electrónico confidencial a muchos destinatarios (por ejemplo, R1, R2 y R3). La provisión de privacidad en este caso se logra de la siguiente manera:
El remitente y todos los destinatarios tienen su propio par de claves públicas y privadas.
El remitente genera una clave simétrica secreta, K sy cifra el mensaje con esta clave.
Luego, el remitente encripta K S varias veces con claves públicas de R1, R2 y R3, obteniendo R1 PUB (K S ), R2 PUB (K S ) y R3 PUB (K S ).
El remitente envía un mensaje cifrado y la correspondiente K S cifrada al destinatario. Por ejemplo, el destinatario 1 (R1) recibe un mensaje cifrado y R1 PUB (K S ).
Cada destinatario primero extrae la clave K S descifrando los K S codificados utilizando su clave privada.
Cada receptor descifra el mensaje utilizando la clave simétrica, K S .
Para proporcionar la integridad, autenticación y no repudio del mensaje, los pasos a seguir son similares a los pasos mencionados anteriormente en el escenario de correo electrónico uno a uno.
Correo electrónico de lista de distribución única
En este escenario, el remitente envía un mensaje de correo electrónico a dos o más destinatarios, pero el remitente no administra localmente la lista de destinatarios. Generalmente, el servidor de correo electrónico (MTA) mantiene la lista de correo.
El remitente envía un correo al MTA que administra la lista de correo y luego el MTA explota el correo a todos los destinatarios de la lista.
En este caso, cuando el remitente desea enviar un correo electrónico confidencial a los destinatarios de la lista de correo (digamos R1, R2 y R3); la privacidad está garantizada de la siguiente manera:
El remitente y todos los destinatarios tienen su propio par de claves públicas y privadas. Exploder Server tiene un par de claves públicas y privadas para cada lista de correo (List PUB , List PVT ) que mantiene.
El remitente genera una clave simétrica secreta K sy luego cifra el mensaje con esta clave.
El remitente luego encripta K S con la clave pública asociada con la lista, obtiene List PUB (K S ).
El remitente envía un mensaje cifrado y List PUB (K S ). El MTA exploder descifra Lista PUB (K S ) utilizando la lista de PVT y obtiene K S .
El exploder encripta K S con tantas claves públicas como miembros haya en la lista.
El Exploder reenvía el mensaje cifrado recibido y la K S cifrada correspondiente a todos los destinatarios de la lista. Por ejemplo, el Exploder reenvía el mensaje cifrado y R1 PUB (K S ) al destinatario 1 y así sucesivamente.
Para proporcionar la integridad, autenticación y no repudio del mensaje, los pasos a seguir son similares a los dados en el caso de un escenario de correo electrónico uno a uno.
Curiosamente, se espera que el programa de correo electrónico que emplea el método de seguridad anterior para proteger el correo electrónico funcione en todos los escenarios posibles discutidos anteriormente. La mayoría de los mecanismos de seguridad mencionados anteriormente para el correo electrónico son proporcionados por dos esquemas populares, Pretty Good Privacy (PGP) y S / MIME. Discutimos ambos en las siguientes secciones.
PGP
Pretty Good Privacy(PGP) es un esquema de cifrado de correo electrónico. Se ha convertido en el estándar de facto para proporcionar servicios de seguridad para la comunicación por correo electrónico.
Como se mencionó anteriormente, utiliza criptografía de clave pública, criptografía de clave simétrica, función hash y firma digital. Proporciona:
- Privacy
- Autenticación del remitente
- Integridad del mensaje
- Non-repudiation
Junto con estos servicios de seguridad, también proporciona compresión de datos y soporte de administración de claves. PGP usa algoritmos criptográficos existentes como RSA, IDEA, MD5, etc., en lugar de inventar los nuevos.
Funcionamiento de PGP
Se calcula el hash del mensaje. (Algoritmo MD5)
El hash resultante de 128 bits se firma utilizando la clave privada del remitente (algoritmo RSA).
La firma digital se concatena al mensaje y el resultado se comprime.
Se genera una clave simétrica de 128 bits, K S, que se utiliza para cifrar el mensaje comprimido con IDEA.
K S se cifra mediante la clave pública del destinatario mediante el algoritmo RSA y el resultado se adjunta al mensaje cifrado.
El formato del mensaje PGP se muestra en el siguiente diagrama. Los ID indican qué clave se utiliza para cifrar KS y qué clave se utilizará para verificar la firma en el hash.
En el esquema PGP, un mensaje está firmado y encriptado, y luego se codifica MIME antes de la transmisión.
Certificado PGP
El certificado de clave PGP se establece normalmente a través de una cadena de confianza. Por ejemplo, la clave pública de A está firmada por B usando su clave pública y la clave pública de B está firmada por C usando su clave pública. A medida que avanza este proceso, establece una red de confianza.
En un entorno PGP, cualquier usuario puede actuar como autoridad de certificación. Cualquier usuario de PGP puede certificar la clave pública de otro usuario de PGP. Sin embargo, dicho certificado solo es válido para otro usuario si el usuario reconoce al certificador como un presentador de confianza.
Existen varios problemas con este método de certificación. Puede resultar difícil encontrar una cadena que vaya de una clave pública conocida y confiable a la clave deseada. Además, puede haber varias cadenas que pueden conducir a diferentes claves para el usuario deseado.
PGP también puede usar la infraestructura PKI con una autoridad de certificación y las claves públicas pueden ser certificadas por CA (certificado X.509).
S / MIME
S / MIME son las siglas de Secure Multipurpose Internet Mail Extension. S / MIME es un estándar de correo electrónico seguro. Se basa en un estándar anterior de correo electrónico no seguro llamado MIME.
Trabajo de S / MIME
El enfoque S / MIME es similar al PGP. También utiliza criptografía de clave pública, criptografía de clave simétrica, funciones hash y firmas digitales. Proporciona servicios de seguridad similares a PGP para la comunicación por correo electrónico.
Los cifrados simétricos más comunes utilizados en S / MIME son RC2 y TripleDES. El método de clave pública habitual es RSA y el algoritmo hash es SHA-1 o MD5.
S / MIME especifica el tipo de MIME adicional, como "application / pkcs7-mime", para el envolvente de datos después del cifrado. Toda la entidad MIME está cifrada y empaquetada en un objeto. S / MIME tiene formatos de mensajes criptográficos estandarizados (diferentes de PGP). De hecho, MIME se amplía con algunas palabras clave para identificar las partes encriptadas y / o firmadas del mensaje.
S / MIME se basa en certificados X.509 para la distribución de claves públicas. Necesita una PKI jerárquica de arriba hacia abajo para el soporte de la certificación.
Empleabilidad de S / MIME
Debido al requisito de un certificado de la autoridad de certificación para la implementación, no todos los usuarios pueden aprovechar S / MIME, ya que algunos pueden desear cifrar un mensaje con un par de claves pública / privada. Por ejemplo, sin la participación o la sobrecarga administrativa de los certificados.
En la práctica, aunque la mayoría de las aplicaciones de correo electrónico implementan S / MIME, el proceso de inscripción de certificados es complejo. En cambio, el soporte de PGP generalmente requiere agregar un complemento y ese complemento viene con todo lo que se necesita para administrar las claves. La Web of Trust no se utiliza realmente. Las personas intercambian sus claves públicas a través de otro medio. Una vez obtenidas, conservan una copia de las claves públicas de aquellos con los que habitualmente se intercambian correos electrónicos.
La capa de implementación en la arquitectura de red para esquemas PGP y S / MIME se muestra en la siguiente imagen. Ambos esquemas proporcionan seguridad a nivel de aplicación para la comunicación por correo electrónico.
Uno de los esquemas, PGP o S / MIME, se utiliza según el entorno. Se puede proporcionar una comunicación segura por correo electrónico en una red cautiva adaptándose a PGP. Para la seguridad del correo electrónico a través de Internet, donde los correos se intercambian con nuevos usuarios desconocidos con mucha frecuencia, S / MIME se considera una buena opción.
Seguridad DNS
En el primer capítulo, mencionamos que un atacante puede utilizar el envenenamiento de caché de DNS para llevar a cabo un ataque al usuario objetivo. Domain Name System Security Extensions (DNSSEC) es un estándar de Internet que puede frustrar tales ataques.
Vulnerabilidad del DNS estándar
En un esquema DNS estándar, cada vez que el usuario desea conectarse a cualquier nombre de dominio, su computadora contacta con el servidor DNS y busca la dirección IP asociada para ese nombre de dominio. Una vez que se obtiene la dirección IP, la computadora se conecta a esa dirección IP.
En este esquema, no hay ningún proceso de verificación involucrado en absoluto. Una computadora le pide a su servidor DNS la dirección asociada con un sitio web, el servidor DNS responde con una dirección IP y su computadora sin duda la acepta como respuesta legítima y se conecta a ese sitio web.
Una búsqueda de DNS en realidad ocurre en varias etapas. Por ejemplo, cuando una computadora solicita "www.tutorialspoint.com", se realiza una búsqueda de DNS en varias etapas:
La computadora primero pregunta al servidor DNS local (proporcionado por el ISP). Si el ISP tiene este nombre en su caché, responde de lo contrario reenvía la consulta al "directorio de la zona raíz" donde puede encontrar ".com". y respuestas de la zona raíz.
Según la respuesta, la computadora pregunta al directorio ".com" donde puede encontrar "tutorialspoint.com".
Con base en la información recibida, la computadora consulta "tutorialspoint.com" donde puede encontrar www. tutorialspoint.com.
DNSSEC definido
La búsqueda de DNS, cuando se realiza mediante DNSSEC, implica la firma de respuestas por parte de la entidad que responde. DNSSEC se basa en criptografía de clave pública.
En el estándar DNSSEC, cada zona DNS tiene un par de claves pública / privada. Toda la información enviada por un servidor DNS está firmada con la clave privada de la zona de origen para garantizar la autenticidad. Los clientes de DNS necesitan conocer las claves públicas de la zona para verificar las firmas. Los clientes pueden estar preconfigurados con las claves públicas de todos los dominios de nivel superior o DNS raíz.
Con DNSSEC, el proceso de búsqueda es el siguiente:
Cuando su computadora va a preguntar a la zona raíz dónde puede encontrar .com, la respuesta está firmada por el servidor de la zona raíz.
La computadora verifica la clave de firma de la zona raíz y confirma que es la zona raíz legítima con información verdadera.
En la respuesta, la zona raíz proporciona la información sobre la clave de firma del servidor de zona .com y su ubicación, lo que permite que la computadora se comunique con el directorio .com y se asegure de que sea legítimo.
A continuación, el directorio .com proporciona la clave de firma y la información para tutorialspoint.com, lo que le permite ponerse en contacto con google.com y verificar que está conectado al tutorialspoint.com real, como lo confirman las zonas superiores.
La información enviada tiene la forma de Conjunto de registros de recursos (RRSets). El ejemplo de RRSet para el dominio "tutorialspoint.com" en el servidor ".com" de nivel superior se muestra en la siguiente tabla.
| Nombre de dominio | Tiempo para vivir | Tipo | Valor |
|---|---|---|---|
| tutorialspoint.com | 86400 | NS | dns.tutorialspoint.com |
| dns.tutorialspoint.com | 86400 | UN | 36..1.2.3 |
| tutorialspoint.com | 86400 | LLAVE | 3682793A7B73F731029CE2737D ... |
| tutorialspoint.com | 86400 | SIG | 86947503A8B848F5272E53930C ... |
El registro KEY es una clave pública de “tutorialspoint.com”.
El registro SIG es el hash firmado del servidor .com de nivel superior de los campos NS, A y KEY para verificar su autenticidad. Su valor es Kcom pvt (H (NS, A, KEY)).
Por lo tanto, se considera que cuando DNSSEC está completamente implementado, la computadora del usuario puede confirmar que las respuestas de DNS son legítimas y verdaderas, y evitar ataques de DNS lanzados a través del envenenamiento de la caché de DNS.
Resumen
El proceso de proteger los correos electrónicos garantiza la seguridad de un extremo a otro de la comunicación. Brinda servicios de seguridad de confidencialidad, autenticación de remitente, integridad de mensajes y no repudio.
Se han desarrollado dos esquemas para la seguridad del correo electrónico: PGP y S / MIME. Ambos esquemas utilizan criptografía de clave secreta y clave pública.
La búsqueda de DNS estándar es vulnerable a ataques como la suplantación de DNS / envenenamiento de caché. Asegurar la búsqueda de DNS es factible mediante el uso de DNSSEC, que emplea la criptografía de clave pública.
En este capítulo, analizamos los mecanismos utilizados en la capa de aplicación para proporcionar seguridad de red para la comunicación de un extremo a otro.