Category Archives: Website Security

Always-On SSL: mehr Sicherheit und bessere Positionen in Suchergebnissen für KMU-Websites

Hacker Medic August 18, 2014 No Comments

Websites using https boosted in google rankings

KMU gelten als die Stütze der Weltwirtschaft, in ihnen kommen Unternehmergeist, kühner Einfallsreichtum und unbedingte Kundenorientierung zusammen.

Kleine und mittlere Unternehmen (KMU) müssen auf dem virtuellen Weltmarkt mit Konkurrenten jeder Größe mithalten und sind daher immer auf der Suche nach Möglichkeiten, ihre Wettbewerbsfähigkeit zu steigern. Und da es im Internet nicht auf die Größe des Ladengeschäfts ankommt, haben sie hier besonders gute Chancen, Boden wettzumachen. Die digitale Welt bietet eine Vielzahl an Möglichkeiten: Web-Auftritte und soziale Medien, Suchmaschinenoptimierung und gezielte Anpassung an Mobilgeräte ermöglichen eine schnellere Vermarktung von Produkten. Im Internet können KMU auch bei einem kleinen Budget ihre Kunden beeindrucken und ihre Marke relevanter und bekannter machen – selbst im Wettbewerb mit Unternehmen, die über viel größere Budgets und eine stärkere Markenpräsenz verfügen.

Wie können KMU also in der digitalen Welt wettbewerbsfähig und beweglich bleiben, ohne Kompromisse bei der Datensicherheit einzugehen oder arm zu werden? Die Antwort lautet: „Always-On SSL“ von Symantec, auch bekannt als „HTTPS everywhere“. Dieses Verfahren ist ideal für KMU mit Online-Präsenz und wird auch von namhaften Unternehmen wie Google, PayPal, Facebook, Twitter und Microsoft unterstützt. Wie diese leistungsstarke SSL-Variante Daten während der Übertragung schützt und dazu noch Ihre Position in Suchergebnissen verbessert, erfahren Sie, wenn Sie weiterlesen.

Laden Sie gleich die Infografik herunter!

Die Rundum-sorglos-Variante von SSL: Das „S“ macht den Unterschied.

Würden Sie die Haustür abschließen, aber die Hintertür weit offen lassen? Dieses Bild beschreibt die Situation, wenn Websites herkömmliches HTTP-SSL, das sogenannte „Intermittierende SSL“, nur zum Schutz einiger bestimmter Seiten einsetzen, meist der Anmelde- und der Bezahlseite. Manche Unternehmen meinen, zum Schutz vor Datendiebstahl und Hackern genüge es, SSL nur in ein oder zwei Bereichen ihrer Website zu implementieren, intermittierend also. Sie übersehen jedoch, dass der Rest der Website damit vollkommen offen und ungeschützt gegenüber Angriffen wie Sidejacking ist.

Wie können Sie jede einzelne Seite Ihrer Website schützen und die Sicherheit Ihrer Kunden gewährleisten? Mit Always-On SSL von Symantec.

„Always-On SSL“: vertrauenswürdige Sicherheit zu jedem Zeitpunkt

