攻撃者は何を知ることができますか
TLSサーバーの秘密鍵、TLSクライアントの秘密鍵（クライアントが脆弱な場合）、Cookie、ログイン、パスワード、およびサーバーとそのクライアント間で交換されるその他のデータ。 この場合、通信チャネルをリッスンする必要はありません。特別に形成されたパケットを送信するだけで十分であり、サーバーログでこれを検出することはできません。
脆弱性は双方向です。脆弱なクライアントが攻撃者のサーバーに接続すると、攻撃者はクライアントプロセスのメモリを読み取る可能性があります。 脆弱なクライアントの例：MariaDB、wget、curl、git、nginx（プロキシモード）。
脆弱性をテストする方法
Webサービス：
-filippo.io/Heartbleed 、
-www.ssllabs.com/ssltest 、
-rehmann.co/projects/heartbeat 、
-possible.lv/tools/hb
クライアントのテスト： reverseheartbleed.com
Pythonスクリプト： gist.github.com/sh1n0b1/10100394、gist.github.com/mitsuhiko/10130454
Goのスクリプト： github.com/titanous/heartbleeder
ウェブサイト統計： gist.github.com/dberkholz/10169691
どのシステムが脆弱ですか？
-OpenSSL 1.0.1の脆弱性-1.0.1f、1.0.2-beta1、OpenSSL 1.0.1gおよび1.0.2- beta2 （ secadv ）で脆弱性が修正されました。
-OpenVPN（Windowsを含む）-バージョンI004で修正（ ダウンロード ）
-OpenSSLの脆弱なバージョンに静的にリンクされているプログラム。
-Tor（ ブログ ）。
-Debian Wheezy（安定版）-OpenSSL 1.0.1e-2 + deb7u5および1.0.1e-2 + deb7u6で修正（ セキュリティ ）
-Ubuntu 12.04.4 LTS-OpenSSL 1.0.1-4ubuntu5.12（ USN ）で修正
-CentOS 6.5-openssl-1.0.1e-16.el6_5.7で修正されました（ centos-announce ）
-Redhat 6.5-openssl-1.0.1e-16.el6_5.7で修正（ ソリューション 、 エラッタ 、 bugzilla ）
-Fedora 19および20-openssl-1.0.1e-37で修正（ 発表 ）
-Gentoo-openssl-1.0.1g（ GLSA ）で修正されました
-Slackware 14.0および14.1-openssl-1.0.1gで修正（ slackware-security ）
-OpenSUSE 12.3および13.1-openssl-1.0.1eで修正（ opensuse-security-announce ）
-FreeBSD 10.0-10.0 -RELEASE-p1で修正（ アドバイザリ ）
-OpenBSD 5.3および5.4（ パッチ ）
-NetBSD 5.0.2
-Amazon-OpenSSL 1.0.1e-37.66で修正されました（ security-bulletins ）
-Android 4.1.1-脆弱性のない他のバージョン。
通常、これらは脆弱なライブラリに依存しており、再起動が必要です。
-Webサーバー：Nginx、Apache、メールサーバー：Postfix、Dovecot、Jabber、およびその他のIM：ejabberd、
-MySQL、TLSが認証に使用され、OpenSSLに依存する場合：CentOS、RedHat（Remiを含む）、Percona Server（ ブログ ）。
脆弱ではないもの
-Windows（OpenSSLなし）、MacOS（OpenSSLの旧バージョン）、Firefox、Thunderbird（デフォルトはNSS ）、Chrome / Chromium（デフォルトはNSS ）、Android（ハートビートは無効）。
-TLSサーバーのキーに署名するルート証明書と中間証明書（それらの秘密キーはサーバー上にありません）
-OpenSSH（キー生成にのみOpenSSLを使用）
-OpenVPNが静的キー（x509ではない）を使用する場合、または構成で「tls-auth ta.key 1」形式のキーを使用する場合
-UnixライクなOSに更新を配布する方法（ほとんどの場合GnuPGが署名に使用されます）。
システムを更新する方法
Debian、Ubuntu
# aptitude update # aptitude -VR full-upgrade
その後、TLSを使用するサービスを完全に再起動します。 更新インストーラーは、自動的に再起動するように求めますが、手動で次のこともできます。
# service nginx restart # service apache2 restart
再起動する必要があり、脆弱である可能性があるサービスの完全なリスト：
# lsof -n | grep -iE 'del.*(libssl\.so|libcrypto\.so)' # checkrestart
不明な場合は、サーバーを完全に再起動することをお勧めします。
バージョンチェック：
# dpkg -l | grep -i openssl # aptitude changelog openssl
CentOS、RedHat、Fedora
# yum update
その後、次のように、TLSを使用するサービスを完全に再起動します。
# service nginx restart # service httpd restart
再起動する必要があり、脆弱である可能性があるサービスの完全なリスト：
# lsof -n | grep -iE 'del.*(libssl\.so|libcrypto\.so)' # needs-restarting
不明な場合は、サーバーを完全に再起動することをお勧めします。
バージョンチェック：
# yum list openssl # rpm -q --changelog openssl
Freebsd
# freebsd-update fetch # freebsd-update install
その後、次のように、TLSを使用するサービスを完全に再起動します。
# service nginx restart # service apache22 restart
不明な場合は、サーバーを完全に再起動することをお勧めします。
バージョンチェック：
# freebsd-version
TLSキーの取り消しとパスワードの変更
-攻撃者が完全に秘密鍵を収集できた場合、それを使用して偽のサイトを作成したり、盗聴されたセッションを解読したりできます。 そのため、攻撃者に届く可能性のあるキーを持つ証明書を取り消すことをお勧めします。
-クライアントブラウザーがハッシュ+ソルトを使用せずに純粋な形式でサイトにパスワードを渡した場合、これらのパスワードも侵害される可能性があります。
未来のために
-ブラウザが、アクセスしているサイトの証明書が失効しているかどうかを確認する必要があります。
FirefoxはデフォルトでOSCPをチェックし、最近のバージョンはOCSP Staplingもサポートしています。 SafariはデフォルトでMac OS X 10.7（Lion）でチェックします。 Chromeはデフォルトではチェックしません（設定セクションのHTTPS / SSL）。OCSPStaplingはサポートされていません。 Internet ExplorerはデフォルトでOSCPをチェックしますが、OCSP Staplingをサポートしません。 OperaはデフォルトでOSCPをチェックします。 SafariはデフォルトでOSCPをチェックしません。 さまざまなブラウザの設定 。
-サーバーでは、Perfect Forward Secrecy（PFS）を有効にすることが望ましいです。 この場合、秘密鍵が危険にさらされても、攻撃者は盗聴された過去または将来のトラフィックを解読できません。 これを行うには、楕円曲線Diffie-Hellman Ephemeral（ECDHE）またはDiffie-Hellman Ephemeral（DHE）を有効にします。 サーバーのセットアップ 、 テスト 。