Tag Archives: Authentication Services

Perfect Forward Secrecy

      No Comments on Perfect Forward Secrecy

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

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

      No Comments on OpenSSL?????Heartbleed?: ??????!

ghp-outbreak-flamer-threat-hero-2.jpg

今週(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

ghp-outbreak-flamer-threat-hero-2.jpg

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!

ghp-outbreak-flamer-threat-hero-2.jpg

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.

Heartbleed no OpenSSL: a hora de agir é agora!

ghp-outbreak-flamer-threat-hero-2.jpg

Semana passada, uma vulnerabilidade conhecida como “Heartbleed” foi encontrada na popular biblioteca de software criptográfico OpenSSL (http://heartbleed.com). O OpenSSL é amplamente usado, muitas vezes com aplicativos e servidores Web como Apache e Nginx. As versões do OpenSSL de 1.0.1 até 1.0.1f contêm essa vulnerabilidade, que pode ser explorada por invasores para ler a memória dos sistemas. O acesso à memória pode levar os invasores a obterem chaves secretas, permitindo que eles decifrem e interceptem comunicações criptografadas por SSL e se façam passar por provedores de serviços. Os dados na memória também podem conter informações confidenciais, inclusive nomes de usuário e senhas.

O Heartbleed não é uma vulnerabilidade do SSL/TLS, e sim um bug de software na implementação da extensão heartbeat do OpenSSL. O SSL/TLS não foi enfraquecido; ele ainda é o padrão ouro para criptografia de dados em trânsito na Internet. Porém, devido à popularidade do OpenSSL, aproximadamente 66% dos servidores da Internet ou dois terços dos servidores Web (segundo o relatório da Netcraft sobre servidores Web) podem estar utilizando esse software. Recomenda-se às empresas que usam o OpenSSL que o atualizem para a última versão corrigida do software (1.0.1g) ou recompilem o OpenSSL sem a extensão heartbeat o mais rápido possível.

Sendo a principal autoridade de certificação do mundo, a Symantec já tomou medidas para reforçar seus sistemas. Nossas raízes não correm risco; no entanto, estamos seguindo as melhores práticas e recriamos as chaves de todos os certificados nos servidores Web que contêm as versões afetadas do OpenSSL.

Depois que as empresas atualizarem ou recompilarem seus sistemas, a Symantec recomenda que os clientes substituam todos os seus certificados em servidores Web, seja qual for o emissor, para reduzir os riscos de violações à segurança. A Symantec oferecerá certificados substitutos gratuitos para todos os clientes.

Por fim, a Symantec solicita aos clientes que redefinam as senhas de seus consoles de gerenciamento SSL e com assinatura de código. Mais uma vez, trata-se da melhor prática; encorajamos as empresas a solicitarem que seus clientes finais façam o mesmo depois que os sistemas tiverem aplicado a correção. Continuaremos a trabalhar com nossos clientes a fim de minimizar o impacto dos riscos de segurança provenientes dessa vulnerabilidade.

Para sua conveniência, eis um resumo das etapas a serem seguidas:

Para empresas:

  • Todos aqueles que usam o OpenSSL 1.0.1 até 1.0.1f devem atualizá-lo para a última versão corrigida do software (1.0.1g) ou recompilar o OpenSSL sem a extensão heartbeat.
  • As empresas também devem substituir o certificado nos respectivos servidores Web após migrarem para uma versão corrigida do OpenSSL.
  • Por fim, como melhor prática, também é recomendável que as empresas redefinam as senhas dos usuários finais que possam ter ficado visíveis na memória de um servidor comprometido.

Para os consumidores:

  • Esteja ciente da possibilidade de seus dados terem sido vistos por um terceiro se você tiver usado um provedor de serviços vulnerável.
  • Monitore as notificações enviadas pelos fornecedores que você usa. Se um fornecedor vulnerável comunicar aos clientes que devem alterar suas senhas, os usuários devem seguir essa instrução.
  • Evite possíveis e-mails de phishing enviados por invasores solicitando a atualização de sua senha; para evitar acessar um site fraudulento, atenha-se ao domínio oficial do site.

OpenSSL et Heartbleed : stoppez l’hémorragie !

ghp-outbreak-flamer-threat-hero-2.jpg

La semaine dernière, une faille baptisée « Heartbleed » a été détectée dans la bibliothèque de chiffrement OpenSSL (http://heartbleed.com). Cette bibliothèque est particulièrement utilisée sur des applications et serveurs Web comme Apache et Nginx. Concrètement, les versions 1.0.1 à 1.0.1f d’OpenSSL présentent une faille que des attaquants peuvent exploiter pour lire la mémoire des systèmes hôtes. Ainsi, ils pourront accéder aux clés secrètes qui leur permettront de décrypter et d’intercepter les communications sécurisées via SSL, voire même de se faire passer pour des fournisseurs de services. Mais le danger ne s’arrête pas là puisque les données en mémoire pourront également contenir des informations sensibles, telles que des noms d’utilisateur et des mots de passe.

Heartbleed ne constitue en rien une vulnérabilité des protocoles SSL/TLS. Il s’agit en fait d’un bug logiciel dans l’implémentation de l’extension OpenSSL « heartbeat ». Bref, la technologie SSL/TLS n’est aucunement remise en question. Elle est et demeure la référence absolue en matière de cryptage des transferts de données sur Internet. Le problème provient de l’omniprésence d’OpenSSL. D’après un rapport Netcraft, deux tiers des serveurs Web sur Internet seraient équipés de ce logiciel. Toutes ces entreprises devront donc passer à la dernière version corrigée de la bibliothèque (1.0.1g) ou recompiler OpenSSL sans l’extension heartbeat dès que possible.

De son côté, en tant que leader mondial des autorités de certification, Symantec a déjà pris un certain nombre de mesures pour renforcer ses systèmes. Bien que nos certificats racines ne soient pas exposés, nous avons décidé d’appliquer les bonnes pratiques de rigueur, à savoir la redéfinition des clés de tous les certificats sur les serveurs Web équipés des versions vulnérables d’OpenSSL.

Une fois leurs systèmes mis à jour ou recompilés, Symantec recommande aux entreprises de remplacer tous leurs certificats – quel qu’en soit l’émetteur – sur leurs serveurs Web afin de limiter les risques de violations de sécurité. Pour les y encourager, nous offrirons à tous nos clients la possibilité de remplacer gratuitement leurs certificats.

Enfin, par simple mesure de précaution, Symantec demande à ses clients de réinitialiser les mots de passe de leur console de gestion de certificats SSL et Code Signing. Nous encourageons également les entreprises à inciter leurs clients à en faire de même une fois leurs systèmes corrigés. De notre côté, nous poursuivrons notre coopération avec nos propres clients pour minimiser l’impact de cette vulnérabilité sur leur sécurité.

Pour vous faciliter la tâche, nous dressons ici un point rapide sur les mesures à prendre :

Entreprises :

  • Si vous utilisez les versions OpenSSL 1.0.1 à 1.0.1f, installez la dernière version corrigée du logiciel (1.0.1g) ou recompilez votre version existante sans l’extension heartbeat.
  • Une fois la version corrigée d’OpenSSL installée, remplacez également le certificat du serveur Web concerné.
  • Enfin, par mesure de précaution, réinitialisez vos mots de passe utilisateur. En effet, ces derniers auront pu être décryptés dans la mémoire des serveurs compromis.

Particuliers :

  • Si votre fournisseur de services a été touché par Heartbleed, il est possible que vos données aient été interceptées par un cybercriminel.
  • Restez attentifs aux avis des éditeurs et fournisseurs dont vous êtes client. Si ces derniers vous demandent de modifier votre mot de passe, faites-le sans tarder.
  • Méfiez-vous des éventuels e-mails de phishing vous demandant de modifier votre mot de passe. Pour éviter de vous retrouver sur un site Web frauduleux, limitez-vous au domaine du site officiel.

OpenSSL, afectado por la vulnerabilidad Heartbleed: actúe cuanto antes

ghp-outbreak-flamer-threat-hero-2.jpg

La semana pasada, se descubrió que la vulnerabilidad «Heartbleed» (http://heartbleed.com) había afectado a la conocida biblioteca de software criptográfico OpenSSL, que se utiliza con aplicaciones y servidores web como Apache y Nginx, además de para otros muchos usos. En determinadas versiones de OpenSSL (de la 1.0.1 a la 1.0.1f, ambas incluidas), existe el riesgo de que los ciberdelincuentes accedan a la memoria de los sistemas, obtengan las claves secretas necesarias para descifrar y espiar las comunicaciones protegidas mediante la tecnología SSL, y suplanten a los proveedores de servicios. Además, es posible que los datos de la memoria contengan información confidencial, como nombres de usuario y contraseñas.

Heartbleed no es una vulnerabilidad de la tecnología SSL/TLS, sino un error de programación en la implementación de la extensión heartbeat de OpenSSL. Esto no quiere decir que SSL/TLS haya dejado de funcionar; al contrario, sigue siendo la tecnología líder para cifrar los datos que se transmiten por Internet. Sin embargo, debido a la popularidad de OpenSSL, es posible que actualmente use el software afectado en torno al 66 % de Internet, el equivalente a dos tercios de los servidores web (según el informe sobre servidores web de Netcraft). Las empresas que usan OpenSSL deberían pasarse a la versión 1.0.1g, en la que el problema ya está solucionado, o recompilar OpenSSL sin la extensión heartbeat lo antes posible.

Symantec ya ha tomado medidas para reforzar la seguridad de sus sistemas, como corresponde a la principal autoridad de certificación del mundo. Nuestras raíces están a salvo, pero aun así estamos siguiendo los protocolos recomendados y hemos modificado las claves de todos los certificados de los servidores web que utilizaban las versiones de OpenSSL afectadas.

Symantec recomienda a las empresas que, tras actualizar o recompilar sus sistemas, sustituyan todos los certificados de los servidores web (independientemente de quién los haya emitido) para evitar posibles incidencias de seguridad. Tenemos previsto facilitar a todos nuestros clientes nuevos certificados gratuitos.

Por último, instamos a los clientes a que, por precaución, cambien las contraseñas de las consolas de gestión de certificados SSL y de firma de código (Code Signing). Una vez restablecida la seguridad de los sistemas, es recomendable que las empresas también pidan a sus clientes que cambien las contraseñas.

Seguiremos colaborando con nuestros clientes para reducir al mínimo las consecuencias de esta vulnerabilidad, pero a continuación resumimos los pasos básicos para protegerse.

En el caso de las empresas, recomendamos:

  • actualizar las versiones de OpenSSL afectadas (de la 1.01 a la 1.0.1f, ambas incluidas) a la versión 1.0.1g, o bien recompilar OpenSSL sin la extensión heartbeat;
  • sustituir el certificado del servidor web tras adoptar una versión segura de OpenSSL;
  • restablecer por precaución todas las contraseñas de los usuarios, ya que alguien podría haberlas obtenido al infiltrarse en la memoria del servidor.

Por su parte, los consumidores deberían:

  • saber que, si los proveedores de los servicios que utilizan se han visto afectados por Heartbleed, es posible que la confidencialidad de sus datos no esté garantizada;
  • estar pendientes de los avisos que reciban y cambiar las contraseñas si el proveedor de un servicio afectado se lo solicita;
  • fijarse bien en quién envía los mensajes de correo electrónico en los que se solicita un cambio de contraseña y asegurarse de que los enlaces conducen al sitio web oficial, ya que podría tratarse de intentos de phishing.

Heartbleed, Y2K and misplaced worry.

      No Comments on Heartbleed, Y2K and misplaced worry.

brook-heartbleed-blog-1.pngOver the past week news about the Heartbleed OpenSSL vulnerability draws some similarities and also some dissimilarities to the Y2K bug; remember that?  In early 1999, there were stories of people building our survival bunkers in the basements of their homes in order to prepare for the potential fallout from the Y2K bug.  As you may recall IT companies scrambled, airlines were fraught with angst , and governments paid very large sums of money to ensure the sky wouldn’t fall down on us.  As we know now New Year’s Day 2000 came and went with nary a hitch, although companies were left to pay some hefty Y2K consultant bills (it was reported at the time that AT&T paid over $500 million USD) and many families across the globe were left with fully stocked basements, a surplus of books on modern Armageddon, candles and canned soup.

brook-heartbleed-blog-2.pngFast forward 15 years later and a new bug; Heartbleed was discovered in the popular OpenSSL cryptographic software library. This vulnerability, which may affect up to two-thirds of the internet, allows an attacker to withdraw a server’s most vital secrets including passwords and private SSL certificate keys.  Although this bug surely won’t cause nuclear missiles to launch, companies and families need to be more concerned about this bug rather than the one that caused people to build bunkers in their backyards.  The Heartbleed bug appears to have been around for two years and was only discovered by two teams of researchers little more than a week ago.  However, much like the argument over who discovered “America”, it appears this vulnerability has been discovered and exploited in the past by black hat Leif Ericksons; modern day digital Vikings bent on pillaging data.

A recent blog by internet services company NetCraft,  said the SSL tsunami has yet to arrive.  Discouragingly, by the morning of Friday the 11th of April 2014, only 30,000 of the possible pool of 500,000 affected SSL certificates have yet to be replaced. This is akin to Y2K being a reality and IT professionals refusing to patch ’00 date bugs on servers in favor of sealing the hatch on their secure bunker. By now every hacker knows about this vulnerability; it’s a race against time and you should take action now to ensure that you take the steps required to take the required action to fix your site.

This is real and every hour that goes by, unpatched servers become more and more exposed to attack.  The first step is to get out of our blissful bunkers of ignorance and check our domains to see if the servers are vulnerable.  Symantec’s Domain Checker should be your first port of call – it allows you to check your site for Heartbleed.  If you are not affected by Heartbleed be certain to tell your customers – they really need to know and believe you me they will be grateful that you have told them.  However if you have been affected, start by reading our Knowledgebase article on the subject and take the following steps:. 

  1. Upgrade your servers to OpenSSL 1.0.1g or recompile without the Heartbeat extension.
  2. Change your password to your Symantec SSL console (if applicable).  Note that Symantec Managed PKI for SSL was not affected and you do not need a new Administrator ID.
  3. Replace your SSL certificates on your impacted servers; replacement SSL certificates are offered at no charge for existing Symantec SSL customers.  Keep your details the same to avoid having to go through authentication again.
  4. Test your configuration and installation.  Note it is a best practice to always install the intermediate certificate with your end-entity certificate. 
  5. Upon successful completion revoke any certificates that were replaced in step 3.
  6. Consider resetting customer’s passwords on any server that could have been compromised.

One final piece of advice, you may have to do this on your intranet sites as well.  Don’t trust your firewall to keep out hackers, they find their way behind firewalls every day by either infecting the menu at your favorite take-out place or by changing the rules.  If you want more up to date information on Heartbleed or any other threats follow us on Twitter, Facebook and bookmark our corporate Heartbleed update page.

Heartbleed in OpenSSL: Take Action Now!

This week a vulnerability dubbed “Heartbleed” was found in the popular OpenSSL cryptographic software library (http://heartbleed.com).  OpenSSL is widely used, often with applications and web servers like Apache and Nginx.   OpenSSL versions 1.0.1 through 1.0.1f contain this vulnerability, which attackers can exploit to read the memory of the systems.  Gaining access to the memory could provide attackers with secret keys, allowing them to decrypt and eavesdrop on SSL encrypted communications and impersonate service providers. Data in memory may also contain sensitive information including usernames and passwords.

Heartbleed is not a vulnerability with SSL/TLS, but rather a software bug in the OpenSSL heartbeat implementation. SSL/TLS is not broken; it is still the gold standard for encrypting data in transit on the Internet. However, due to the popularity of OpenSSL, approximately 66% of the Internet or two-thirds of web servers (according to Netcraft Web server report ) could be using this software. Companies using OpenSSL should update to the latest fixed version of the software (1.0.1g) or recompile OpenSSL without the heartbeat extension as soon as possible.

As the world’s leading Certification Authority, Symantec has already taken steps to strengthen our systems. Our roots are not at risk; however, we are following best practices and have re-keyed all certificates on web servers that have the affected versions of OpenSSL.

After companies have updated or recompiled their systems, Symantec is recommending that customers replace all their certificates -regardless of issuer- on their web servers to mitigate the risks of security breach. Symantec will be offering free replacement certificates for all our customers.   

Finally, Symantec is asking customers to reset passwords to their SSL and code-signing management consoles.  Again, this is a best practice and we encourage companies to ask their end customers to do the same after their systems have applied the fix.  We will continue to work with our customers to minimize the impact of security risks from this vulnerability.

For your convenience, here is a summary of steps to take:

For businesses:

  • Anyone using OpenSSL 1.0.1 through 1.0.1f should update to the latest fixed version of the software (1.0.1g), or recompile OpenSSL without the heartbeat extension.  
  • Businesses should also replace the certificate on their web server after moving to a fixed version of OpenSSL.
  • Finally, and as a best practice, businesses should also consider resetting end-user passwords that may have been visible in a compromised server memory.

For consumers:

  • Should be aware their data could have been seen by a third party if they used a vulnerable service provider.
  • Monitor any notices from the vendors you use. Once a vulnerable vendor has communicated to customers that they should change their passwords, users should do so.
  • Avoid potential phishing emails from attackers asking you to update your password – to avoid going to an impersonated website, stick with the official site domain.

Applying for an SSL certificate? Do your homework first!

homework-blog-1.png

If you need an SSL certificate to protect your website or some other business-critical application such as email or storage systems, then you need to remember your ABCDs.

A is for the Appropriate certificate

There are a few different types of SSL certificate out there for different applications. For example, there are Unified Communications Certs (UCC) and code signing certificates. But the most common type is designed to secure a website, authenticate it and encrypt the traffic between the site and the user.

Within this group there are SSL Wildcard certificates that are ideal if you want to protect multiple subdomains of the same address, for example if you had multiple sites for different languages such as uk.company.com and us.company.com.

For other certificates, you have a choice of Extended Validation certificates which give site visitors visible reassurance about the provenance of the site and regular certificates. Within the Symantec SSL portfolio, there are different levels of encryption, different types of the encryption algorithm and security but they all include daily website malware scanning and Symantec Seal-in-Search.

More information about Symantec SSL certificates.

homework-blog-2.png

B is for Best support

Before you buy a certificate, it’s important to check that you’ll get the support you need. Sometimes, even the most proficient IT managers needs help with a particularly complex certificate problem. With Symantec, you’ve got multi language 24/7/365 support on tap.

C is for Certificate Authority

Not all SSL is the same because not all CAs are the same. Founded as VeriSign in 1995, we support the world’s largest and most critical certificate deployments. Our validation services process on average over four and a half billion hits per day – with zero downtime in more than ten years. This is why 97 of the world’s 100 largest financial institutions and 75 percent of the 500 biggest e-commerce sites in North America use SSL Certificates from Symantec.

D is for Documentation

Before you request a certificate, especially an Extended Validation (EV) certificate, it helps to have all your documentation ready. You’ll need to authenticate your organisation, prove you have authority to request a certificate, authenticate your domain and, in some cases, verify the organisation with additional documentation.

The more you know the better prepared you can be to enrol and install your certificate. Read on to find out how SSL and using the Norton Secured Seal on your site can help you succeed online.

For SSL download our interactive SSL resource, ‘SSL Explained’ now.