Firefox 38 と TLS intolerant であるSSL/TLS サーバーについて

TLS (Transport Layer Security) は以前は SSL (Secure Sockets Layer) と呼ばれる暗号プロトコルで、ネットワーク、主にインターネット上で安全な通信を提供するために作られました。

http://en.wikipedia.org/wiki/Transport_Layer_Security も併せて参照してください。

TLS は、多くのインターネットアプリケーションで使用されています。https プロトコルを使用する Firefox などの web ブラウザーがその最たる例で、http を TLS に接続して web サーバーから情報を安全に取得します。

Firefox web ブラウザーのバージョン 38 では、TLS と https プロトコルの処理方法が変更になります。このナレッジでは、変更内容とその理由および結果、そしてその変更に関連する問題をどのように回避できるかについて説明します。

通信セッションを開始すると、通信チャンネルの両側 (たとえば web ブラウザーと web サーバー) が最初のフェーズを開始して、チャンネルの保護方法を互いに同意します。この手順は、TLS プロトコルが徐々に進化しているため、いずれかで使用している TLS のバージョンが古く、機能が制限されている可能性があるため非常に重要です。

この最初のフェーズは TLS ハンドシェイクとも呼ばれており、ここで、使用可能な TLS プロトコルのバージョンをお互いに指定し、どのプロトコルのバージョンを使用するか同意します。たとえば、ブラウザーが、TLS 1.2 プロトコルを使用して接続することを提案します。web サーバーが TLS 1.2 サポートしない場合は TLS 1.1 を使用して接続することを提案します。ブラウザーがこれに同意すると、セッションは TLS 1.1 プロトコルで行われます。

ハンドシェイク時には安全な通信は確立されていないため、攻撃者はこのフェーズを操ろうとします。よくある攻撃は「中間者 (MITM) 攻撃」と呼ばれ、 クライアントとサーバーとの間に攻撃者が置かれ、互いが送信するデータパッケージを妨害します。たとえば、web サーバーとブラウザーに、安全性が低い古いバージョンの TLS または SSL を使用するようにネゴシエートさせて、データを破壊します。TLS ハンドシェイクプロトコルは安全であるため直接攻撃するのは困難ですが、接続を失敗させることができれば、MITM は web サーバーとブラウザーに古いバージョンの TLS を使うようにネゴシエートさせることができます。

Firefox 38 では、クライアントとサーバーに古くて安全性の低い TLS プロトコルを使用させるように仕向けることが困難になっています。

TLS プロトコルは、クライアント (たとえばブラウザー) が、利用できる最新のプロトコルを使用するようにサーバーが伝えます。サーバーがその TLS プロトコルをサポートはしていても古いバージョンの TLS プロトコルを使用している場合、サーバーはクライアントに通知し、クライアントはその通信を使用し続けるか決定できます。

クライアントソフトウェアはサーバーソフトウェアよりも早い時期にバージョンがあがるため、より新しいバージョンを使用するクライアントが、古いバージョンの TLS をサポートするサーバーと通信できるようにすることがしばしば適切となります。

ただし、攻撃者が古いバージョンの TLS を攻撃する可能性は非常に高いため、できるだけ新しいバージョンを使用する必要があります。

また、パブリックインターネットとプライベートイントラネットに配置されている多くのサーバーソフトウェアの中には、TLS プロトコルを実装する方法に不具合が含まれるものもあります。サーバーの中には、サポートしないバージョンを見つけた場合は、TLS ハンドシェイクプロトコルを介して使用するバージョンをネゴシエートせずに、単純に切断してしまうものもあります。この動作は TLS intolerance (TLS 狭量、TLS 不寛容) と呼ばれています。

以前は、悪い実装がよく見られたため、web ブラウザーなどのクライアントソフトウェアの開発者が、相互運用性を強化して回避策を実装していました。

