¿Por qué los certificados de validación extendida no se usan con el correo electrónico?

Question

¿Por qué los certificados de validación extendida no se usan con el correo electrónico?

#1 de dave_thompson_085 (1 votos)
#2 de sebastian nielsen (0 votos)

1

Los certificados de validación extendida son certificados de identidad emitidos a una entidad legal. Esto significa que cualquier cosa firmada por ese certificado tiene "garantía" de que proviene de la entidad en lugar de solo del nombre de dominio.

Dado que los correos electrónicos de phishing son un gran problema y (al menos en mi opinión) parecen estar creciendo en prevalencia, ¿por qué las empresas no firman correos electrónicos con estos certificados (e incluyen la firma como un archivo adjunto)?

La infraestructura de confianza ya está (en su mayoría) en su lugar y los clientes de correo electrónico pueden manejar la verificación de forma bastante transparente mediante el sistema operativo o el almacén de certificados del navegador.

Me imagino que esto podría hacer que muchos de los correos electrónicos "INTRODUZCA BANCOS BANCARIOS EN 24 HORAS O CUENTA SEA ELIMINADO" y otros correos electrónicos de phishing mejor diseñados, en gran parte inútiles para los phishers.

certificates phishing email

pregunta 21.09.2017 - 17:09

fuente

2 respuestas

Lea otras preguntas en las etiquetas certificates phishing email

Acceso directo a las páginas de administración. El servidor web o el servidor de aplicaciones están configurados de manera insegura. La secuencia de comandos vbs maliciosa solo abre una conexión GET HTTPS

score 1 · Answer 1

De acuerdo con las Pautas EV (SSL) a partir de 1.6.5 (julio de 2017) de cabforum (advertencia: al igual que otros, ahora han "optimizado" su sitio web para mostrar la menor cantidad de datos posible, por lo que para encontrar algo útil tiene que arrastrarse por el menú desplegable) en la cláusula 1:

Esta versión de la Las directrices abordan solo los requisitos para los Certificados EV destinados a la autenticación SSL / TLS en Internet y para la firma del código. Los requisitos similares para S / MIME, sellado de tiempo, VoIP, IM, servicios web, etc. pueden estar cubiertos en futuras versiones

Aunque las pautas de EV no indican nada sobre ExtendedKeyUsage, y en los requisitos de línea de base (incorporados por referencia) 7.1.2.3f dice que DEBE contener clientAuth y / o serverAuth y PUEDE contener la protección del correo electrónico. Así que creo que un miembro de CA podría emitir un certificado EV que incluya un correo electrónico sin violar las reglas. OTOH Dudo que algún software de correo electrónico compruebe EV actualmente, incluso cuando admite X.509 (S / MIME), ya que no se espera.

Por supuesto que hay el problema habitual del huevo de gallina; los remitentes de correo electrónico legítimos no querrán usar esto hasta que al menos una fracción significativa de los destinatarios utilicen software o sistemas de correo electrónico que lo admitan, y al menos la mayoría de los destinatarios ni siquiera buscarán dicho soporte siempre que nadie lo envíe. Posiblemente si algunos grandes jugadores como gmail presionan esto, podría obtener algo de tracción, de la misma manera que algunos navegadores han estado impulsando mejoras en la criptografía web / HTTPS.

score 0 · Answer 2

Hoy ya existen métodos de verificación que pueden establecer una conexión segura entre un correo electrónico y su nombre de dominio de envío. Tres de ellos son SPF y DKIM, pero también S / MIME.

Dado que el sitio web y / o un servidor de correo, que residen en el mismo dominio, pueden contar con la certificación EV, significa que una vez que realice esa conexión, puede estar seguro de que La organización hizo la solicitud.

Lo único que falta es que el cliente de correo deba mostrar el resultado de la validación SPF / DKIM, y su nombre de dominio asociado, de alguna manera prometedora para el usuario.

Implementar EV para correos electrónicos solo agregaría complejidad, y también costos adicionales para las compañías.