No soy criptógrafo. Tal vez es por eso que no veo los problemas con la integración de PGP en SMTP.
En mi cabeza: Lea solicita al servidor del dominio jedi.com de Luke que le diga la clave pública de [email protected] (la solicitud incluye un método de encriptación). Ella recupera la clave PUBLIC . Luego ella cifra el mensaje y Luke puede descifrarlo fácilmente.
No es tan difícil, ¿por qué no es estándar durante años?
No es tan difícil, ¿por qué no es estándar durante años?
Porque eso no habría resuelto el problema que PGP está tratando de resolver.
PGP es un cifrado de extremo a extremo, por lo que si el servidor SMTP tiene alguna forma de subvertir el cifrado, el esquema falla.
En el caso del esquema que propusiste, supongamos que Alice ([email protected]) desea enviar un mensaje privado a Bob ([email protected]). Usando el esquema que propuso, el cliente de correo de Alice o el servidor SMTP de Alice obtiene la clave pública de Bob al hacer una conexión TLS con dave.com. Esto está bien siempre y cuando dave.com sea honesto y en realidad devuelva la clave pública de Bob. Pero dave.com podría haber sido configurado por el operador de dave.com para devolver una clave pública falsificada creada por Eve, o Eve podría piratear en dave.com y configurar esto. Ahora, el cliente de correo de Alicia / servidor de correo aceptaría felizmente el certificado de Eve, pensando que la clave pública es la de Bob. En este modelo, el operador de dave.com puede interceptar cualquiera de los correos electrónicos de Bob.
Ahora, mientras dave.com sea honesto, esto todavía protege contra la falsificación de terceros. ¿Por qué no hacemos esto de todos modos si esto protege al menos contra el espionaje de terceros? Principalmente porque SMTPS también proporciona el mismo nivel de protección, al mismo tiempo que es mucho más simple. Si no le preocupa el MITM realizado por el operador del servidor de correo, ya puede proteger muy bien sus correos electrónicos asegurándose de que ambos utilicen SMTPS.
Tenga en cuenta que la dificultad del cifrado de extremo a extremo no se trata de obtener claves públicas. La mayoría de los clientes de correo electrónico que admiten PGP también admiten la obtención automática de claves públicas desde LDAP o HPKP. La dificultad del cifrado de extremo a extremo es verificar las claves públicas.
No se conoce ningún método para verificar las claves públicas que sea totalmente transparente para los usuarios y completamente seguro. El modelo de Web of Trust o Certificate Authority es el más cercano, pero Web of Trust tiene muchas advertencias y el modelo de Certificate Authority se basa en un tercero para realizar la verificación.
integración de PGP en SMTP.
PGP es un formato de contenedor para datos (como correos, pero no restringido a correos), que agrega cifrado y / o firma a los datos. SMTP es un protocolo de transporte.
No integras formatos de contenedor en protocolos de transporte. Esto sería lo mismo que decir que debe integrar Office (contenedor de texto, imágenes ...) con SMTP (transporte) para enviar un documento de Office a alguien.
PGP también se usa fuera de SMTP, porque es solo un contenedor. Y SMTP también se usa para transportar cosas diferentes de los contenedores PGP, porque es solo un protocolo de transporte.
Si, en cambio, pregunta sobre la integración del cifrado de extremo a extremo como PGP o S / MIME en SMTP, tampoco funcionará, ya que SMTP es una entrega salto a salto y no de extremo a extremo. Aparte de eso, SMTP ni siquiera cubre el último salto, es decir, la entrega del último servidor de correo al cliente. Esto se hace con protocolos como POP o IMAP.
Lea solicita al servidor del dominio de Luke jedi.com que le diga la clave pública de [email protected] ...
Para eso tiene servidores clave u otros tipos de directorios centrales. Pero, ¿cómo sabe Lea que esta es realmente la clave de Luke y no la clave de alguien que dice ser Luke? Por lo tanto, debe tener cierta propagación de confianza, por ejemplo, en forma de una red de confianza (PGP) o una estructura más centralizada (S / MIME) o confiando en todo en un directorio central específico.
Por lo tanto, la tarea no es integrar PGP con SMTP, sino contar con un mejor soporte para PGP en los clientes de correo, de modo que obtengan automáticamente las claves PGP de los destinatarios. Pero, por supuesto, primero debe haber una clave PGP verificable para el destinatario en algún lugar en un servidor de claves u otro directorio, por lo que la otra tarea es facilitar la creación, publicación y administración de claves (renovación, revocación ...) más fácil. Estas son todas cosas fuera de la entrega de correo (SMTP) en sí.
Escribir un estándar es fácil. Pensé en este mismo problema hace unos diez años. Se trata del factor humano / costo. ¿Cómo convencer a mil millones de personas analfabetas tecnológicamente para que actualicen su software sin beneficio percibido, y convencer a los miles de desarrolladores en una serie de plataformas para que implementen este protocolo, y a millones de organizaciones a cambiar a un nuevo protocolo, incluso si usted lo hace? > Regálalo . Ya hemos agotado nuestras direcciones IPv4 en algunas partes del mundo desde 2011 y, sin embargo, Internet todavía no utiliza IPv6 a nivel mundial. Ni siquiera podemos convencer a las personas para que cambien a IPv6 a pesar del hecho de que literalmente estamos reprimiendo el crecimiento de Internet. Incluso si pudiera eliminar un estándar hoy, y enviarlo a IETF para que se formalice y distribuya, sería 2030 antes de que fuera lo suficientemente amplio como para cerrar los innumerables servidores de correo "clásicos" que se ejecutan hoy.
El cifrado ya se implementó durante el tránsito de correo ( STARTTLS en SMTP), pero no es lo suficientemente sofisticado como para proteger contra MITM.
Creo que PGP es más una experiencia de usuario final entre clientes de correo electrónico, lo cual es útil si no tienes plena confianza en los servidores involucrados.
(PGP a veces es susceptible de MITM al usuario que no es cuidadoso, sin embargo, como en SSH, si comprueba la firma de la clave correcta, se solucionará el problema)
Sin embargo, en el caso de los servicios de correo electrónico basados en la nube como Gmail, tendrían que estar disponibles para el servidor de todos modos para una buena experiencia de usuario, por lo que PGP se interpondría en el camino.
Esperamos que algún día obtengamos un cifrado a prueba de MITM en SMTP, pero es un problema menor allí porque los servidores de correo están en redes controladas.
Bueno, como puede leer más arriba, puede usar SMTPS y STARTTLS para fortalecer la seguridad de los servidores SMTP mientras envía correos. MITM se puede mitigar con DKIM.
DomainKeys Identified Mail (DKIM) le permite a una organización tomar Responsabilidad por un mensaje que está en tránsito. La organizacion es un manejador del mensaje, ya sea como su creador o como un intermediario. Su reputación es la base para evaluar si confíe en el mensaje para su posterior manejo, como la entrega. Técnicamente DKIM proporciona un método para validar una identidad de nombre de dominio que es asociado a un mensaje a través de la autenticación criptográfica.
En resumen, DKIM le permite identificar si los correos provienen del origen del que dice el encabezado del correo. Cuando el servidor puede decidir de manera confiable si el mensaje es confiable (si falla la autenticación DKIM, puede dejar el correo y no preocuparse si un mensaje falsificado obtiene al servidor SMTP en una lista de correo basura).
Y ese tipo de rondas del círculo. Con la autenticación segura STARTTLS puede conectarse de manera confiable a un servidor SMTP y enviar su correo a un servidor de correo. DKIM puede identificar si un servidor SMTP determinado está autorizado para enviar correos desde una dirección determinada. TLS para la entrega de correo desde el servidor SMTP al servidor de correo para cifrar la conexión. Las STARTTLS entre el cliente de correo y el servidor de correo (a menos que sea un cliente de correo web, puede ser suficiente una conexión de socket segura a través de POP o IMAP)