前書き
2014年10月14日に、SSL暗号化プロトコルのバージョン3の脆弱性が公開されました。 POODLE（ダウングレードされたレガシー暗号化のパディングOracle）と呼ばれるこの脆弱性により、攻撃者は中間者攻撃を使用してプレーンテキストでこのバージョンのプロトコルで暗号化された情報を読み取ることができます。
SSLv3はプロトコルの古いバージョンであり、主に廃止されていますが、より適切な暗号化オプションが利用できない場合、manyのソフトウェアはSSLv3にフォールバックします。 さらに重要なことは、接続しようとする両方の参加者が利用可能な代替手段である場合、攻撃者がSSLv3接続を強制することが可能です。
POODLEの脆弱性は、SSLv3を使用した通信を可能にするサービスまたはクライアントに影響を与えます。 これはプロトコル設計の欠陥であり、実装の問題ではないため、SSLv3を使用するeveryのソフトウェアは脆弱です。
脆弱性の詳細については、CVE-2014-3566にあるCVE情報を参照してください。
POODLEの脆弱性とは何ですか？
POODLEの脆弱性は、SSLプロトコルのバージョン3の弱点であり、中間者コンテキストの攻撃者がSSLv3暗号化メッセージのプレーンテキストコンテンツを解読できるようにします。
この脆弱性の影響を受けるのは誰ですか？
この脆弱性は、SSLv3との通信を強制されるすべてのソフトウェアに影響を与えます。 つまり、SSLv3サポートを含むフォールバックメカニズムを実装するソフトウェアは脆弱であり、悪用される可能性があります。
影響を受ける可能性のある一般的なソフトウェアには、Webブラウザ、Webサーバー、VPNサーバー、メールサーバーなどがあります。
それはどのように機能しますか？
つまり、SSLv3プロトコルは暗号化されたメッセージとともに送信されるパディングバイトを適切にチェックしないため、POODLEの脆弱性が存在します。
これらは受信側では検証できないため、攻撃者はこれらを置き換えて目的の宛先に渡すことができます。 特定の方法で行われた場合、変更されたペイロードは、苦情なしに受信者に受け入れられる可能性があります。
宛先では256リクエストごとに平均1回が受け入れられ、攻撃者は1バイトを解読できます。 これは、追加のバイトを徐々に復号化するために簡単に繰り返すことができます。 このプロトコルを使用して参加者にデータの再送を繰り返し強制できる攻撃者は、非常に短時間で暗号化を破ることができます。
どうすれば自分を守ることができますか？
クライアントとサーバーの両方としての役割において脆弱ではないことを保証するためのアクションをとるべきです。 暗号化は通常、クライアントとサーバー間でネゴシエートされるため、両者が関係する問題です。
サーバーとクライアントは、SSLv3サポートを完全に無効にする手順を実行する必要があります。 多くのアプリケーションはデフォルトでより良い暗号化を使用しますが、フォールバックオプションとしてSSLv3サポートを実装します。 悪意のあるユーザーは、受け入れ可能な方法として両方の参加者が許可した場合、SSLv3通信を強制する可能性があるため、これを無効にする必要があります。
一般的なアプリケーションを保護する方法
以下では、一般的なサーバーアプリケーションでSSLv3を無効にする方法について説明します。 サーバーを評価して、SSL / TCP暗号化に依存する可能性のある追加サービスを保護するように注意してください。
POODLE脆弱性は実装の問題を表すものではなく、プロトコル全体に固有の問題であるため、回避策はなく、唯一の信頼できる解決策はそれを使用しないことです。
Nginx Webサーバー
Nginx WebサーバーでSSLv3を無効にするには、ssl_protocolsディレクティブを使用できます。 これは、構成のserverまたはhttpブロックに配置されます。
たとえば、Ubuntuでは、これをhttpブロック内の/etc/nginx/nginx.confにグローバルに追加するか、/etc/nginx/sites-enabledディレクトリの各serverブロックに追加できます。
sudo nano /etc/nginx/nginx.confSSLv3を無効にするには、ssl_protocolsディレクティブを次のように設定する必要があります。
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;上記の変更を行った後、サーバーを再起動する必要があります。
sudo service nginx restartApache Webサーバー
Apache WebサーバーでSSLv3を無効にするには、mod_sslモジュールによって提供されるSSLProtocolディレクティブを調整する必要があります。
このディレクティブは、サーバーレベルまたは仮想ホスト構成で設定できます。 ディストリビューションのApache構成によっては、SSL構成がソースとなる別のファイルにある場合があります。
Ubuntuでは、サーバーのサーバー全体の仕様は、/etc/apache2/mods-available/ssl.confファイルを編集することで調整できます。 mod_sslが有効になっている場合、シンボリックリンクはこのファイルをmods-enabledサブディレクトリに接続します。
sudo nano /etc/apache2/mods-available/ssl.confCentOSでは、ここにあるSSL構成ファイルでこれを調整できます（SSLが有効な場合）。
sudo nano /etc/httpd/conf.d/ssl.conf内部には、SSLProtocolディレクティブがあります。 これが利用できない場合、作成します。 これを変更して、SSLv3のサポートを明示的に削除します。
SSLProtocol all -SSLv3 -SSLv2ファイルを保存して閉じます。 サービスを再起動して、変更を有効にします。
Ubuntuでは、次のように入力できます。
sudo service apache2 restartCentOSでは、これは次のようになります。
sudo service httpd restartHAProxyロードバランサー
HAProxyロードバランサーでSSLv3を無効にするには、haproxy.cfgファイルを開く必要があります。
これは/etc/haproxy/haproxy.cfgにあります：
sudo nano /etc/haproxy/haproxy.cfgフロントエンド構成でSSLを有効にしている場合、bindディレクティブはパブリックIPアドレスとポートを指定します。 SSLを使用している場合は、この行の最後にno-sslv3を追加する必要があります。
frontend name
bind public_ip:443 ssl crt /path/to/certs no-sslv3ファイルを保存して閉じます。
変更を実装するには、サービスを再起動する必要があります。
sudo service haproxy restartOpenVPN VPNサーバー
OpenVPNの最近のバージョンは、実際にはSSLv3を許可していません。 サービスはこの特定の問題に対して脆弱ではないため、構成を調整する必要はありません。
Postfix SMTPサーバー
Postfix設定が暗号化を要求するように設定されている場合、smtpd_tls_mandatory_protocolsと呼ばれるディレクティブを使用します。
これはメインのPostfix設定ファイルで見つけることができます：
sudo nano /etc/postfix/main.cf常に暗号化を使用するように設定されたPostfixサーバーの場合、このパラメーターを設定することにより、SSLv3およびSSLv2が受け入れられないようにすることができます。 暗号化を強制しない場合、何もする必要はありません。
smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3設定を保存します。 サービスを再起動して、変更を実装します。
sudo service postfix restartDovecot IMAPおよびPOP3サーバー
DovecotサーバーでSSLv3を無効にするには、ssl_protocolsというディレクティブを調整する必要があります。 ディストリビューションのパッケージ方法によっては、SSL構成が代替構成ファイルに保持される場合があります。
ほとんどのディストリビューションでは、このファイルを開いてこのディレクティブを調整できます。
sudo nano /etc/dovecot/conf.d/10-ssl.conf内部では、Dovecot 2.1以降を使用している場合は、ssl_protocolsディレクティブを設定してSSLv2とSSLv3を無効にします。
ssl_protocols = !SSLv3 !SSLv22.1より前のバージョンのDovecotを使用している場合は、次のようにssl_cipher_listを設定してSSLv3を禁止できます。
ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL:!SSLv3ファイルを保存して閉じます。
変更を実装するには、サービスを再起動します。
sudo service dovecot restartさらなるステップ
サーバー側のアプリケーションに加えて、クライアントアプリケーションも更新する必要があります。
特に、Webブラウザは、ステップダウンプロトコルネゴシエーションのため、この問題に対して脆弱である可能性があります。 ご使用のブラウザーで、受け入れ可能な暗号化方式としてSSLv3が許可されていないことを確認してください。 これは、設定または追加のプラグインまたは拡張機能のインストールによって調整可能です。
結論
SSLv3の広範なサポートにより、強力な暗号化が有効になっている場合でも、この脆弱性は広範囲に及ぶ危険です。 SSL暗号化を利用するリソースの消費者とプロバイダーの両方として自分自身を保護するための対策を講じる必要があります。
あらゆる形式のSSL / TLSを活用する可能性のあるネットワークアクセス可能なサービスをすべてチェックアウトしてください。 多くの場合、これらのアプリケーションでは、SSLv3のような弱い形式の暗号化を完全に無効にするための明示的な指示が必要です。