Als Mitglied der Online Trust Alliance und des CA/B Forums hat sich Symantec schon immer für Always-On SSL ausgesprochen, denn damit ist jede einzelne Seite einer Website durch ein SSL-Zertifikat geschützt (zu erkennen am Adressbestandteil HTTPS://) nicht nur die Seiten zur Anmeldung und zum Durchführen von Transaktionen. Nur mit dem Umstieg von einer http-Website zu einer durchgängig gesicherten https-Website wird wirklich jede Interaktion mit den Seiten Ihrer Website vom ersten bis zum letzten Klick verschlüsselt. Wenn nur Anmelde- und Transaktionsseiten geschützt sind, ist es Hackern weiterhin möglich, Sitzungscookies eines Benutzers zu stehlen. Mit diesen Cookies können sie die Website-Sitzung nachstellen und Zugriff auf alle vertraulichen Daten erlangen – immer und immer wieder. Angriffe durch Sidejacking (mit Firesheep) und SSLStrip sind bei solchen nur begrenzt geschützten Websites besonders häufig. Letztlich konterkarieren ungeschützte Seiten und die dazugehörigen Cookies alle Bemühungen und Aufwendungen, um die Anmelde- und Transaktionsseiten durch intermittierendes SSL zu schützen.

SSL secure sites get ranking boost

Die finanziellen Konsequenzen von Sicherheitslücken

Der Wert eines lückenlosen Schutzes lässt sich in Zahlen ausdrücken: 2012 kam es weltweit zu mehr als 100 000 Datenschutzverstößen, 35 000 davon alleine in den USA. Die betroffenen US-Unternehmen mussten 5,4 Millionen US-Dollar ausgeben, um die Ursachen zu finden. Dieser Betrag enthält direkte Kosten, etwa Honorare von Fachleuten für forensische Analysen oder Hotline-Support von Services zur Bankkontoüberwachung, aber auch indirekte Kosten, zum Beispiel für interne Untersuchungen, Öffentlichkeitsarbeit und durch verlorene Kunden.* Die meisten dieser Datenschutzverstöße wurden durch Angriffe von Hackern oder Kriminellen verursacht und mit Always-On SSL wäre es möglich gewesen, ihre Zahl zu senken, sie abzuwehren oder ihnen vorzubeugen.

* Studie 2013 zu den Kosten von Datenschutzverletzungen: Weltweite Analyse, Ponemon Institute

Google bevorzugt Websites mit Always-On SSL oder HTTPS – das sollten Sie auch tun

Eine gewichtige Aufwertung erfuhr Always-On SSL, speziell die lückenlose Verschlüsselung mit HTTPS, am 6. August 2014 durch einen Artikel im Google-Blog zur Online-Sicherheit. Das Unternehmen plant, Websites mit vollständiger HTTPS-Verschlüsselung beim Ranking der Suchergebnisse zu bevorzugen. Der Grund dafür ist eigentlich ganz simpel, wie Zineb Ait Bahajji und Gary Illyes, Trendanalysten für Google-Webmaster, erläutern: „Wir möchten allen Website-Betreibern ans Herz legen, von HTTP auf HTTPS umzusteigen, damit alle Nutzer sicher im Internet unterwegs sein können. In diesem Zusammenhang ist es uns wichtig, dass die Websites, die die Menschen über Google aufrufen, sicher sind.“ Klarer kann man das nicht ausdrücken: „Hoffentlich gibt es bald mehr Websites mit HTTPS.“ Es geht also darum, den Selbstschutz der Website-Betreiber zu fördern und damit auch den Datenaustausch im gesamten Internet. Die Präsentation von Google zu Bedeutung und Vorteilen von HTTPS können Sie hier aufrufen.

HTTPS als Wettbewerbsvorteil für kleine und mittlere Unternehmen

Der HTTPS-Schutz ihrer Website kann für KMU einen Wettbewerbsvorteil im Online-Markt bedeuten:

• Bessere Markenposition in Suchergebnissen – besonders im Vergleich zu Großunternehmen, die noch ohne HTTPS arbeiten. Mit HTTPS können KMU mindestens gleichziehen mit ihren großen Konkurrenten.

• Die besseren Suchergebnisse können sie mit Seal-in-Search™ von Symantec noch weiter aufwerten: Wenn das Norton™ Secured-Siegel in den Suchergebnissen angezeigt wird, erhalten Sie noch mehr Klicks. Schließlich ist es die bekannteste Vertrauensmarke im Internet.

• Ihr klare Stellungnahme für Online-Sicherheit wirkt sich positiv auf Ihren Ruf und Ihre Marke aus.

• Sie erzielen mehr Transaktionen und höhere Abschlussraten.

• Sie schützen Ihre Kunden und deren Daten während des gesamten Besuchs, nicht nur bei Anmeldung und Kauf.

• Mit Extended Validation ist Ihre Vertrauenswürdigkeit optimal sichtbar.

Zu Symantec gehören mehrere Marken, die unterschiedliche Lösungen anbieten, sodass wir für jeden Fall eine bewährte Lösung parat haben. Wählen Sie also die „Always-On SSL“-Lösung, die Ihre Anforderungen am besten erfüllt: vom einfachen SSL-Zertifikat über Platzhalter- und SAN-Zertifikate bis hin zu Zertifikaten mit Extended Validation – die mit den grünen Hervorhebungen in der Adressleiste. Jedes unserer Zertifikate gewährleistet die stärkste Verschlüsselung und damit den Schutz aller übertragenen Daten, seien es personenbezogene Daten, Cookies oder Kontodaten.

Always-On SSL: nicht neu, aber aktueller denn je

Branchengrößen wie Microsoft, PayPal, Facebook und Twitter befürworten Always-On SSL schon seit Jahren. Ebenso wie Symantec sind diese Unternehmen Teil der Online Trust Alliance (OTA), die es sich zum Ziel gesetzt hat, Online-Vertrauen und Benutzersicherheit zu fördern, Innovationen einzuführen und die Robustheit des Internets zu stärken. „Wir alle müssen gemeinsam darauf hinarbeiten, dass für die Internetsicherheit Best Practices gelten, um die Nutzer zu schützen“, formuliert die OTA in diesem Whitepaper. „Die allgemeine Online-Sicherheit steht derzeit auf der Kippe, daher sind an Websites Änderungen erforderlich, die die lückenlose Sicherheit und damit das Vertrauen der Kunden weiterhin gewährleisten.“ Einer der bedeutendsten Vorteile von Always-On SSL liegt in dem Vertrauen, das man bei den Kunden schafft.

Wie können Sie eine Website lückenlos schützen?

Mit den folgenden Maßnahmen sorgen Sie dafür, dass Ihre Website durchgängig mit HTTPS geschützt ist:

1. Dauerhaftes HTTPS auf jeder Webseite erzwingen

Sie schützen die personenbezogenen Daten, Identitäten und Cookies Ihrer Kunden, wenn Sie auf jeder Seite der Website HTTPS aktiviert haben. Mehr erfahren Sie hier.

2. Korrekte Implementierung von SSL-Zertifikaten

Um HTTPS zu nutzen, benötigen Sie ein gültiges SSL-/TLS-Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle wie Symantec. Damit signalisieren Sie Ihren Benutzern, dass die Identität der Website-Inhaber von einer vertrauenswürdigen Organisation überprüft und bestätigt wurde. Mehr erfahren Sie hier.

3. Verwendung des Attributs „sicher“ für alle Sitzungscookies

Ein Sitzungscookie kann das optionale Attribut „sicher“ („secure“) erhalten, das dafür sorgt, dass der Browser diesen Cookie nur über eine HTTPS-Verbindung an den Webserver zurücksendet. Damit ermöglichen Sie gleichzeitig auch zuverlässige Nutzungsauswertungen.

4. Zertifikate mit Extended Validation stärken Sicherheit und Vertrauen

Wenn Sie Ihren Kunden die Vertrauenswürdigkeit und die Sicherheit Ihrer Website deutlich zeigen möchten, entscheiden Sie sich für ein SSL-Zertifikat mit Extended Validation (EV) von Symantec. Damit wird ein Teil der Adressleiste grün dargestellt und der Name des Zertifikatsinhabers ist auf einen Blick sichtbar. Das schafft Vertrauen und Ihre Kunden sehen sofort, dass sie auf Ihrer Website sicher sind.

Weitere Informationen finden Sie in den folgenden Artikeln:

Google Rewards Secure Websites with Higher Search Ranking (Blog)

Google smiles on safer connections (auf Internet Retailer, 8. August 2014)

Understanding Always On SSL and SEO (Symantec | Connect Januar 2014)

Types of SSL certificates – choose the right one

Hacker Medic August 11, 2014 No Comments

Introduction

From the server administrators of highly technological organizations, to product managers of financial institutions, down to the one man startup companies that just want to secure their shopping cart, at one stage or another, the same question pops-up: “They all do the same thing, what should we get?”

Fundamentally all SSL certificates do the same thing, encrypt information during SSL/TLS negotiations. Correctly installed and configured, both https:// and the padlock will show.

However picture this:

You want to buy smart phone online. You see three sellers offering the phone at different prices:

US$250 – Zero star rating – no comments

US$375 – Three star rating – with 50% of comments such as “it arrived late”, “It was scratched” and other 50% of the comments, “ok service” and “arrived on time”.

US$400 – Five star rating – with only good comments: “excellent service” and “fast and reliable”.

Which seller will be most likely to deliver the goods to you on time? The one offering $400?

Why? The comments from previous buyers formed a conscious or sub-conscious decision in your mind. The decision is based on “Trust”. They have been authenticated by real people.

Anyone that purchased from the first two sellers most likely would base their decision on both price and luck (“Maybe I would not be unlucky”).

Here’s another scenario: A hooded man walks out from a dark alley and offer you a brand new IPhone 6, still in its box for US $50.

Do you feel lucky today?

Apache Struts 1 & 2 の脆弱性(S2-020、CVE-2014-0114等)

Hacker Medic June 12, 2014 No Comments

2014年4月に新たに見つかったApache Strutsの脆弱性(S2-020、CVE-2014-0114等)

このブログではウェブサイトやその上で動作しているウェブアプリケーションの脆弱性について紹介すると共に注意喚起をする目的でまとめられています。
今回は、2014年4月に発見されたApache Strutsの脆弱性について解説をしています。

Perfect Forward Secrecy

Hacker Medic May 8, 2014 No Comments

Recent revelations from Edward Snowden about pervasive government surveillance have led to many questions about the safety of communications using the SSL/TLS protocol. Such communications are generally safe from eavesdroppers, as long as certain precautions are observed. For example, configuring your web server to avoid using SSL2 and SSL3, favoring newer versions of TLS like TLS 1.2, selecting strong ciphersuites, etc.

But even if your server is configured properly, you still must secure the private key associated with your SSL certificate. In nearly all cases, the web site owner generates their key pair and sends only the public key to their Certification Authority (CA). The CA (and any eavesdropper) sees only the public key, and the private key cannot be derived from that. So the CA cannot reveal a web site owner’s private key to the government or an attacker, even if coerced to do so.

After your SSL certificate has expired and been replaced with a new key pair and certificate, it’s still important to secure or destroy the old private key, because attackers have the ability to save old SSL-protected traffic. In many cases, an attacker with a private key and saved SSL traffic can use the private key to decrypt all session keys negotiated during saved SSL handshakes, and then decrypt all saved session data using those session keys.

But not if the web server and its clients agree to use a key agreement protocol that offers support for Perfect Forward Secrecy (PFS). First let’s look at how things work without PFS. The client generates a random number and sends it to the server, encrypted it with the public key of the server. Only the server can decrypt it, so now both sides have the same random number. They use a key generation algorithm to derive the session key from that random number. But an attacker who knows the server’s private key can also decrypt the random number, apply the same key generation algorithm, and arrive at the same session key. The attacker can then decrypt any saved SSL session data.

Using PFS, there is no link between the server’s private key and each session key. If both client and server support PFS, they use a variant of a protocol named Diffie-Hellman (after its inventors), in which both sides securely exchange random numbers and arrive at the same shared secret. It’s a clever algorithm that prevents an eavesdropper from deriving the same secret, even if the eavesdropper can view all the traffic. See this Wikipedia article for a clear explanation of how this works, and this blog post for a more detailed technical explanation. Note that if the ephemeral variant of Diffie-Hellman is used, no part of the exchange is encrypted with the web server’s private key. That means that an attacker who obtains the private key cannot decrypt any saved sessions that were established using PFS.

The variants of Diffie-Hellman are known as Diffie-Hellman Ephemeral (DHE) and Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). You’ll see those terms within the names of TLS ciphersuites that can be configured for use in your web server. For example, Ivan Ristić of SSL Labs recommends the following:

TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

Please note that there are more options available which may have to be used as the industry moves to ECC certificates, TLS 1.2 and GCM suites. Also note that you may see ciphersuites with DH (not DHE) and ECDH (not ECDHE) in their names – these are variants of Diffie-Hellman that do not exhibit the Perfect Forward Secrecy property. Only DHE and ECDHE support PFS at this time.

Ristić also provides information on how to configure PFS support on Apache, Nginx and OpenSSL. If you want to see if your server supports PFS, test it at the CA Security Council’s SSL Configuration Checker.

Do the browsers support PFS? Yes they do. At this time, Chrome, Firefox, IE, Opera and Safari all support PFS when using ECDHE cipher suites with RSA and ECC SSL certificates. All browsers except IE also support DHE with RSA certificates. You can also test your browser to see if it supports PFS. If your web site needs to support older browsers that may not support PFS, you’ll have to configure your web server to also offer non-PFS suites. But list PFS suites first in order of preference.

PFS is a mature technology that is built in to nearly all major browsers and web servers. It’s available for use in securing your SSL traffic both now and in the future.

Tags: Perfect Forward Secrecy, PFS, SSL, SSL Labs

This blog was originally posted at https://casecurity.org/2014/04/11/perfect-forward-secrecy/ Authors Rick Andrews and Bruce Morton

