Tag Archives: encryption

Certificate Transparency (CT) est un projet Google de journalisation, d’audit et de surveillance des certificats émis par les autorités de certification (AC). Le but de cette initiative est d’empêcher les AC d’émettre des certificats à clés publiques à l’insu des propriétaires des domaines concernés. En ce sens, Google Chrome exige des autorités de certification qu’elles enregistrent tous leurs certificats SSL Extended Validation (EV) dans des registres vérifiables publiquement, condition indispensable à l’affichage de la barre d’adresse verte dans son navigateur. Ce billet fait le point sur l’implication d’un tel changement dans SSL, tout en détaillant le plan d’accompagnement des clients Symantec dans cette transition.

Prévention des émissions non autorisées

Composante indispensable des systèmes de sécurité en ligne, les certificats SSL protègent les opérations d’e-commerce, les transactions de banque en ligne, ou plus simplement les serveurs de messagerie électronique. Un certificat SSL remplit deux grandes fonctions :

1. Il crypte les échanges entre un navigateur client et un site Web pour prévenir toute lecture de ces informations par un tiers.
2. Il fournit aux internautes des informations fiables sur l’identité du site Web qu’ils visitent.

À l’image de Symantec, les autorités de certification (AC) émettrices de certificats SSL procèdent à une validation rigoureuse de ces informations d’identification. Pour ce faire, elles investissent des moyens conséquents dans la vérification de l’identité des entreprises et de leurs droits de propriété sur les sites Web à protéger. Ce n’est qu’au terme de cette procédure que des certificats OV (Organization Validation) ou EV (Extended Validation) sont délivrés. Toutefois, toutes les AC ne se valent pas, comme en témoignent certains cas récents de certificats émis pour des sites Web réputés à la demande de tiers non autorisés.

La détection rapide de ces émissions non autorisées joue un rôle crucial dans l’élimination de la fraude aux certificats. À cet égard, Certificate Transparency (CT) offre un mécanisme préventif viable. 

Fonctionnement de Certificate Transparency (CT)

CT repose sur quatre acteurs principaux :

1. Les AC
2. Les serveurs de journalisation – qui servent de référentiels publics des certificats SSL
3. Les auditeurs (navigateurs Web ou tout client qui accepte les certificats SSL)
4. Les contrôleurs

Avant d’émettre un certificat SSL, une AC envoie toutes les informations afférentes à un ou plusieurs serveurs de journalisation auxquels l’AC et les auditeurs font confiance. Le serveur de journalisation accepte le certificat et émet une vérification unique et cryptographiquement inviolable à l’attention de l’AC. C’est ce que l’on appelle l’horodatage de certificat signé – SCT. Ainsi, lorsque l’AC émet le certificat, elle y intègre cette/ces preuve(s). Il existe d’autres moyens de les obtenir, mais nous y reviendrons plus tard.

Système TLS/SSL actuel vs. TLS/SSL avec CT

Lorsqu’un navigateur se rend sur un site Web équipé d’un certificat SSL, il valide d’abord ce certificat sur la base d’une série de vérifications standard. Le projet CT propose que les navigateurs, qui jouent le rôle d’auditeurs dans son mécanisme, passent également en revue les preuves SCT incluses dans le certificat. CT fournit des indications quant au nombre de preuves qu’un certificat doit apporter en fonction de sa période de validité. Un navigateur vérifie donc les preuves SCT émises par les serveurs de journalisation de confiance. Pour être valide, une preuve SCT doit être émise par un serveur de journalisation dont le navigateur détient la clé publique, signe de sa fiabilité. Notons que dans ce cas, le navigateur n’effectue pas une vérification en temps réel auprès du serveur de journalisation. Aujourd’hui, seul Google Chrome prévoit d’appliquer le mécanisme CT. Le principal rôle du navigateur est d’inciter les AC à publier les certificats qu’elles comptent émettre et à y inclure une/des preuve(s) d’une telle publication.

Il est possible de développer et déployer des contrôleurs CT chargés de vérifier les certificats nouvellement ajoutés aux serveurs de journalisation. Cette surveillance a pour objectif de détecter toute émission non autorisée de certificat pour des sites Web particuliers.

