Una Autoridad de Certificación , antes de emitir un certificado a una entidad E , con el nombre de E y E en el certificado, se supone que verifica que la clave pública en cuestión realmente pertenece a E . Para el certificado del servidor SSL:
-
El nombre de E es un nombre de host , como
www.google.com
, posiblemente con un "comodín" ( *.google.com
). Esto es lo que clientes SSL verifican ; esto se trata de nombres , no de direcciones IP.
- La CA recibe la clave pública como solicitud de certificado .
Entonces, la noción de "identidad" vigente aquí es realmente una cuestión de propiedad del dominio. La CA desea asegurarse de que recibió la solicitud de alguien que controla el dominio. Hay varios métodos para eso; Los dos más utilizados son los siguientes:
- La CA envía un desafío por correo electrónico a la dirección de correo electrónico especificada para el dominio en la base de datos WHOIS .
- La CA desafía al solicitante con cierta información que se incluirá en el dominio, por ejemplo. un nombre de host aleatorio que se incluirá en el DNS.
Estas comprobaciones no son extremadamente sólidas (se basan en la "imposibilidad" de piratear, respectivamente, los correos electrónicos o el DNS, sin estar bien protegidos), por lo que existe una moda reciente para verificaciones más estrictas, denominada Certificados de validación extendida . Para un certificado EV, se supone que la CA debe hacer mucho más papeleo para asegurarse de que habla con la entidad correcta. Retrospectivamente, los certificados que no son EV se denominan "DV" (como "dominio validado").
El efecto neto de un certificado EV es que los navegadores web los reconocen como tales, y pueden mostrar ese hecho al usuario humano con una pantalla más lujosa, con mucho verde. Pero los certificados que no son EV técnicamente funcionan igual de bien. Solo vale la pena realizar un certificado de EV si los usuarios están capacitados para reconocer certificados de EV y se sienten más cómodos con un certificado de EV que con un certificado "normal" (que aún se muestra con el famoso icono de "candado"). En este momento, diría que la mayoría de los usuarios de Internet están lejos de ser conscientes de la distinción, por lo que comprar un certificado EV es un poco inútil.
(Los certificados EV serán útiles cuando se conviertan en obligatorios , es decir, cuando los navegadores web comiencen a rechazar o advertir sobre los certificados de servidor SSL que parecen ser válidos pero no están etiquetados como "EV". Esto es bastante difícil. transición y no veo que suceda en un futuro próximo.)
Para que un malo pueda obtener un certificado aparentemente válido con el nombre de servidor de su (el requisito previo para realizar un ataque de suplantación realmente exitoso), debe realizar una de las siguientes acciones:
-
Engaña a la CA. Engañar a la CA es más difícil para los certificados EV (ese es el punto). Sin embargo, incluso si usted obtiene un certificado EV, no evitará que el atacante obtenga un certificado no EV en su nombre de una CA crédula. Un certificado de EV lo protegerá contra una CA descuidada siempre y cuando sus clientes estén capacitados para pausar y sospechar si ven un certificado aparentemente válido pero no EV con el nombre de su sitio. Esto apenas parece realista en este momento.
-
Roba tu clave privada. Si un atacante roba su clave privada, entonces puede usarla con su certificado (que es público) para instalar su servidor falso. EV o no EV es irrelevante aquí; Lo que importa es que debes proteger bien tu clave privada. Si su servidor no funciona, informe a la CA para que pueda revocar su certificado y le emita otro (con una nueva clave).
-
Engaña al usuario humano para que ignore las advertencias muy rojas y aterradoras del navegador cuando se muestra un certificado no válido. No puedes realmente defenderte de eso, excepto educando a tus usuarios. Las advertencias mostradas por los navegadores web tienden a aumentar en la sensación de miedo (y enrojecimiento también) con el tiempo.
-
Engaña al usuario humano para que se conecte a un dominio propiedad del atacante con un certificado perfectamente válido, y un nombre que se vea como el nombre del servidor deseado. P.ej. www.gogle.com
o www.google.business.com
en lugar de www.google.com
(ejemplos ficticios). Una vez más, solo la educación del usuario puede realmente funcionar en contra de eso.
La mayoría de los ataques de phishing se basan en uno de los dos últimos métodos, por lo que esto significa que no debe preocuparse demasiado por la dicotomía DV / EV. El realmente punto importante para la seguridad es educación del usuario .