Brauchen Sie eine eigene private Zertifizierungsstelle?

Hacker Medic May 8, 2014 No Comments

Haben Sie in Ihrem Intranet Domänennamen wie https://intranet.local oder einen Mailserver mit einer Adresse wie https://mail? Viele Unternehmen und Organisationen nutzen solche Domänennamen intern, doch das wird nun problematisch.

SSL-Zertifikate für Intranets

Symantec und die anderen im CA/Browser-Forum zusammengeschlossenen Zertifizierungsstellen (CA) und Browseranbieter haben beschlossen, keine SSL-Zertifikate mehr auszustellen, deren Root-Zertifikat nicht im öffentlich zugänglichen Internet überprüft werden kann.

Das heißt, dass Domänennamen nun weltweit eindeutig sein müssen und nicht nur innerhalb Ihres Intranets. Wenn Sie also beispielsweise eine Domäne mit der Endung .local haben, die Sie intern nutzen, werden Sie dafür bald kein von einer CA ausgestelltes SSL-Zertifikat mehr kaufen können.

Mit der Vergabe neuer gTLDs wie .berlin steigt die Wahrscheinlichkeit, dass weit verbreitete intern genutzte Domänenendungen von Unternehmen gekauft und im öffentlich zugänglichen Internet genutzt werden. Endungen wie .home und .pics wurden bereits beantragt und Anträge für weitere Endungen werden sicher folgen. In Zukunft können nur die Eigentümer dieser gTLDs bei CAs SSL-Zertifikate für sie kaufen.

Dadurch wird die Sicherheit im Internet insgesamt verbessert, doch Unternehmen und Organisationen, die diese neuen gTLDs oder reservierte IP-Adressen für interne Server nutzen, müssen sich nun umstellen.

So bereiten Sie sich auf die Umstellung vor

Wenn Sie in dieser Situation sind, haben Sie drei Möglichkeiten: Sie können die internen Domänennamen durch vollständig qualifizierte Domänennamen ersetzen, selbstsignierte Zertifikate nutzen oder eine private Zertifizierungsstelle (CA) einrichten, um Ihre intern genutzten Domänen zu authentisieren.

Für viele Unternehmen bietet sich die letztgenannte Option an, denn eine private Zertifizierungsstelle erfordert die wenigsten Änderungen an vorhandenen Systemen und ist mit dem geringsten Risiko verbunden.

Das Angebot von Symantec

Vor Kurzem stellte Symantec seine Lösung Private Certification Authority vor. Damit können Sie sowohl die Risiken und versteckten Kosten selbstsignierter Zertifikate als auch die Kosten einer Umstellung Ihres gesamten Intranets auf vollständig qualifizierte Domänennamen vermeiden.

