開発者ドキュメント

POODLESSLv3の脆弱性からサーバーを保護する方法

序章

2014年10月14日、SSL暗号化プロトコルのバージョン3の脆弱性が公開されました。 この脆弱性はPOODLE(Padding Oracle On Downgraded Legacy Encryption)と呼ばれ、攻撃者が中間者攻撃を使用して、このバージョンのプロトコルで暗号化された情報をプレーンテキストで読み取ることを可能にします。

SSLv3はプロトコルの古いバージョンであり、主に廃止されていますが、多くのソフトウェアは、より優れた暗号化オプションが利用できない場合でもSSLv3にフォールバックします。 さらに重要なことに、SSLv3が接続を試みる両方の参加者にとって利用可能な代替手段である場合、攻撃者がSSLv3接続を強制する可能性があります。

POODLEの脆弱性は、SSLv3を使用した通信を可能にするすべてのサービスまたはクライアントに影響します。 これはプロトコル設計の欠陥であり、実装の問題ではないため、SSLv3を使用するすべてのソフトウェアは脆弱です。

この脆弱性の詳細については、CVE-2014-3566にあるCVE情報を参照してください。

POODLEの脆弱性とは何ですか?

POODLEの脆弱性は、SSLプロトコルのバージョン3の弱点であり、中間者コンテキストの攻撃者がSSLv3暗号化メッセージのプレーンテキストコンテンツを解読できるようにします。

この脆弱性の影響を受けるのは誰ですか?

この脆弱性は、SSLv3との通信を強制できるすべてのソフトウェアに影響を及ぼします。 これは、SSLv3サポートを含むフォールバックメカニズムを実装するソフトウェアは脆弱であり、悪用される可能性があることを意味します。

影響を受ける可能性のある一般的なソフトウェアには、Webブラウザー、Webサーバー、VPNサーバー、メールサーバーなどがあります。

それはどのように機能しますか?

つまり、SSLv3プロトコルは、暗号化されたメッセージで送信されるパディングバイトを適切にチェックしないため、POODLEの脆弱性が存在します。

これらは受信側が確認できないため、攻撃者はこれらを置き換えて目的の宛先に渡すことができます。 特定の方法で行われた場合、変更されたペイロードは、苦情なしに受信者によって受け入れられる可能性があります。

256リクエストごとに平均1回が宛先で受け入れられ、攻撃者は1バイトを復号化できます。 これは、追加のバイトを段階的に復号化するために簡単に繰り返すことができます。 このプロトコルを使用して参加者にデータの再送信を繰り返し強制できる攻撃者は、非常に短時間で暗号化を破ることができます。

どうすれば自分を守ることができますか?

クライアントとサーバーの両方としての役割に脆弱でないことを確認するためのアクションを実行する必要があります。 暗号化は通常、クライアントとサーバーの間でネゴシエートされるため、両者が関係する問題です。

サーバーとクライアントは、SSLv3サポートを完全に無効にするための手順を実行する必要があります。 多くのアプリケーションはデフォルトでより優れた暗号化を使用しますが、フォールバックオプションとしてSSLv3サポートを実装します。 両方の参加者が許容可能な方法としてSSLv3通信を許可した場合、悪意のあるユーザーがSSLv3通信を強制する可能性があるため、これを無効にする必要があります。

一般的なアプリケーションを保護する方法

以下では、いくつかの一般的なサーバーアプリケーションでSSLv3を無効にする方法について説明します。 サーバーを評価して、SSL/TCP暗号化に依存する可能性のある追加のサービスを保護するように注意してください。

POODLEの脆弱性は実装の問題を表すものではなく、プロトコル全体に固有の問題であるため、回避策はなく、信頼できる唯一の解決策はそれを使用しないことです。

NginxWebサーバー

Nginx WebサーバーでSSLv3を無効にするには、ssl_protocolsディレクティブを使用できます。 これは、構成のserverまたはhttpブロックに配置されます。

たとえば、Ubuntuでは、これをhttpブロック内の/etc/nginx/nginx.confにグローバルに追加するか、/etc/nginx/sites-enabledディレクトリの各serverブロックに追加できます。

sudo nano /etc/nginx/nginx.conf

SSLv3を無効にするには、ssl_protocolsディレクティブを次のように設定する必要があります。

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

上記の変更を行った後、サーバーを再起動する必要があります。

sudo service nginx restart

ApacheWebサーバー

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.conf

CentOSでは、ここにあるSSL構成ファイルでこれを調整できます(SSLが有効になっている場合)。

sudo nano /etc/httpd/conf.d/ssl.conf

中にはSSLProtocolディレクティブがあります。 これが利用できない場合は、作成してください。 これを変更して、SSLv3のサポートを明示的に削除します。

SSLProtocol all -SSLv3 -SSLv2

ファイルを保存して閉じます。 サービスを再起動して変更を有効にします。

Ubuntuでは、次のように入力できます。

sudo service apache2 restart

CentOSでは、これは次のようになります。

sudo service httpd restart

HAProxyロードバランサー

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 restart

OpenVPNVPNサーバー

OpenVPNの最近のバージョンでは、実際にはSSLv3は許可されていません。 サービスはこの特定の問題に対して脆弱ではないため、構成を調整する必要はありません。

詳細については、OpenVPNフォーラムのこの投稿を参照してください。

PostfixSMTPサーバー

Postfix設定が暗号化を要求するように設定されている場合、smtpd_tls_mandatory_protocolsと呼ばれるディレクティブを使用します。

これはメインのPostfix設定ファイルにあります:

sudo nano /etc/postfix/main.cf

常に暗号化を使用するように設定されたPostfixサーバーの場合、このパラメーターを設定することにより、SSLv3およびSSLv2が受け入れられないようにすることができます。 暗号化を強制しない場合は、何もする必要はありません。

smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3

構成を保存します。 サービスを再起動して、変更を実装します。

sudo service postfix restart

DovecotIMAPおよび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 !SSLv2

2.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などの弱い形式の暗号化を完全に無効にするための明示的な命令が必要です。

モバイルバージョンを終了