Hormis leur intégration aux certificats SSL, les preuves SCT peuvent se présenter sous la forme d’extensions TLS ou d’« agrafages OCSP » (OCSP stapling). Ces méthodes nécessitent cependant une configuration avancée des serveurs Web.

CT constitue un bon moyen de rassembler tous les certificats SSL émis au sein d’un ou plusieurs référentiels publics. Si une AC décide de ne pas inscrire ses certificats SSL sur des serveurs de journalisation, libre aux navigateurs de leur faire confiance ou non. Dans la configuration CT initiale, prévue début 2015, le navigateur Google Chrome n’affichera plus la barre d’adresse verte pour les certificats EV n’intégrant pas les preuves SCT requises. D’aucun pourront rétorquer qu’au lieu de créer des référentiels publics, il est toujours possible d’examiner tous les certificats publiquement accessibles afin de détecter d’éventuelles émissions non autorisées. Toutefois, cette méthode prendra certainement plus de temps qu’une simple vérification des preuves de publication. Ainsi, la valeur intrinsèque de CT repose sur sa mise en application par le/les navigateur(s). En d’autres termes, en l’absence d’un vaste pool diversifié de contrôleurs CT, ce projet ne pourra pas tenir toutes ses promesses. Or, à l’heure de la rédaction de ce billet, Google Chrome est le seul grand navigateur s’engageant officiellement à prendre en charge CT. En outre, l’efficacité du système CT passe aussi par son intégration des applications PC/mobiles et des services Web présents dans l’écosystème SSL.

Étant donné qu’ils n’ont pas à passer tout le Web au crible, les contrôleurs CT sont appelés à détecter relativement plus rapidement les émissions non autorisées de certificats. Toutefois, tous les propriétaires de sites ne disposeront pas des ressources nécessaires au développement et à l’exécution de tels contrôleurs. Seules les grandes entreprises sont donc susceptibles d’en créer.

CAA, une alternative ?

En réalité, CT ne résout pas le problème des émissions non autorisées, mais facilite leur détection. D’autres solutions comme CAA (Certification Authority Authorization) recourent à des méthodes différentes pour réellement agir sur la prévention des émissions non autorisées. Dans CAA, un propriétaire de site Web spécifie dans les enregistrements DNS l’AC autorisée à émettre des certificats pour son site. Avant d’émettre un certificat, chaque AC participante doit donc vérifier qu’elle y est autorisée. Certes, ses détracteurs pourront toujours arguer qu’un tel système n’a rien de contraignant. Mais, si sa mise en application par les auditeurs/navigateurs suit un schéma similaire à celui de CT, alors CAA pourra lutter efficacement contre les émissions non autorisées de certificats.

Ce que Symantec peut faire pour vous

Nous envisageons de lancer une grande concertation avec tous nos clients SSL EV existants pour définir ensemble leurs exigences de confidentialité sur leurs certificats SSL EV internes. Ainsi, nous veillerons à ce que leurs données internes restent privées et n’apparaissent pas sur les registres CT publics. Quant aux certificats SSL EV externes, ils seront automatiquement publiés dans les registres CT d’ici février 2015, ce afin de maintenir l’affichage de la barre d’adresse verte dans Chrome. Enfin, la publication CT sera facultative sur les futurs certificats SSL EV. Pour en savoir plus, lisez l’article de notre base de connaissances sur le sujet.

Restez connecté

Pour ne rien manquer de l’actu sécurité et des derniers articles de nos blogs, suivez-nous sur Twitter ou sur Facebook. Pour des conseils et solutions aux problèmes utilisateurs les plus courants, rejoignez notre forum spécial support.

Certificate Transparency (CT), o transparencia de los certificados, es una iniciativa de Google que aspira a registrar, auditar y supervisar los certificados que emiten las autoridades de certificación. El objetivo es evitar que estas emitan certificados de clave pública para un dominio sin que lo sepa el propietario del mismo. Dado que Chrome se acogerá a esta iniciativa, dicho navegador solo seguirá mostrando la barra de direcciones verde propia de los certificados SSL con Extended Validation si la autoridad de certificación emisora los ha registrado previamente en un servidor público y auditable que solo permita anexar datos. A continuación, explicamos en qué consiste exactamente el cambio y qué ayuda prestará Symantec a sus clientes para que la transición sea lo más sencilla posible.