Die Lösung beruht auf der robusten Infrastruktur von Symantec und ist für ein breites Anforderungsspektrum geeignet, vom Ausstellen von SSL-Zertifikaten für einzelne, in Intranets genutzte Domänen über Wildcard-Zertifikate bis hin zu selbstsignierten Zertifizierungsstellen. Zudem stellt sie eine gehostete private SSL-Zertifikatshierarchie mit speziell auf den Schutz des unternehmensinternen Datenaustauschs zugeschnittenen Endzertifikaten bereit.

Die Konsole von Managed PKI for SSL erleichtert Ihnen das Zertifikatsmanagement, denn sie ermöglicht die Verwaltung öffentlicher und privater Zertifikate an einer zentralen Stelle. So können Sie die mit dem unbemerkten Ablauf von Zertifikaten verbundenen Risiken vermeiden und rechtzeitig neue Zertifikate ausstellen. Doch unabhängig davon, für welche Lösung Sie sich entscheiden, gilt vor allem eins: Die Umstellung sollte so bald wie möglich erfolgen.

¿Necesita su propia autoridad de certificados?

Hacker Medic May 8, 2014 No Comments

¿Tiene alguna intranet cuyo nombre se parezca a https://intranet.local o algún servidor de correo electrónico con una dirección que comience por https://mail? Estos nombres de dominio de uso interno son muy frecuentes, pero ahora plantean un grave problema.

Certificados SSL para intranet

Symantec, junto con las demás autoridades de certificación y proveedores de navegadores que conforman el CA/Browser Forum, ha decidido dejar de emitir certificados SSL cuya cadena incluya una raíz pública a la que solo se puede acceder desde la red interna de la empresa.

Esto significa que los nombres de dominio tienen que ser únicos en el mundo, no solo en su red. Por lo tanto, si utiliza un dominio .local de forma interna, dentro de poco ya no podrá comprar certificados SSL validados para ese nombre.

Debido a la aparición de nuevos gTLD, como .london, y a la posibilidad de que empresas comerciales adquieran y usen muchos de los nombres que más se suelen utilizar para designar de forma interna a los dominios de servidor (por ejemplo, ya hay solicitudes para .red y .home, aunque seguro que les seguirán muchos más nombres), será imposible que compre un certificado SSL validado para estos gTLD a menos que le pertenezcan.

Si bien se trata de una medida que mejorará la seguridad, genera ciertos desafíos para aquellas empresas cuyos servidores utilizan estos nombres de dominio para uso interno o para direcciones IP reservadas.

Preparativos para el cambio

Entre las alternativas disponibles, se encuentra el cambio a nombres de dominio completos, el uso de certificados autofirmados o la creación de una autoridad de certificación privada para autenticar los nombres de dominio internos.

Para muchas empresas, esta última opción es una magnífica estrategia de preparación para el cambio, ya que es la alternativa que supone menos cambios en los sistemas existentes y la que conlleva menos riesgos.

La propuesta de Symantec

Para crear autoridades de certificación privadas, Symantec ha lanzado la solución Private Certification Authority. Gracias a este producto, evitará los riesgos y los costes ocultos de los certificados autofirmados, así como el gasto que supone cambiar toda la intranet para que utilice nombres de dominio completos.

Al utilizar la infraestructura blindada de Symantec, cumple todos los requisitos de los certificados SSL para intranet de un solo dominio, de los certificados comodín y de las autoridades de certificación autofirmadas. Además, ofrece una jerarquía de certificados SSL privada y alojada con certificados de entidad final creados específicamente para proteger las comunicaciones internas.

La consola Managed PKI for SSL contribuye a simplificar la administración de los certificados SSL, ya que le permite gestionar certificados públicos y privados desde un mismo panel de control. Gracias a esto, se reduce el riesgo de que los certificados caduquen de forma imprevista y se pueden emitir nuevos certificados conforme se necesitan.

Si su empresa dispone de servidores internos que utilizan nombres de dominio en desuso, tendrá que hacer algo al respecto más pronto que tarde.

Avez-vous besoin de votre propre autorité de certification privée ?

Hacker Medic May 8, 2014 No Comments

Vous possédez un site intranet dont le nom de domaine ressemblerait à https://intranet.local ? Ou un serveur de messagerie avec une adresse de type https://mail ? Certes très répandus, ces noms de domaines internes posent néanmoins un réel problème.

Certificats SSL pour intranet

Symantec s’est associé aux autres membres du CA/Browser Forum (autorités de certification et éditeurs de navigateurs Web) pour décider de stopper l’émission de certificats SSL rattachés à une racine publique ne pouvant être vérifiée dans un contexte d’Internet public.

En conséquence, l’unicité des noms de domaines ne doit plus seulement s’appliquer au niveau local (votre réseau), mais aussi au niveau mondial. En clair, si vous utilisez un domaine .local en interne, vous ne serez bientôt plus en mesure d’acheter des certificats SSL validant ce nom de domaine.

On assiste actuellement à l’émergence de nouveaux domaines génériques de premier niveau (gTLD) de type .london et autres, dans le sillage desquels de nombreux noms devraient suivre – les noms .red et .home sont d’ores et déjà en phase d’homologation. Par conséquent, il est fort probable que la plupart des noms communs utilisés pour identifier les domaines de serveurs en interne finiront par être exploités par des plates-formes commerciales. En clair, à moins que vous ne soyez propriétaire de ces gTLD, vous ne pourrez plus acheter de certificat SSL pour la validation de ces domaines.

