Extended Validation Certificate (EV SSL): Cómo funciona técnica y socialmente

Se supone que EV SSL es una «mejora» del uso de
certificados en conexiones TLS/SSL. Visto de otra forma, se trata de un intento de
enmendar algo que la propia industria de las CA (en combinación con los
navegadores) había roto, y es la
confianza en las comunicaciones cifradas. De paso, consiguieron hacer algo más
de caja.

En 2005, Melih Abdulhayoglu de Comodo fundó CA/Browser Forum,
con el objetivo de mejorar los estándares del SSL a través de sus dos actores principales: las autoridades certificadoras y los navegadores. Dos años después ya estaba
propuesta la primera versión del estándar Extended Validation Certificate (EVSSL). Por aquel entonces (e incluso ahora continúa esa inercia), se habían dado varias
circunstancias para que el SSL no estuviese ofreciendo todas las soluciones que
se esperaban de él.

Los navegadores (en aquel momento, Internet Explorer fundamentalmente) no
mostraban coherentemente que una conexión a una página estaba cifrada o autenticada. El fallo venía en parte del hecho
de que, en un intento de diversificar el negocio, las CA comercializaron certificados
automáticamente a un usuario solo por poseer un dominio, sin mayores comprobaciones.
Por otro lado, el navegador trataba (y mostraba) igual la seguridad de esta web que la de
otros certificados en los que se habían tomado mayores precauciones. Los
usuarios se hacían un lío. ¿Es seguro el candado o no? El famoso
«candado» podía aparecer en cualquier web por muchas razones, y terminó por no garantizar la seguridad del sitio, por no significar nada. Las advertencias por conexiones no cifradas también eran ridículamente «débiles» y poco informativas.

Comenzaba un verdadero boom de la banca online, y se
precisaba de una seguridad especial para estos casos tan potencialmente
peligrosos.

Así que pensaron que sería mejor «dar un salto» y
ofrecer certificados más caros, con mayores controles de comprobación de
identidad, y que se mostraran de otra forma en el navegador para
diferenciarlos del resto. En resumen, hacer por fin lo que debía haber
conseguido desde el principio el certificado TLS/SSL. Técnicamente, para ello se siguen varios pasos.

Comprobar la identidad

Las CA cobran más por este tipo de certificado, pero también realizan unas comprobaciones más exhaustivas sobre la empresa para saber si realmente es lícita y quien
dice ser. Llamadas por teléfono, documentación, etc.

Una extensión al certificado

Estos certificados cuentan con un valor especial en las extensiones que permite
la versión 3 del estándar X509. Las CA, a la hora de generarlos, pueden definir cualquier extensión que se añadirá al certificado y por supuesto, darles diferentes valores (en forma de OIDs). Si montásemos nuestra propia CA que emitiese certificados EV, en el caso de usar OpenSSL se añadiría lo siguiente en
openssl.cfg.

Parte de la configuración de OpenSSL para generar certificados EV, por ejemplo

Que resultará en un certificado con el campo Certificate
Policies, o «directivas de certificado» con el valor establecido como
sigue:

Certificado EV donde se muestra el valor que hace que un certificado sea «EV» para el navegador

El ejemplo propuesto son los valores reales que utiliza VeriSign.

El navegador lo interpreta

El navegador, en su código, comprueba el valor OID de ese
campo. Si coincide con los que tiene en su código, cambiará la forma de mostrar
la barra de direcciones, añadiendo ese color verde intenso que parece
«garantizar» mejor la comunicación.

Las CA no utilizan un mismo OID y
cada marca utiliza uno diferente. La lista «no oficial» de OIDs y fabricantes está en la Wikipedia. Por ejemplo, en el código fuente de Chromium
se puede observar claramente el valor del OID de VeriSign, XRamp Global CA….

Código de Chromium que valida certificados EV. Fuente: http://src.chromium.org/chrome/branches/250/src/net/base/ev_root_ca_metadata.cc

En resumen, EV SSL es un intento de volver «al
origen» de lo que siempre debió ser SSL, pero que se «corrompió». El estándar ha tenido un éxito aceptable, es reconocido y aceptado por la industria y los navegadores… pero ¿lo entiende el usuario?

Sergio de los Santos

ssantos@11paths.com

@ssantosv

Un ataque, 5 erroresCertificate pinning: el qué, el cómo y el porqué (I)