Medidas para asegurar que los certificados se emitan a quien corresponde

Los certificados SSL son esenciales para proteger a quienes compran por Internet, realizan operaciones de banca electrónica o, simplemente, consultan su correo electrónico. Estos certificados desempeñan dos funciones principales.

1. En primer lugar, cifran la información que se intercambia entre el sitio web y el navegador de quien lo visita, de forma que sea imposible interceptarla.
2. En segundo lugar, indican a los internautas a quién pertenece el sitio web, lo cual es igual de importante.   

Las autoridades de certificación que emiten certificados SSL con validación de empresa (OV) o con Extended Validation (EV), como es el caso de Symantec, siguen procedimientos de autenticación muy rigurosos. Sin embargo, no todas son iguales. Algunas han emitido certificados para sitios web destacados a personas no autorizadas que nunca deberían haberlos obtenido.

Si sucede algo así, es importante detectarlo a tiempo para evitar males mayores. La iniciativa Certificate Transparency (CT) tiene como objetivo facilitar este proceso.

La iniciativa CT, al detalle

Hay cuatro elementos que hacen posible esta iniciativa.

1. Las autoridades de certificación.
2. Los servidores de registro, que proporcionan un listado público de certificados SSL.
3. Los auditores (en este caso, navegadores web o clientes que aceptan certificados SSL).
4. Los llamados «monitores».

Una autoridad de certificación que desee cumplir los requisitos de la iniciativa CT deberá enviar toda la información relativa al certificado a uno o varios servidores de registro que tanto ella como los auditores consideren de confianza. El servidor aceptará el certificado y le facilitará una marca de verificación cifrada e imposible de manipular llamada SCT (Signed Certificate Timestamp). Al emitir el certificado, la autoridad de certificación deberá incluir al menos un elemento de prueba de este tipo, a no ser que se utilicen otros métodos, como los especificados en el apartado siguiente.

Diferencias entre el sistema TLS/SSL actual y el sistema TLS/SSL con CT

Cuando un navegador visita un sitio web protegido con tecnología SSL, realiza una serie de comprobaciones estándar para cerciorarse de que el certificado SSL sea válido. La iniciativa CT va más allá y convierte a los navegadores en «auditores» que comprueban si las SCT integradas en el certificado son válidas y si el número de elementos de prueba (que depende del periodo de validez del certificado) coincide con el estipulado en las directrices pertinentes. A la hora de validar las SCT, el navegador se basa en los servidores de registro que considera de confianza. Para dar las SCT por válidas, la clave pública del servidor de registro debe figurar en el listado de almacenes CT de confianza del navegador. Esto no significa que el navegador haga una comprobación en tiempo real en el servidor de registro: por ahora, solo Google Chrome tiene previsto incorporar la función CT, así que el papel principal del navegador es el de obligar a las autoridades de certificación a publicar los certificados que vayan a emitir e incorporar en ellos los elementos de prueba que lo demuestren.

Cualquiera podrá consultar los certificados que se han añadido hace poco a los servidores de registro. Basta con crear e implementar «monitores» que detecten si se han emitido certificados fraudulentos para determinados sitios web.

Los elementos de prueba SCT no solo pueden integrarse en los certificados SSL; también es posible «graparlos» a una respuesta OCSP o usar una extensión TLS, aunque estos métodos exigen conocimientos avanzados sobre configuración de servidores web.

 La iniciativa CT pretende dejar constancia de todos los certificados SSL emitidos en uno o más almacenes públicos. Si una autoridad de certificación decide no publicar los certificados SSL que emite en los servidores de registro, los navegadores podrán tenerlo en cuenta a la hora de decidir si los aceptan. A principios del año que viene, fecha prevista para la adopción inicial, Google Chrome dejará de mostrar la barra de direcciones verde si un certificado con EV no incluye las SCT que demuestren que está en los registros. Hay quien considera que, para detectar la emisión errónea de certificados, no es necesario crear almacenes públicos, sino que bastaría con pasar revista a todos los certificados accesibles públicamente. Sin embargo, esto llevaría mucho más tiempo que verificar las pruebas de publicación antes de aceptar un certificado. Por otro lado, la iniciativa CT solo funcionará si los navegadores son compatibles con ella; de lo contrario, la falta de «auditores de CT» y la escasa variedad de estos limitará su valor. Por ahora, de todos los navegadores más usados, solo Google Chrome tiene previsto adoptar este sistema. Además, existe otro problema: a menos que los servicios web y las aplicaciones para móviles y ordenadores se sumen a esta iniciativa, tampoco se logrará la eficacia deseada, pues dichos elementos también forman una parte esencial del entorno SSL.