Malgré les avantages de ce changement en termes de sécurité, il n’en pose pas moins un véritable enjeu pour les entreprises exploitant des noms de domaines internes ou des adresses IP réservées.

Comment se préparer

Face au changement à venir, les entreprises disposent de plusieurs options pour authentifier leurs noms de domaines internes : passage à des noms de domaines entièrement qualifiés, utilisation de certificats auto-signés ou mise en place d’une autorité de certification (AC) privée.

Pour de nombreuses entreprises, la mise en place d’une AC privée représente la meilleure solution car elle est la moins risquée et ne demande qu’un minimum de changements sur les systèmes existants.

La solution Symantec

Récemment annoncée par Symantec, la solution Private Certification Authority permet aux entreprises d’éliminer les risques et coûts cachés des certificats auto-signés, ainsi que les coûts associés au déploiement de noms de domaine Internet complets sur leur intranet.

Grâce à l’infrastructure ultra-sécurisée de Symantec, Private Certification Authority répond à n’importe quelle exigence : des certificats SSL intranet mono-domaines aux autorités de certification auto-signée, en passant par les formules Wildcard. Cette solution hébergée offre une hiérarchie SSL privée avec des certificats pour entités finales spécialement conçus pour sécuriser les communications internes.

Côté gestion, Symantec Private Certification Authority vous permet de consolider tous vos certificats SSL privés et publics au sein de la console Managed PKI for SSL. Résultat : vous éliminez les risques d’expiration inopinée de certificats et pouvez émettre de nouveaux certificats selon vos besoins. Pour conclure, si vos serveurs internes exploitent des noms de domaine invalidés, vous devriez envisager une solution au plus vite.

OpenSSL?????Heartbleed?: ??????!

Hacker Medic April 17, 2014 No Comments