また、Firefox が最新の TLS バージョン 1.2 を使用していてサーバーが単に切断した場合、Firefox は TLS 1.1 を使用して接続しようとしていました。再度失敗したら、Firefox は TLS 1.0 を使用して接続しようとしていました。これに失敗した場合は、さらに古いプロトコル SSL 3.0 を使用していましたが、POODLE セキュリティ問題で SSL 3.0 の安全性が問題となったため、これはデフォルトでは無効になっています。

Firefox 38 は、デフォルトでは、TLS 1.2 を使用した最初の接続に失敗した場合は再試行は行いません。Firefox 38 は、 サーバーが TLS ハンドシェイクプロトコルを使用してこれらのバージョンをネゴシエートしようとした場合は、バージョンが古い TLS 1.1 および 1.0 の使用を許可します。

これは、デフォルトでは、Firefox 38 は TLS intolerant であるサーバーには有効ではないことを示しています。これは、TLS fallback でセキュリティ問題を対処するために意図された動作です。

この新しいデフォルトが導入された理由は、MITM 攻撃者が自動再試行を悪用して、TLS 1.2 をサポートするクライアントと、TLS 1.2 をサポートするサーバーが TLS 1.0 などの古いプロトコルを利用するように仕向けていたからです。

Firefox が再試行すると、攻撃者は TLS 1.2 を使用した通信の試みをブロックし、サーバーにも通知しません。この時、Firefox は、サーバーで TLS 1.2 を使用しないものと判断し、バージョンが古い TLS を使用して再試行しようとします。

古いバージョンの TLS を使用しないように Firefox を変更すると、このような MITM 攻撃は有効ではなくなります。

TLS intolerant であるサーバーの数は年々減っていて、少数のサーバーとの互換性にしか影響しないため、Firefox などのブラウザーの開発者は、自動フォールバックを無効にすることは妥当であると考えています。また、TLS intolerant である web サーバーは TLS 仕様に従いません。

ただし、Firefox 38 を使用している場合はこの変更の影響を受ける場合があり、一部のサーバーへの接続が停止する場合もあります。

サーバーが TLS intolerant であるため接続に失敗し、サーバーが単に切断すると、Firefox は、以下のようなエラーメッセージを含むエラーページを表示する可能性があります。

"Secure Connection Failed.The connection to HOSTNAME was interrupted while the page was loading."

ただし、ネットワーク接続問題など、同様のエラーメッセージを生成する別のシナリオもあるため、この状況を診断することは重要です。エラーメッセージがサーバーに送られないため、クライアントが認識できることは接続が中断したことだけであり、その理由は分かりません。

最善の策は、開こうとしているユーザーを対処するサーバーの正確さを確認することで、エラーメッセージが引き続き発生する場合は、影響を受けているサーバーの管理者に連絡を取り、 サーバーソフトウェアに互換性がないことを伝え、TLS プロトコルを完全にサポートするバージョンにサーバーソフトウェアをアップグレードするように依頼してください。

特定のサーバーに接続しないといけない場合は、Firefox のデフォルト動作を上書きするように Firefox を設定できます。

推奨されるメカニズムは、ホワイトリストに登録されているサーバーに対してのみ、Firefox がバージョンが古い TLS を使用して再試行するようにホワイトリスト設定を使用することです。これにより、ホワイトリストのサーバーには以前の Firefox 動作が復元されます。また、この互換性がないさまざまなサーバーに接続する必要がある場合に、すべてのホスト名を Firefox 設定に入力していると時間がかかるかもしれません。この場合、古い Firefox 動作を復元する別の設定メカニズムを使用して、すべての URL にバージョンが古い TLS をいつでも試すことができます。

この両方の手順については、以下のナレッジベースを参照してください。

https://access.redhat.com/solutions/1423443

Red Hat は、上述した変更を含む Firefox web ブラウザーに対処するために、Red Hat Enterprise Linux 5、6、および 7 に対して Red Hat Bugfix Advisories (RHBA) を 2015 年 5 月中旬にリリースします。