Author Archives: Hacker Medic

Die nächste Änderung für SSL-Zertifikate

      No Comments on Die nächste Änderung für SSL-Zertifikate
The next change for SSL Certificates

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.

ctblog-2.jpg

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.

brooks.jpg

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.

Nouveau cap technologique pour les certificats SSL

The next change for SSL Certificates

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.

ctblog-2.jpg

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. 

brooks.jpg

 

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.

Hacked Snapchat accounts use native chat feature to spread diet pill spam

Compromised Snapchat accounts have sent out photo messages of a box of Garcinia Cambogia, followed by a chat message with a suspicious link containing ‘groupon.com’ in the URL.

Contas hackeadas do Snapchat usam recurso nativo de chat para disseminar spam de pílulas para emagrecimento

Compromised Snapchat accounts have sent out photo messages of a box of Garcinia Cambogia, followed by a chat message with a suspicious link containing ‘groupon.com’ in the URL.

Shellshock: Bash Bug ????????????????

      No Comments on Shellshock: Bash Bug ????????????????

新たに確認された脆弱性は、Linux、Unix、および Mac OS X の多くのバージョンに影響を与える可能性があるため、Web サーバーはリスクにさらされています。

Shellshock: Tudo que você precisa saber sobre a vulnerabilidade Bash Bug

Web servers at risk as new vulnerability potentially affects most versions of Linux and Unix, as well as Mac OS X.
Read more…

Shell Shock: Todo lo que debes saber sobre la vulnerabilidad Bash Bug

Se ha detectado una nueva vulnerabilidad que puede afectar potencialmente a casi todas las versiones de los sistemas operativos Linux y Unix, además del OS X de Mac (basado en torno a Unix). Se conoce como “Bash Bug” o “Shell Shock”.