Author Archives: Hacker Medic

Zertifikatstransparenz (Certificate Transparency, CT) ist eine Initiative von Google zur Protokollierung, Prüfung und Überwachung von Zertifikaten, die von Zertifizierungsstellen ausgestellt werden. Mit dieser Initiative soll verhindert werden, dass Zertifizierungsstellen ohne Wissen des Domäneninhabers Public-Key-Zertifikate (Zertifikate mit öffentlichem Schlüssel) für eine Domäne ausstellen. Zur Unterstützung von CT erfordert Google Chrome, dass alle Zertifizierungsstellen sämtliche SSL-Zertifikate mit Extended Validation (EV) in ein öffentlich prüfbares, nicht überschreibbares Verzeichnis eintragen, damit die grüne Adressleiste angezeigt wird. Nachfolgend finden Sie weitere Informationen zu dieser Änderung an SSL und dazu, wie Symantec seine Kunden bei dieser Umstellung unterstützen wird.

Erschwerung von Falschausstellungen

SSL-Zertifikate sind eine wichtige und zentrale Sicherheitskomponente in den Bereichen Online-Handel, Online-Banking und E-Mail. Ein SSL-Zertifikat hat zwei Hauptfunktionen:

1. Es ermöglicht die verschlüsselte Datenübertragung zwischen Browser und Website, damit niemand die Informationen mitlesen kann, die ausgetauscht werden.
2. Es stellt dem Benutzer vertrauenswürdige Identitätsangaben über die Website bereit.

Zertifizierungsstellen wie Symantec, die SSL-Zertifikate ausstellen, überprüfen diese Angaben in einem aufwendigen Verfahren. Dabei prüfen Sie sowohl die Angaben zum Unternehmen als auch seine Eigentumsrechte an der Website, bevor sie SSL-Zertifikate mit Unternehmensvalidierung (Organization Validation, OV) oder Extended Validation (EV) ausstellen. Allerdings sind nicht alle Zertifizierungsstellen gleich, weshalb es in der Vergangenheit vorgekommen ist, dass manche von ihnen unbefugten Antragstellern Zertifikate für bekannte Websites ausgestellt haben.

Die rechtzeitige Erkennung solcher Falschausstellungen ist bei der Verhinderung eines weiteren Missbrauchs betrügerisch erlangter Zertifikate sehr wichtig. Mit Certificate Transparency (CT) steht hierfür eine probate Methode zur Verfügung.

Funktionsweise von CT

CT beruht auf vier Säulen:

1. Zertifizierungsstellen,
2. Protokollierungsservern als öffentliches Repository für SSL-Zertifikate,
3. Auditoren (Webbrowser oder jeder Client, der ein SSL-Zertifikat akzeptiert) und
4. Überwachern.

Bevor eine teilnehmende Zertifizierungsstelle ein SSL-Zertifikat ausstellt, sendet sie sämtliche Informationen über dieses Zertifikat an mindestens einen Protokollierungsserver, der von der Zertifizierungsstelle und den Auditoren als vertrauenswürdig eingestuft wurde. Der Protokollierungsserver akzeptiert das Zertifikat und stellt der Zertifizierungsstelle eine kryptografisch gegen Manipulationen gesicherte eindeutige Verifizierung (Signed Certificate Timestamp, SCT) aus. Diesen Nachweis schließt die Zertifizierungsstelle bei der Ausstellung eines Zertifikats darin ein. Es gibt auch noch andere Möglichkeiten, diese Nachweise bereitzustellen. Darauf werden wir später in diesem Blog eingehen.

Das aktuelle TLS/SSL-System im Vergleich mit TLS/SSL mit CT

Wenn ein Browser eine SSL-geschützte Website aufruft, unterzieht er das SSL-Zertifikat zunächst verschiedenen branchendefinierten Prüfungen. CT sieht vor, dass Browser die Rolle eines Auditors übernehmen und auch die im Zertifikat enthaltenen SCT-Nachweise überprüfen. Die CT-Leitlinien geben Empfehlungen, wie viele Nachweise ein Zertifikat je nach Gültigkeitsdauer enthalten sollte. Ein Browser überprüft die SCT-Nachweise mithilfe der Protokollierungsserver, die von ihm als vertrauenswürdig eingestuft werden. Damit ein SCT-Nachweis als gültig akzeptiert wird, muss sich der öffentliche Schlüssel des ausstellenden Protokollierungsservers im CT Trust Store des Browsers befinden. Hierbei ist zu beachten, dass der Browser keine Echtzeitprüfung mit dem Protokollierungsserver vornimmt. Bis jetzt beabsichtigt nur Google Chrome die Unterstützung von CT. Die Rolle des Browsers bei CT besteht hauptsächlich darin, durchzusetzen, dass Zertifizierungsstellen veröffentlichen, welche Zertifikate sie ausstellen und den Zertifikaten Veröffentlichungsnachweise beifügen.