Los «monitores de CT» permitirán detectar si se han emitido certificados por error sin necesidad de hacer un barrido completo de Internet, con el consiguiente ahorro de tiempo. Sin embargo, no todos los propietarios de un sitio web disponen de los recursos necesarios para crearlos y utilizarlos, así que es muy probable que solo las grandes empresas lo hagan.

CAA, una posible alternativa

La iniciativa CT no resuelve los errores relacionados con la emisión de certificados, pero sí facilita su detección. Hay otras soluciones, como el sistema CAA (Certification Authority Authorization), que utilizan mecanismos distintos para conseguir que solo se emitan certificados a quien corresponde. Con CAA, el propietario de un sitio web especifica en los registros DNS qué autoridad de certificación puede emitir certificados para su sitio web. Todas las autoridades de certificación que utilicen CAA deberían consultar esta información antes de emitir un nuevo certificado para comprobar si están autorizadas a hacerlo. Aunque respetar estos requisitos no es obligatorio, el sistema CAA podría ser igual de eficaz que la iniciativa CT si su aplicación se controlara mediante navegadores o auditores.

Apoyo a nuestros clientes

Symantec se pondrá en contacto con todos clientes que ya tengan certificados SSL con EV. En el caso de los certificados internos, les explicaremos cómo proteger los datos confidenciales para que no aparezcan en los registros de CT públicos. Los certificados SSL con EV externos se publicarán automáticamente en los registros de CT antes de febrero de 2015 para que, al acceder desde Chrome a los sitios web que protegen, siga viéndose la barra de direcciones verde. En adelante, los solicitantes de certificados SSL con EV podrán especificar si aceptan o no la publicación de sus certificados en los registros. Este artículo de nuestra base de conocimientos contiene más información al respecto.

Manténgase al día de las novedades

Síganos en Twitter o Facebook para estar al corriente de las últimas noticias sobre seguridad y de las nuevas entradas de nuestro blog. También le invitamos a pasarse por nuestro foro de asistencia, en el que encontrará consejos y soluciones a los problemas más frecuentes.

The next change for SSL Certificates

Certificate Transparency (CT) is a Google initiative to log, audit, and monitor certificates that Certificate Authorities (CAs) have issued.  CT’s intent is to prevent CAs from issuing public key certificates for a domain without the domain owner’s knowledge.  Chrome support for CT requires that all CAs log all Extended Validation (EV) SSL certificates in publicly auditable, append-only logs for the green address bar to appear in Chrome.  Read more to understand this change within SSL and how Symantec plans on supporting their customers through this transition. 

Impeding Mis-Issuance

SSL certificates are a critical and an integral part of online security when it comes to e-commerce, online banking, or simply checking your email.  An SSL certificate performs two main functions.

1. It enables encryption between client browser and the website so that no one else can interpret the information exchanged between the two.
2. Equally important, it provides trusted identity information about the website to the end user.   

Certification Authorities (CAs) that issue SSL certificates, like Symantec, rigorously validate this trusted information. CAs invest heavily in validating an organization’s information and ownership of the website before they issue Organization (OV) or Extended Validation (EV) certificates.  However, not all CAs are created equal and in the past some have issued certificates for prominent websites to unauthorized parties.

Detecting mis-issuance in a timely manner can be very important in mitigating further misuse of fraudulent certificates.  Certificate Transparency (CT) provides a viable mechanism to address this issue. 

How CT Works

There are four main participants in CT:

