この文書は2017年以降更新されていません
トランスポート層の保護に関するチートシート
|
最終改訂日 (yy/mm/dd): 2015/11/19 はじめに
このチートシートでは、アプリケーションの通信を守るためにトランスポート層の保護を実装する際の単純なモデルを提供します。SSL の概念は広く知られていますが、実装に関する詳細やセキュリティ上の選択事項については十分に理解されていないことが多く、往々にしてこれが実運用における安全性の低下の原因となっています。この資料では、トランスポート層セキュリティの安全な設計と構成についての指針となる明確なルールを規定します。この資料では、Web アプリケーションと Web ブラウザー間での SSL/TLS の使用に重点を置いていますが、バックエンド、その他の非ブラウザーベースの接続でも SSL/TLS や他のネットワーク暗号化技術 (VPN など) を使用することをお勧めします。 アーキテクチャの決定通信データを保護する適切な方法を判断するには、アーキテクチャを決定する必要があります。企業向けの最も一般的な選択肢は、仮想プライベートネットワーク (VPN) か、あるいは Web アプリケーションで一般に使用されている SSL/TLS モデルです。選択するモデルは、組織個々のビジネスニーズによって決まります。たとえば、2 社間の、各種プロトコルを介した共有サーバーへの相互アクセスを含む連携には、VPN 接続が最適な設計でしょう。 逆に、インターネット向けのエンタープライズ Web アプリケーションは、おそらく SSL/TLS モデルが最適と思われます。 この資料では、SSL/TLS モデルを選択する場合の、セキュリティ上の検討事項に重点を置いています。これは、一般向けの Web アプリケーションでよく使用されるモデルです。 SSL/TLS によるトランスポート層の保護利点トランスポート層セキュリティ (TLS) の最大の利点は、クライアント (Web ブラウザー) と Web アプリケーションサーバー間、および Web アプリケーションサーバーとバックエンドおよび他の非ブラウザーベースのエンタープライズコンポーネント間での通信時に Web アプリケーションデータを不正な開示や改ざんから保護できる点にあります。 TLS のサーバー検証コンポーネントがクライアントに対するサーバーの認証を提供します。クライアント側の証明書を要求するように構成された場合、TLS はサーバーに対するクライアント認証の役割も果たします。ただし実際には、ユーザー名とパスワードによる認証の代わりにクライアント証明書による認証が使用されることは、あまりありません。 見過ごされがちですが、TLS には他にも 2 つの利点があります。完全性の保証とリプレイの防止です。TLS 通信ストリームには、暗号化されたデータのあらゆる部分の改ざんを防ぐ制御が組み込まれています。また、TLS データのストリームをキャプチャして使うリプレイ攻撃の対策も組み込まれています。 TLS が前述の保証を提供するのは通信中のデータに対してであることに注意してくだい。保存されたデータに対しては、上に挙げたどのセキュリティ上のメリットも TLS はもたらしません。したがって、アプリケーション内やデータストア内に保存されているデータを保護するための適切なセキュリティ対策を追加する必要があります。 基本要件TLS を使用するための基本要件は、公開鍵インフラストラクチャ (PKI) にアクセスして証明書を取得できること、ディレクトリまたはオンライン証明書ステータスプロトコル (OCSP) レスポンダーにアクセスして証明書失効ステータスを確認できること、および各プロトコルバージョンとそのプロトコルオプションの最小構成をサポートできることです。 SSL と TLSSSL (Secure Socket Layer) と TLS (Transport Layer Security) という用語は、多くの場合、区別なく使用されます。事実、SSL v3.1 は TLS v1.0 に相当します。しかし、最新の Web ブラウザーや最新の Web フレームワークおよびプラットフォームでサポートされている SSL と TLS のバージョンはさまざまです。このチートシートでは、この技術を総称して TLS と呼ぶことにします。SSL プロトコルと TLS プロトコルの使用に関する推奨事項とブラウザーの TLS 対応については、「強固なプロトコルだけをサポートする」というタイトルのルールにまとめてあります。  FIPS 140-2 認定暗号モジュールをいつ使用すべきかWeb アプリケーションが高度なスキルと明確な動機を持つ攻撃者の標的になる可能性がある場合 (機密データを扱うインターネットアクセス型アプリケーションの一般的な脅威モデル)、FIPS 140-2 認定の暗号モジュールを使った TLS サービスの使用を強くお勧めします。 暗号モジュールは、ソフトウェアライブラリの場合もハードウェアデバイスの場合も、基本的に 3 つの部分で構成されています。
暗号モジュールとそのサービス (および暗号モジュールを呼び出す Web アプリケーション) のセキュリティは、これら 3 つの構成要素それぞれの適切な実装と統合にかかっています。また、暗号モジュールは安全に使用し、安全にアクセスする必要があります。これには、以下への配慮が含まれます。
TLS のメリットを活かすには、FIPS 140-2 の認定を受けた TLS サービス (ライブラリ、Web フレームワーク、Web アプリケーションサーバーなど) を使用することが重要です。また、FIPS 140-2 認定暗号モジュールが所定のセキュリティサービスを想定どおりに提供できるよう、暗号モジュールのインストール、構成、運用は承認または許可された方法にしたがって行う必要があります。 FIPS 140-2 暗号の使用が法的に要求されるシステム (米国政府またはその代理機関が所有または運用するシステムなど) では、SSL を無効にし、必ず TLS を使用することが必要です。SSL が認められない理由については、「Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program」の第 7.1 項に詳しく説明されています。 高度なスキルと明確な動機を持つ攻撃者から機密データを守るために TLS を使用する方法の詳細については、「SP800-52 Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations」を参照してください。 安全なサーバー設計ルール: すべてのログインページとすべての認証済みページに TLS を使用するログインページとそれ以降のすべての認証済みページは、TLS 経由でのみアクセスする必要があります。最初のログインページ ("ログインランディングページ" と呼ばれます) は、TLS 経由で提示する必要があります。ログインランディングページに TLS を使用していないと、攻撃者がログインフォームの動作を変更して、ユーザーの資格情報を任意の場所に書き込むことが可能になります。ログイン後の認証済みのページに TLS を使用していないと、攻撃者が暗号化されていないセッション ID を確認して、ユーザーの認証済みのセッションを侵害できるようになります。 ルール: 機密データを通信するすべてのネットワーク (外部および内部) で TLS を使用する機密データを通信するすべてのネットワーク (外部と内部の両方) で TLS または同等のトランスポート層セキュリティメカニズムを使用する必要があります。内部ネットワークへのアクセスは "従業員だけに限定" されていると主張しても、それだけでは十分とはいえません。最近発生した多くのデータ漏えいは、内部ネットワークも攻撃者に侵害される可能性があることを示しています。これらの攻撃では、社内ネットワーク上に送信される暗号化されていない機密データにアクセスするためにスニファーがインストールされていました。 ルール: 安全を確保したコンテンツに対して非 TLS ページを用意しないTLS 経由で提供されるページは、いずれも非 TLS 接続経由でアクセスできてはいけません。アプリケーションの認証済み部分にある HTTP ページ (例: http://example.com/myaccount) をユーザーがうっかりブックマークしたり、手入力したりする可能性があります。このリクエストがアプリケーションによって処理されると、応答と機密データがプレーンテキストの HTTP 経由でユーザーに返されます。 ルール: TLS コンテンツと非 TLS コンテンツを混在させないTLS 経由で提供されるページは、TLS 経由で送信されるコンテンツだけで構成する必要があります。このページには、暗号化されていない HTTP 経由で送信されるコンテンツを一切含めないでください。これには、関連のないサードパーティサイトのコンテンツも含まれます。 攻撃者が暗号化されていない HTTP 経由で送信されるあらゆるデータを傍受し、悪意のあるコンテンツをユーザーのページに挿入するおそれがあります。この悪意のあるコンテンツは、ページ全体が TLS 経由で提供されていても、ページに挿入される危険があります。また、非 TLS リクエストとともに送信されるユーザーのセッション Cookie を攻撃者が盗む可能性もあります。これが可能なのは、Cookie の 'secure' フラグが設定されていない場合です。「ルール: Cookie の "secure" フラグを使用する」を参照してください。 ルール: Cookie の "secure" フラグを使用するすべてのユーザー Cookie に "secure" フラグを設定する必要があります。"secure" フラグを設定しないと、攻撃者がユーザーのブラウザーをだまして、サイト上の暗号化されていないページへのリクエストを送信することで、セッション Cookie にアクセスできます。この攻撃は、サーバーが HTTP コンテンツを提供するように構成されていない場合でも可能です。攻撃者はリクエストを監視しており、サーバーが 404 で応答したり、まったく応答しなくてもかまわないからです。 ルール: 機密データを URL 外に保持する機密データは、URL 引数を介して送信しないでください。より適切な場所は、機密データをサーバー側リポジトリまたはユーザーのセッション内に格納することです。TLS を使用すると、URL の引数と値が送信時に暗号化されます。しかし、URL の引数と値が露出する可能性のある方法が 2 つあります。 1.URL 全体をローカルユーザーのブラウザー履歴にキャッシュする。これにより、機密データがワークステーションの他のユーザーに露出する可能性があります。 2.ユーザーが別の HTTPS サイトへのリンクをクリックすると、URL 全体が露出する。これにより、サードパーティサイトへの参照フィールド内にある機密データが露出する可能性があります。この露出はほとんどのブラウザーで発生し、2 つの TLS サイト間の遷移時にのみ発生します。 たとえば、ユーザーが https://example.com にある https://someOtherexample.com へのリンクを辿ると、(ほとんどのブラウザーの) 参照ヘッダーで https://example.com の URL 全体 (URL 引数を含む) が露出します。https://example.com にある http://someHTTPexample.com へのリンクを辿った場合は、これに該当しません。 ルール: 機密データのキャッシュを防止するTLS プロトコルは、通信中のデータについてのみ機密性を確保します。クライアントや中継プロキシにおける潜在的なデータ漏えいの問題解決には役立ちません。したがって、多くの場合、これらのノードでは機密データをキャッシュしたり、永続化したりしないように指示するのが賢明です。選択肢の 1 つとして、該当する HTTP 応答にキャッシュ防止ヘッダーを追加する方法があります (たとえば、"Cache-Control: no-cache, no-store" と "Expires: 0" で、2013 年時点の多くの最新ブラウザーに対応できます)。HTTP/1.0 との互換性 (つまり、ユーザーエージェントが非常に古いときや、Web サーバーが互換性対策として HTTP/1.0 を強制しているとき) のために、応答には "Pragma: no-cache" ヘッダーも追加してください。詳細については、第 14.9 項の「HTTP 1.1 RFC 2616」を参照してください。 ルール: HTTP Strict Transport Security を使用する参照: HTTP Strict Transport Security ルール: 公開鍵のピン留めを使用する参照: 証明書と公開鍵のピン留め
サーバー証明書注: FIPS 140-2 暗号モジュールを使用している場合は、以下のルールを無視して、特定の暗号モジュールの推奨構成に従ってください。その場合も、以下のルールを利用して構成を監査することをお勧めします。 ルール: 強力な鍵を使用し、鍵を保全する暗号鍵の生成に使用するプライベート鍵は、プライベート鍵の予定有効期間および対応する証明書に対して十分な強度を備えている必要があります。現時点のベストプラクティスは、2048 ビット以上の鍵サイズを選択することです。鍵の有効期間と鍵の比較強度の追加情報については [1]、NIST SP 800-57 を参照してください。また、プライベート鍵は、不正アクセスから保護された場所に保管する必要があります。 ルール: 必要なドメイン名に対応した証明書を使用するユーザーに対して証明書エラー (ドメインまたはホスト名の不一致を解消するように求めるプロンプトを含む) や、有効期限の切れた証明書を提示することは絶対にしないでください。アプリケーションが https://www.example.com と https://example.com のどちらでも使用できる場合は、適切な 1 つまたは複数の証明書を提示してこの状況に対処する必要があります。証明書エラーがあると、ユーザーが TLS エラーメッセージに対して鈍感になり、攻撃者が信ぴょう性のあるフィッシング攻撃や中間者攻撃を仕掛ける可能性が高くなります。 たとえば、ある Web アプリケーションが https://abc.example.com と https://xyz.example.com でアクセスできるとします。ホスト (サーバー) abc.example.com 用の証明書と、ホスト (サーバー) xyz.example.com 用の証明書をそれぞれ取得する必要があります。どちらの場合も、ホスト名がサブジェクトのコモンネーム (CN) に入っています。 または、サブジェクトの別名 (SAN) を使用して、証明書が有効である複数の名前を明示的にリスト化することもできます。上の例では、証明書のサブジェクトの CN として example.com が記載され、SAN としてabc.example.com と xyz.example.com の 2 つが記載されます。このような証明書を "複数ドメイン証明書" と呼ぶこともあります。 ルール: 証明書では完全修飾名を使用するDNS 名フィールドでは完全修飾名を使用します。修飾されていない名前 ('www' など)、ローカル名 ('localhost' など)、プライベート IP アドレス (192.168.1.1) を DNS 名フィールドでは使用しないでください。修飾されていない名前、ローカル名、プライベート IP アドレスは証明書の仕様に違反しています。 ルール: ワイルドカード証明書を使用しないワイルドカード証明書の使用は控えてください。ワイルドカード証明書は、厄介なユーザープロンプトを回避する便法ですが、最小権限の原則にも反するほか、開発者のマシンやロビーにある秘書のマシン、サインインキオスクを含むすべてのマシンを信頼するようユーザーに要求することになります。プライベート鍵へのアクセスの取得というハードルが攻撃者にはまだ残っていますが、無防備な状態でファイルシステムに保存されていれば、相当に簡単になります。 Qualys 社が Internet SSL Survey 2010 のために収集した統計によれば、ワイルドカード証明書のシェアは 4.4% です。したがって、ワイルドカード証明書の使用は、公衆ネットワークにつながるホストでは標準的ではありません。最後に、ワイルドカード証明書は EV 証明書ガイドライン に違反しています。 ルール: 証明書では RFC 1918 アドレスを使用しない証明書ではプライベートアドレスを使用しないでください。RFC 1918 は プライベートネットワークのアドレス割り当てです。プライベートアドレスは IANA (Internet Assigned Numbers Authority) によって予約されており、192.168/16、172.16/12、および 10/8 が含まれます。 プライベートアドレスで発行された証明書は EV 証明書ガイドラインに違反します。また、Peter Gutmann 氏が『Engineering Security』で次のように述べています。「これは特に厄介である。なぜなら、ルーター侵害攻撃 (中略) と (中略) OSCP 攻略法を組み合わせることで、攻撃者は任意の EV 証明書サイトになりすますことができるからだ。」 ルール: アプリケーションのユーザーベースに適切な認証機関 (CA) を使用するアプリケーションユーザーに対して、この証明書は不明か信頼できない機関によって署名されたという警告が絶対に提示されないようにする必要があります。アプリケーションの全ユーザーが、サーバーの証明書を発行した認証機関の公開証明書にアクセスできることが必要です。インターネットにアクセス可能な Web サイトの場合、この目的を達成する最も効果的な方法は、公認の認証機関から TLS 証明書を購入することです。一般的なインターネットブラウザーには、このような公認認証機関の公開証明書があらかじめ組み込まれています。 ユーザー数が限られた社内用アプリケーションでは社内の認証機関を使用できますが、その公開証明書を全ユーザーに安全に配布することが前提となります。ただし、この認証機関が発行するすべての証明書をユーザーが信頼することになるので注意してください。このため、徹底した制御によってプライベート鍵を保護し、許可された人間だけが証明書に署名できることを確保します。 自己署名証明書の使用は絶対に認められません。自己署名証明書はエンドポイント認証の利点を打ち消すだけでなく、ユーザーが中間者攻撃を検知する能力を低下させます。 ルール: 必要なすべての証明書を常に提供するクライアントは、サーバーまたはホストの識別という問題を PKI または X509 証明書によって解決しようとします。ユーザーがサーバーまたはホストの証明書を受け取った時点で、その証明書の正当性を、信頼されたルート証明機関まで遡って検証できることが必要です。これをパス検証といいます。 エンドエンティティ (サーバーまたはホスト) 証明書とルート証明書の間に 1 つ以上の中間証明書が介在する場合があります。両方のエンドポイントの検証に加え、ユーザーはすべての中間証明書も検証する必要があります。ユーザーがすべての中間証明書をローカルに保有していない可能性もあるため、この検証は難しい場合があります。これは周知の PKI の課題であり、"Which Directory?" 問題と呼ばれています。 この "Which Directory?" 問題を回避するには、パス検証で使用される必要なすべての証明書をサーバーからユーザーに提供する必要があります。 SHA-1 の廃止計画に注意し、その対策を講じる段階的な証明書の警告がエンドユーザーに提示されないように、ブラウザーベンダーの今後の SHA-1 廃止計画に組織として事前に対応しておく必要があります。現時点では、おそらく Google Chrome の計画が最も具体的かつ積極的なものです (「Gradually sunsetting SHA-1」を参照)。 所属組織で SHA256 との互換性の問題がなければ、サイトを SHA256 署名証明書 / チェーンに移行するのが妥当でしょう。問題があるか、その可能性がある場合は、SHA-1 証明書が 2017/01/01 までに失効するように徹底してください。 サーバーのプロトコルと暗号アルゴリズムの構成注: FIPS 140-2 暗号モジュールを使用している場合は、以下のルールを無視して、特定の暗号モジュールの推奨構成に従ってください。その場合も、以下のルールを利用して構成を監査することをお勧めします。 ルール: 強力なプロトコルのみをサポートするSSL/TLS は複数のプロトコルの集合です。SSLv2 と SSLv3 を含む旧 SSL プロトコルには脆弱性が見つかっています。したがって、SSL バージョン 1、2、および 3 は今後使用しないください。トランスポート層を保護するためのベストプラクティスは、TLS プロトコル (TLS 1.0、TLS 1.1、および TLS 1.2) だけをサポートすることです。この構成は、高度なスキルと明確な動機を持つ攻撃者に対し最大の防御を提供し、機密データを扱うアプリケーションや危険な操作を行うアプリケーションに適しています。 ほぼすべての最新ブラウザーは、少なくとも TLS 1.0 をサポートしています。2014 年 2 月現在、最新の各ブラウザー (Chrome v20 以上、Firefox v27 以上、IE v8 以上、Opera v10 以上、および Safari v5 以上) は TLS 1.1 と TLS 1.2 をサポートしています。これらのプロトコルをサポートするクライアントに対応するために、TLS 1.1 と TLS 1.2 をサポートしてください。クライアントとサーバーは通常、双方でサポートされている最適なプロトコルをネゴシエートします。 最新バージョンに更新されていない多くのブラウザーでは、まだ TLS 1.0 が "最適な" プロトコルとして広く使用されています。TLS 1.0 は、CBC 連鎖攻撃やパディングオラクル攻撃を受けます。リスク分析とリスク許容を経ない限り、TLSv1.0 は使用しないでください。PCI DSS 3.1 では、2016 年 6 月 30 日以降の TLS 1.0 の使用を禁止しています。 プロトコルの選択肢として SSLv2 と SSLv3 は絶対に有効にしないでください。
ルール: 短期鍵交換を優先する短期鍵交換は Diffie-Hellman を基にしており、最初の SSL/TLS ハンドシェイクの際にセッションごとの一時鍵を使用します。短期鍵交換は、Perfect Forward Secrecy (PFS) を提供します。これは、サーバーの長期署名鍵が暴露しても、過去のセッションの機密性は侵害されないことを意味します (次のルールを参照)。短期鍵を使用する場合、サーバーは長期鍵を使用して一時鍵に署名します (長期鍵はサーバーの証明書に含まれている通常の鍵です)。 証明書でサポートされている鍵長に一致する安全な長さを使用する暗号パラメーター (DH パラメーターなど) を使用してください (2048 ビット以上または同等の楕円曲線)。この点について問題のあるミドルウェアもあるので、最新バージョンにアップグレードしてください。 注: 古いブラウザーや古い Java バージョンの中には、1024 ビットを超える DH パラメーターを処理できないものもあります。これを解決する方法については、次のルールを参照してください。 RFC 2409、3526、または 5114 で定義されているような標準化された DH パラメーターを使用しないでください。独自の DH パラメーターを生成して、一意の素数を取得してください (これには長い時間がかかる場合があります)。 openssl dhparam 2048 -out dhparam2048.pem このパラメーターファイルを使用してパスを設定します (Apache の使用時など)。 SSLOpenSSLConfCmd DHParameters <dhparam2048.pem のパス> サーバーファームを所有し、Forward Secrecy (前方秘匿性) を提供している場合は、セッションの再開を無効にすることが必要になる可能性があります。たとえば、Apache では、ファーム内のすべてのサーバーがセッションの再開に参加できるように、セッション ID とマスターシークレットをディスクに書き込みます (現時点では、共有を実現するインメモリメカニズムはありません)。セッション ID とマスターシークレットをディスクに書き込むと、Forward Secrecy が損なわれます。 ルール: 強力な暗号アルゴリズムのみをサポートする各プロトコル (TLSv1.0、TLSv1.1、TLSv1.2 など) には暗号スイートが用意されています。TLS 1.2 の時点では、各国のバニティ暗号スイートも含め、320 以上のスイートがサポートされており、今も増え続けています。TLS セッション内で使用される暗号の強度は、サーバーとブラウザー間でネゴシエートされる暗号アルゴリズムによって決まります。強力な暗号アルゴリズムのみが選択されるようにするには、サーバーの設定を変更して、弱い暗号アルゴリズムの使用を無効にするとともに、暗号アルゴリズムを適切な順序で構成する必要があります。強力な暗号アルゴリズムだけをサポートし、十分に大きな鍵サイズを使用することをお勧めします。一般に、暗号スイートの選択にあたっては、以下の点に注意してください。
openssl ciphers -v "EDH+aRSA+AESGCM:EDH+aRSA+AES:DHE-RSA-AES256-SHA:EECDH+aRSA+AESGCM:EECDH+aRSA+AES:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:RSA+AESGCM:RSA+AES+SHA:DES-CBC3-SHA:-DHE-RSA-AES128-SHA" 0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x39 - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
注:
追加情報については、TLS 1.2 RFC 5246、SSL Labs: SSL/TLS Deployment Best Practices、BSI: TR-02102 Part 2 (ドイツ語)、ENISA: Algorithms, Key Sizes and Parameters Report、RFC 7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)、および FIPS 140-2 IG を参照してください。 ルール: 相互認証のための TLS-PSK と TLS-SRP をサポートする共有シークレットまたは共有パスワードを使用するときは、TLS-PSK (Pre-Shared Key) または TLS-SRP (Secure Remote Password) を提供します。これらは PAKE (Password Authenticated Key Exchange) と呼ばれます。TLS-PSK と TLS-SRP は適切にチャネルをバインドします。つまり、外部トンネルと内部認証プロトコル間の暗号バインドです。IANA では現在、79 PSK 暗号スイートと 9 SRP 暗号スイートを予約しています。 基本認証では、サーバー自身の認証後、ユーザーのパスワードがプレーンテキストで送信されます。基本認証は一方向の認証しか提供しません。これに対し、TLS-PSK と TLS-SRP はいずれも相互認証を提供します。つまり、パスワードをプレーンテキストで送信することなく、パスワードを認識していることを双方が証明します。 最後に、PAKE を使用すると、証明機関 (CA) など、外部の第三者に頼る必要がなくなります。 ルール: 安全な再ネゴシエーションのみをサポートするCVE-2009-3555 として識別されている、TLS の設計上の脆弱性により、攻撃者は任意のプレーンテキストを標的者の TLS セッションに挿入できます。HTTPS コンテキストでは、攻撃者が標的者の代わりに独自の HTTPS リクエストを挿入できる可能性があります。この問題は、TLS のサポートを無効にするか、RFC 5746 に準拠した再ネゴシエーションのみをサポートすることで対処できます。最新のすべてのブラウザーは、アップデートにより、この RFC に準拠しています。 ルール: 圧縮を無効にするCRIME (Compression Ratio Info-leak Made Easy) は、TLS プロトコルと SPDY プロトコルで使用されているデータ圧縮方式の攻略手段です。この攻略手段により、敵対者は HTTPS からユーザー認証 Cookie を回復できます。その後、回復された Cookie がセッションハイジャック攻撃に利用されるおそれがあります。 TLS/SSL のセットアップ全体と証明書のテストここでは、最も一般的な参照先のみを示します。その他のツールについては、「ツール」を参照してください。
クライアント (ブラウザー) の構成証明書が有効であることを確認するための検証手順は複雑で、適切に実行するのは困難です。標準的な Web アプリケーションモデルでは、この確認はクライアントの Web ブラウザーによってローカルなブラウザー設定に基づいて実行されるので、アプリケーションの管理外です。ただし、次のような場合には、これらの要素に対処する必要があります。
以上の場合、証明書の信ぴょう性を確かめるには、幅広い証明書妥当性チェックを行う必要があります。この機能の設計とテストに役立つ以下の資料を参照してください。NIST PKI Testing サイトには、証明書の完全なテストスイートとテストケースの望ましい結果が含まれています。 上のガイダンスに明記されているように、何らかの理由で証明書が検証できない場合は、クライアントとサーバー間の接続を削除する必要があります。証明書が適切に検証されていない接続を介して交換されたデータは、不正アクセスや改ざんを受ける可能性があります。 その他の制御Extended Validation 証明書業界の底辺競争に伴い、Extended Validation 証明書 (EV 証明書) の発行にあたっては、発行者による申請者の広範な審査が行われます。EV 証明書の目的は、証明書の所有者がそのサイトの確認済みの法人であるとの確実な保証をユーザーに与えることです。EV 証明書に対応しているブラウザーは、EV 証明書をさまざまな方法で区別します。Internet Explorer は URL の部分を緑色で表示します。Mozilla は URL の左側に緑色の部分を追加して会社名を表示します。 高価値の Web サイトでは、EV 証明書の使用により、証明書に対する顧客の信頼度を高めることを検討してください。ただし、EV 証明書は TLS の技術的な安全性を高めるわけではないので注意してください。EV 証明書の目的は、対象のサイトが本物であるというユーザー側の信頼感を高めることにあります。 クライアント側の証明書TLS でクライアント側証明書を使用すると、クライアントの同一性をサーバーに証明できます。"相互 TLS" と呼ばれるこの構成では、サーバーが自らの証明書をクライアントに提示するだけでなく、クライアントも自らの証明書をサーバーに提示する必要があります。クライアント証明書を使用する場合は、前述のサーバー証明書の検証と同様のクライアント証明書の検証がサーバーで必ず実行されるようにします。また、クライアント証明書が検証できないか、提示されない場合は、TLS 接続を削除するようにサーバーを構成してください。 現時点では、証明書生成 / 安全な配布 / クライアント側の構成 / 証明書の失効と再発行が複雑であること、およびクライアントが認証できるのはクライアント側証明書がインストールされたマシン上だけであることから、クライアント側証明書の使用は比較的まれです。クライアント側証明書は、ユーザー数が少ない非常に高い価値を伴う接続で使用するのが一般的です。 証明書と公開鍵のピン留めハイブリッドアプリケーションおよびネイティブアプリケーションでは、証明書と公開鍵のピン留めを活用できます。ピン留めは、ホスト (サーバーなど) をアイデンティティ (証明書や公開鍵など) に関連付けます。これにより、アプリケーションは既存のリレーションシップの知識を利用できるようになります。実行時、アプリケーションはサーバーへの接続後に受け取った証明書または公開鍵を検証します。証明書または公開鍵が想定どおりであれば、アプリケーションは通常どおり続行します。想定外であった場合は、敵対者がチャネルまたはサーバーを制御している可能性があるので、アプリケーションはそのチャネルの使用を停止し、接続を閉じます。 ピン留めしても、失効などの通例の X509 チェックが引き続き必要とされますが、これは CRL と OCSP がリアルタイムのステータス情報を提供するためです。これ以外の場合、アプリケーションは (1) 既知の不正な証明書を受け入れるか、(2) アウトオブバンド方式の更新を要求できます。これには、App Store の承認に長い時間がかかる可能性があります。 大部分のブラウザーは既存のリレーションシップや演繹的な知識の活用をユーザーに許可していなため、ブラウザーベースのアプリケーションは不利です。また、JavaScript と WebSocket は、基となるセキュアな接続の情報 (証明書、公開鍵など) を問い合わせるメソッドを Web アプリケーションに公開していません。注目すべき点として、Chromium ベースのアプリケーションは特定のサイトでピン留めを実行しますが、そのリストは現在ベンダーによって管理されています。 詳細については、「ピン留めに関するチートシート」を参照してください。 バックエンドなどの接続に対するトランスポート層の保護このチートシートの主題からは外れますが、機密データの交換やユーザー ID の確認が行われるバックエンド接続およびその他すべての接続には、トランスポート層の保護が必要であることを強調しておかなければなりません。効果的で堅牢なトランスポート層セキュリティを実装しないと、機密データが漏えいし、認証やアクセス制御のあらゆるメカニズムの有効性が損なわれます。 安全な社内ネットワークという誤解企業の社内ネットワークも攻撃を免れてはいません。何千もの機密の顧客記録が漏えいした、最近の人目を引く侵入の多くは、社内ネットワークにアクセスした攻撃者がスニファーを使用して、社内ネットワークを流れる暗号化されていないデータを傍受する方法で実行されました。 バックエンドなどの接続に対するプロトコルと暗号アルゴリズムの構成クライアントとサーバー間の通信だけでなく、サーバー同士の通信にも TLS を提供することが重要です。サーバーのプロトコルと暗号アルゴリズムの構成に従って、バックエンドなどの接続に使用されるサーバーのクライアント側構成の安全性を確保します。安全でないプロトコルと暗号アルゴリズムを必ず無効にしてください(サーバーが "クライアント" として機能するときは、最小限の強固な構成のみをサポートするなど)。 ツールローカル / オフラインオンライン
関連資料
Authors and Primary EditorsTorsten Gigler - torsten.gigler[at]owasp.org Other CheatsheetsDeveloper Cheat Sheets (Builder)
Assessment Cheat Sheets (Breaker)
Mobile Cheat Sheets OpSec Cheat Sheets (Defender) Draft Cheat Sheets
|
