Extended Validation Certificate (EV SSL): Cómo funciona técnica y socialmenteElevenPaths 21 agosto, 2013 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)
José Vicente Catalán Tú te vas de vacaciones, pero tu ciberseguridad no: 5 consejos para protegerte este verano Las vacaciones son una necesidad, está claro. Todo el mundo necesita relajarse, pasar tiempo de calidad con la familia y amigos, desconectar. Pero, irónicamente, para desconectar acabamos conectando (el...
Jennifer González Qué es la huella digital y por qué es importante conocerla para proteger a los menores en internet Como explicaba en mi anterior artículo sobre las cibervictimizaciones en los menores y el aumento que cada año se registra, hoy querría hablar sobre la importancia de concienciarnos sobre...
Telefónica Tech Boletín semanal de ciberseguridad, 16 — 22 de julio Lightning Framework: nuevo malware dirigido a entornos Linux El equipo de investigadores de Intezer ha publicado información relativa a un nuevo tipo de malware que afecta a entornos Linux y...
Telefónica Tech España necesita 83.000 profesionales en ciberseguridad en los próximos dos años Universidad Loyola y Telefónica Tech han puesto en marcha el nuevo Máster en Ciberseguridad para CISO
Roberto García Esteban Cloud computing: abierto por vacaciones Llegan las vacaciones de verano y con ellas el merecido descanso para casi todos nosotros. La actividad de la mayoría de las empresas se reduce drásticamente, aunque también hay...
Diego Samuel Espitia Qué son los “Martes de parches” de seguridad para tecnología operativa (OT) En el mundo de la ciberseguridad estamos acostumbrados a la publicación de paquetes que corrigen las vulnerabilidades detectadas en software para empresas, los conocidos como actualizaciones o «parches» de...