今週(4/10現在)、広く利用されている暗号ソフトウェアライブラリであるOpenSSL に「Heartbleed」と呼ばれる脆弱性が見つかりました。(http://heartbleed.com)

OpenSSLは、広く使われるオープンソースの暗号ライブラリで、ApacheやNginxといったウェブサーバやアプリケーションで広く使われています。ウェブサーバで利用中のOpenSSLのバージョンが1.0.1から1.0.1fで脆弱性が含まれており、攻撃者はこの脆弱性を利用してウェブシステムのメモリを覗き見ることができます。このメモリにアクセス出来ることで、SSL暗号通信や個人向けのサービス提供者の通信を復号化し覗き見することができる秘密鍵を攻撃者に渡してしまいます。このメモリにはウェブサイトで利用されているユーザー名やパスワードといった秘匿性の高い情報も含まれます。

「Heartbleed」はSSL/TLS プロトコルに起因する問題ではなく、むしろソフトウェアであるOpenSSLのハートビートの実装バグです。

SSL/TLSプロトコルが破られたわけではありません。インターネット上で暗号通信を行う最高の標準であることに変わりはありません。しかしながら、OpenSSLの利用が幅広いことから、おおよそ66%のインターネットもしくは3分の2のウェブサーバ（参照；Netcraftウェブサーバレポート）がこのソフトウェアを利用しています。OpenSSLを利用している企業は、出来るだけ早くそのバージョンを確認し、影響を受けるバージョンの場合には修正された最新バージョン(1.0.1g)のソフトウェアにアップデートするか、「heartbeat」拡張機能オプションを利用しないで再コンパイルをしないといけません。

世界の認証局のリーダーとしてシマンテックは既に私たちのシステムを更新しました。私たちのルート証明書は危険に直面していません。；しかしながら、基本的なセキュリティ対策（ベストプラクティス）として、問題のバージョンのOpenSSLを利用していたウェブサーバはすべてのSSLサーバ証明書の再発行を行いました。

企業のシステムでOpenSSLを更新するか、再コンパイルをしたら、どのCAが発行したSSLサーバ証明書かに関わらず、サーバからセキュリティの侵害が起こるリスクを軽減するためにすべてのSSLサーバ証明書を入れ替えることをシマンテックは推奨します。

最後に、シマンテックはSSLサーバ証明書とコードサイン証明書の管理画面のパスワードを変更することをお願いしています。改めて、これは基本的なセキュリティ対策（ベストプラクティス）として、システム側の問題を修正したら、ウェブサイトの利用者に対してパスワードの変更を推奨します。この脆弱性による危険を最小化するために、シマンテックはお客様の為に全力を尽くします。

分かりやすくするために、対策として行うべきことを以下にまとめます。

企業向けの注意事項:

•これは OpenSSL ライブラリの脆弱性であり、SSL/TLS プロトコルやシマンテックが発行する「SSL サーバ証明書」の欠陥ではありません。

•OpenSSL 1.0.1 から 1.0.1f を使っている場合には、最新の修正版（1.0.1g）に更新するか、Heartbeat 拡張機能を使わずに OpenSSL を再コンパイルする必要があります。

•修正版の OpenSSL への更新後、脆弱性が悪用されたことでウェブサーバの「SSL サーバ証明書」が侵害された、または秘密鍵を盗まれたと考えられる場合には、認証局に連絡して「SSL サーバ証明書」の再発行を依頼してください。

•基本的なセキュリティ対策（ベストプラクティス）として、侵入を受けたサーバのメモリから漏えいした可能性を考慮し、エンドユーザのパスワードをリセットすることも検討する必要があります。

消費者向けの注意事項:

• 利用しているサービスプロバイダのサーバが脆弱な場合は、データが第三者に盗み見られた可能性があります。

• 利用しているプロバイダからの通知を見逃さないようにしてください。脆弱性を確認したプロバイダからパスワードを変更するよう連絡があった場合には、指示に従ってパスワードを変更してください。

• たとえパスワードの更新を促す内容であっても、攻撃者からのフィッシングメールである可能性には注意し、公式サイトのドメインを確認したうえで、偽装されたウェブサイトにアクセスしないように気を付けてください。

以下のページで最新の情報をご確認ください。

http://www.symantec.com/ja/jp/outbreak/?id=heartbleed

自社の管理サーバがHeartbleedの脆弱性を含んでいるかを確認するツールも提供しています。

[Tweet]

Title；ここをクリックしてテキストを入力してください。

Link；ここをクリックしてテキストを入力してください。

Heartbleed in OpenSSL: richiesta azione immediata

Hacker Medic April 17, 2014 No Comments

Questa settimana è stata rilevata nella diffusa libreria software crittografica OpenSSL una vulnerabilità denominata “Heartbleed” (http://heartbleed.com). OpenSSL trova larghissimo impiego, in particolare con applicazioni e server Web quali Apache e Nginx. La presenza della vulnerabilità è stata riscontrata nelle versioni da 1.0.1 a 1.0.1f di OpenSSL, sfruttate dagli hacker per leggere la memoria dei sistemi colpiti. L’accesso alla memoria può portare alla violazione delle chiavi segrete, permettendo di decrittografare e intercettare le comunicazioni crittografate con SLL, nonché di impersonare i fornitori di servizi. I dati in memoria possono anche contenere informazioni sensibili, inclusi nomi utente e password.

Heartbleed non è una vulnerabilità intrinseca di SSL/TLS, ma piuttosto un bug software dell’implementazione Heartbeat di OpenSSL. A essere compromessa non è la funzionalità di SSL/TLS e il protocollo rimane lo standard di riferimento per la crittografia dei dati in transito su Internet. Tuttavia, data l’ampia diffusione di OpenSSL, è possibile che circa il 66% dei sistemi Internet o i due terzi dei server Web (stando alle stime del report Netcraft sui server Web) facciano uso di questa libreria software. È auspicabile che le aziende che utilizzano OpenSSL provvedano quanto prima a effettuare l’aggiornamento del software alla versione corretta più recente (1.0.1g) o a ricompilare OpenSSL senza l’estensione Heartbeat.

Quale principale autorità di certificazione del settore, Symantec ha già adottato misure tese a rafforzare la protezione dei propri sistemi. I certificati radice di Symantec non corrono alcun rischio. Sono state tuttavia implementate tutte le best practice applicabili, tra cui la rigenerazione delle chiavi per tutti i certificati sui server Web contenenti le versioni di OpenSSL interessate dalla vulnerabilità.

Una volta che le aziende avranno aggiornato e ricompilato i relativi sistemi, Symantec suggerisce loro di sostituire tutti i certificati, indipendentemente dalla CA emittente, sui server Web per ridurre il rischio di violazioni. Symantec offrirà certificati sostitutivi gratuiti a tutti i clienti.

Symantec invita infine a reimpostare le password delle console di gestione dei certificati SSL e Code Signing. Anche in questo caso, si tratta di applicare una best practice di riconosciuta efficacia e il consiglio che Symantec dà alle aziende è di estendere tale raccomandazione, una volta che abbiano applicato la correzione, ai propri clienti finali, perché facciano altrettanto sui propri sistemi. Nel frattempo, continueremo a collaborare con i nostri clienti per contenere quanto più possibile l’impatto dei rischi di sicurezza che la vulnerabilità comporta.

Forniamo di seguito, per praticità, un riepilogo dei passi da intraprendere:

Per le aziende:

Se si utilizzano versioni da 1.0.1 a 1.0.1f di OpenSSL, sarà necessario effettuare l’aggiornamento del software alla versione corretta più recente (1.0.1g) o ricompilare OpenSSL senza l’estensione Heartbeat.
Una volta implementata una versione corretta di OpenSSL, occorrerà sostituire il certificato sul server Web.
Infine, come best practice, sarà consigliato reimpostare le password degli utenti finali che potrebbero essere state decodificate nelle memorie dei server compromessi.

Per i consumatori:

Essere consapevoli del fatto che, se i propri dati si trovavano nei sistemi di un fornitore di servizi vulnerabile, potrebbero essere stati esposti a estranei.
Monitorare le comunicazioni dei fornitori di cui si utilizzano i servizi. Se il fornitore vulnerabile invita i clienti a sostituire le proprie password, provvedervi senza esitare.
Fare attenzione a possibili e-mail di phishing inviate da hacker, contenenti la richiesta di aggiornare la password, per evitare di venire indirizzati a un sito Web contraffatto. Fare sempre e solo riferimento al dominio ufficiale del sito.

Heartbleed in OpenSSL: Handeln Sie jetzt!

Hacker Medic April 16, 2014 No Comments

Letzte Woche wurde eine Schwachstelle mit dem Namen „Heartbleed“ in der beliebten Bibliothek mit Kryptografiesoftware OpenSSL entdeckt (http://heartbleed.com). OpenSSL ist weit verbreitet und wird häufig in Verbindung mit Anwendungen und Webservern wie Apache und Nginx verwendet. Die Schwachstelle ist in den OpenSSL-Versionen 1.0.1 bis 1.0.1f enthalten und ermöglicht es Angreifern, den Arbeitsspeicher der betroffenen Systeme auszulesen. Durch den Zugriff auf den Arbeitsspeicher können die Angreifer Zugang zu privaten Schlüsseln erhalten, wodurch es ihnen möglich wird, SSL-verschlüsselte Kommunikation zu entschlüsseln und mitzulesen und sich als Service-Anbieter auszugeben. Die Daten im Arbeitsspeicher können auch andere vertrauliche Daten wie Benutzernamen und Kennwörter umfassen.

Heartbleed ist keine Schwachstelle von SSL/TLS, sondern ein Softwarefehler in der Heartbeat-Implementierung von OpenSSL. SSL/TLS ist nicht defekt, sondern nach wie vor der Goldstandard für die Verschlüsselung von Daten bei der Übertragung über das Internet. Aufgrund der Beliebtheit von OpenSSL verwenden aber laut dem Netcraft-Bericht über Webserver wahrscheinlich ca. 66 % des Internets, also zwei Drittel der Webserver, diese Software. Unternehmen, die OpenSSL verwenden, sollten daher so schnell wie möglich ein Update auf die neueste, korrigierte Version (1.0.1g) durchführen oder OpenSSL ohne die Heartbeat-Erweiterung neu kompilieren.

Als weltweit führende Zertifizierungsstelle hat Symantec bereits Maßnahmen zum Schutz seiner eigenen Systeme ergriffen. Unsere Root-Zertifikate sind nicht gefährdet, aber wir haben gemäß unseren Best Practices sämtliche Zertifikate auf Webservern, die die betroffenen Versionen von OpenSSL verwendet haben, neu verschlüsselt.

Symantec empfiehlt seinen Kunden, nach der Aktualisierung oder Neukompilierung ihrer Systeme unabhängig vom Aussteller alle Zertifikate auf ihren Webservern zu ersetzen, um das Risiko einer Sicherheitsverletzung zu mindern. Symantec stellt allen seinen Kunden kostenlose Ersatzzertifikate bereit.

Darüber hinaus rät Symantec seinen Kunden, die Kennwörter der Verwaltungskonsole für SSL und Code Signing zurückzusetzen. Dies zählt ebenfalls zu den Best Practices und wir empfehlen allen Unternehmen, auch ihre Kunden dazu aufzufordern, nach der Behebung des Problems auf ihren Systemen dieselben Maßnahmen durchzuführen. Wir werden mit unseren Kunden eng zusammenarbeiten, um die Auswirkungen der Sicherheitsrisiken zu minimieren, die sich durch diese Schwachstelle ergeben.

Zur besseren Übersicht fassen wir die Maßnahmen hier noch einmal zusammen:

Unternehmen:

Alle Unternehmen, die OpenSSL verwenden, sollten ein Update auf die neueste, korrigierte Version der Software (1.0.1g) durchführen oder OpenSSL ohne die Heartbeat-Erweiterung neu kompilieren.
Ersetzen Sie nach der Umstellung auf eine korrigierte Version von OpenSSL die Zertifikate auf ihren Webservern.
Gemäß Best Practice sollten abschließend nach Möglichkeit die Benutzerkennwörter zurückgesetzt werden, da diese im Arbeitsspeicher eines gefährdeten Servers sichtbar gewesen sein können.

Verbraucher:

Machen Sie sich bewusst, dass Ihre Daten von unbefugten Dritten eingesehen worden sein können, wenn Sie einen betroffenen Service-Anbieter verwendet haben.
Lesen Sie alle Nachrichten der von Ihnen verwendeten Anbieter. Sobald ein betroffener Anbieter seine Kunden dazu auffordert, die Kennwörter zu ändern, sollten Sie dies unverzüglich tun.
Fallen Sie nicht auf mögliche Phishing-E-Mails herein, in denen Sie zur Aktualisierung Ihres Kennworts aufgefordert werden. Rufen Sie immer nur den offiziellen Domänennamen der Website auf, um nicht auf eine gefälschte Website zu gelangen.