CT-Überwacher können von jedem entwickelt und implementiert werden, der regelmäßig Zertifikate prüfen will, die Protokollierungsservern neu hinzugefügt wurden. Hiermit wird bezweckt, dass durch die Überwachung der Protokollierungsserver für bestimmte Websites falsch ausgestellte Zertifikate erkannt werden können.

Außer durch die Einbettung in SSL-Zertifikate können SCT-Nachweise auch als TLS-Erweiterung oder per OCSP Stapling ausgeliefert werden. Für diese Verfahren müssen auf Webservern erweiterte Konfigurationen vorgenommen werden.

CT ist ein guter Ansatz dafür, sämtliche ausgestellten SSL-Zertifikate in mindestens einem öffentlichen Repository zur Verfügung zu stellen. Wenn eine Zertifizierungsstelle die von ihr ausgestellten SSL-Zertifikate nicht auf Protokollierungsservern veröffentlicht, können Browser entscheiden, wie sie mit einem solchen Zertifikat umgehen. Der ursprüngliche Vorschlag von Google sah vor, dass Chrome ab einem bestimmten Zeitpunkt im nächsten Frühjahr die Adressleiste im Browser für EV-Zertifikate ohne die erforderlichen CT-Nachweise nicht mehr grün anzeigt. Sicherlich könnte man, statt öffentliche Repositorys zu erstellen, auch sämtliche öffentlich zugänglichen Zertifikate überprüfen, um eine Falschausstellung zu erkennen. Allerdings wäre der Zeitaufwand hierfür wahrscheinlich wesentlich höher als für die Überprüfung der Veröffentlichungsnachweise, bevor ein Zertifikat akzeptiert wird. Daher besteht der inhärente Wert der CT in der Durchsetzung durch die Browser. Ohne einen großen und breit gefächerten Pool von CT-Auditoren wird CT nicht seinen vollen potenziellen Nutzen liefern. Außer Google Chrome hat bislang keiner der anderen großen Browser Pläne zur Unterstützung von CT veröffentlicht. Zudem müssten auch Desktop-Anwendungen, Mobilanwendungen und Webdienste, die Teil der SSL-Infrastruktur sind, an CT teilnehmen, damit sie wirklich effektiv wäre.

CT-Überwacher sind ein gutes Verfahren, mit dem sich falsche Ausstellungen deutlich schneller als mit einer Durchsuchung des gesamten Internets feststellen lassen. Allerdings hat nicht jeder Betreiber einer Website die erforderlichen Ressourcen, um solche Überwacher zu erstellen und auszuführen. Wahrscheinlich werden nur Großunternehmen solche Überwacher erstellen, um falsche Ausstellungen erkennen zu können.

CAA als Alternative?

Ein wichtiger Punkt ist, dass CT das Problem falsch ausgestellter Zertifikate nicht behebt, sondern nur die Erkennung solcher Zertifikate erleichtert. Es gibt andere Lösungen wie CAA, die das Problem auf andere Art und Weise angehen. Bei CAA gibt der Betreiber einer Website in den DNS-Einträgen an, welche Zertifizierungsstelle Zertifikate für seine Website ausstellen darf. Jede Zertifizierungsstelle, die CAA unterstützt, sollte vor der Ausstellung eines Zertifikats prüfen, ob eine solche Autorisierung vorliegt. Man kann dagegenhalten, dass dies nicht zwingend vorgeschrieben ist, aber wenn die Prüfung durch die Auditoren/Browser auf ähnliche Weise wie bei CT erfolgt, kann CAA die Ausstellung falscher Zertifikate effektiv verhindern.

Unterstützung von Symantec

Wenn Sie zu unseren Kunden zählen und bereits über EV SSL-Zertifikate verfügen, werden wir mit Ihnen Kontakt aufnehmen, um uns über Ihre Anforderungen bei der Datensicherheit interner EV SSL-Zertifikate zu informieren. Wir möchten sicherstellen, dass Ihre internen Daten intern bleiben und nicht in öffentlichen CT-Protokollen auftauchen. Externe EV SSL-Zertifikate werden bis Februar 2015 automatisch in den CT-Protokollen veröffentlicht, um sicherzustellen, dass die zugehörigen externen Websites in Chrome weiterhin mit einer grünen Adressleiste angezeigt werden. Bei zukünftigen EV SSL-Zertifikaten erfolgt die Veröffentlichung in den Protokollen optional. Wenn Sie hierüber mehr erfahren möchten, lesen Sie bitte den entsprechenden Artikel in unserer Online-Wissensdatenbank.

Bleiben Sie in Verbindung

Folgen sie uns auf Twitter oder Facebook, damit Sie über die neuesten Entwicklungen im Bereich Sicherheit und unsere neuesten Blog-Beiträge informiert werden. Besuchen Sie auch unser Support-Forum, um sich über Tipps und Kniffe zu informieren, mit denen Benutzer die gängigsten Probleme lösen können.

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.