1. CAs,
2. Log servers that act as public repository of SSL certificates,
3. Auditors (web browsers or any client that accepts an SSL certificate), &
4. Monitors.

Before issuing an SSL certificate, a participating CA sends all information about that certificate to one or more log servers, which are trusted by the CA and auditors. The Log server accepts the certificate and issues a cryptographically tamperproof unique verification (Signed Certificate Timestamp – SCT) to the CA.  While issuing the certificate, the CA then includes such proof(s) inside the certificate. There are other ways to deliver these proofs but we will discuss them later in this blog.

The current TLS/SSL system vs. TLS/SSL with CT

When a browser visits an SSL enabled website, it first validates the SSL certificate against various industry defined checks.  CT proposes that browsers who perform an auditor’s role in CT should also check for the SCT proofs included with the certificate.  CT provides a guideline on how many proofs a certificate should have based on validity period of the certificate.  A browser checks the SCT proofs based on the log servers it trusts.  For a SCT proof to be valid, a browser must have the issuing log server’s public key in its CT trust store. It is important to note here that the browser does not make a real-time check with the log server. As of today only Google Chrome has planned to support CT. The browser’s role in CT is mainly to enforce that CAs publish certificates they are going to issue and include proof(s) of such publication.

CT monitors can be developed and deployed by anyone who wants to keep reviewing newly added certificates to log servers. The intention here is by monitoring log servers one can detect mis-issued certificates for specific websites.

Apart from embedding SCT proofs in SSL certificates they can be delivered as a TLS extension or via OCSP stapling. These methods require advance configurations on web servers.

CT is a good attempt to make available all issued SSL certificates in one or more public repositories. If a CA decides not to publish the issued SSL certificates to log servers then browsers can decide on how to treat that certificate. In its initial proposal, sometime early next year, Google’s Chrome browser will not be showing the “green browser bar” for EV certificates that do not include the required CT proofs with them. One can argue that instead of creating public repositories one can look at all publicly accessible certificates to detect mis-issuance. However, this may be more time consuming than just checking the proofs of publication before accepting a certificate. Thus the intrinsic value of CT is created by the enforcement of the browser(s). In the absence of a vast and diversified pool of CT auditors, it will not provide the full value it promises. At this time, except for Google Chrome, there are no published plans from any other major browsers to support CT.  Additionally, desktop applications, mobile applications, and web services that are part of SSL ecosystem need to participate in CT for it to be truly effective.

CT monitors will be a good mechanism to detect mis-issuance relatively quicker than crawling the entire web. However, not every website owner will have resources to build and run such monitors. Only big companies are likely to build such monitors to detect any mis-issuance.

CAA, an Alternative?

One important thing to note is CT does not solve the problem of mis-issuance but makes it easier to detect errant issuance.  There are other solutions like CAA, which focuses on preventing mis-issuance but in a different way.  In CAA, a website owner specifies in the DNS records which CA can issue certificates to its website.  Every CA that supports CAA is supposed to check for such authorization before issuing a certificate.  One can argue that this is not mandatory but if auditor/browser enforcement is designed similar to what is present in CT, then CAA can be effective in preventing mis-issuance.

Data Privacy Challenges

From a privacy angle CT poses a challenge.  If an authorized website owner for some reason does not want to publish its certificate details publicly then EV certificates may not work properly with browsers that enforce CT. Just think about a certificate issued for an internal website for a new product to a company that fiercely guards its new product information from being leaked, or a classified government project.  CT must include a way to respect and handle such privacy.

How Symantec Helps

For customers with existing EV SSL certs, we will be reaching out to understand your privacy requirements on internal EV SSL certificates.  We want to make sure that internal data remains internal and not be listed on public CT logs.  External EV SSL certificates will be automatically published on the CT logs before February 2015 to help ensure that the corresponding external sites continue to be highlighted with the green address bar on Chrome.  Future EV SSL certificates will come with an option to be published on the logs.  To learn more please visit our knowledge base article.

Stay in Touch

Follow us on Twitter or Facebook to be kept apprise of the latest in security news and our latest blogs.  Visit our support forum as well to get user hints and solutions to common user issues.