このセクションでは、SSL 制御機能を計画、設計、実装、および管理する方法について説明します。
図 45. HTTP over SSL 通信
SSL を使用すると、HTTPS セッションの確立時にクライアントから要求された URL (Uniform Resource Locator、例えば https://www.mysonicwall.com など) を含むすべてのペイロードをはっきりわからないようにするという、セキュリティ上の効果が得られます。これは、HTTPS を使用すると、暗号化された SSL トンネルを使用して HTTP が転送されるからです。SSL セッションが確立される (Figure 45 の手順 14) まで実際の対象リソース (www.mysonicwall.com) がクライアントによって要求されることはありませんが、SSL セッションが確立した後に、ファイアウォールやその他の中間機器がセッション データを検査することはできません。このため、URL ベースのコンテンツ フィルタ システムでは、IP アドレス以外の方法で要求を検査して、許可するかどうかを決定することはできません。
|
SSL 制御機能によってポリシー違反が検出された場合に、イベントをログに記録して接続を遮断することができます。 あるいは、イベントをログに記録するだけで接続を継続することもできます。 |
|
•
|
SSL － セキュア ソケット レイヤ (SSL) は、Netscape が 1995 年に導入したネットワーク セキュリティ メカニズムです。SSL は、2 つの通信アプリケーション (クライアントおよびサーバ) 間でのプライバシーの確保と、サーバ (および必要に応じてクライアント) の認証を目的としていました。SSL の最も有名なアプリケーションは HTTPS です。http:// の代わりに https:// で始まる URL によって指定される HTTPS は、インターネット上のウェブ トラフィックを暗号化する標準的な方式として認知されています。SSL HTTP 転送では一般的に TCP ポート 443 が使用されますが、通常の HTTP 転送では TCP ポート 80 が使用されます。SSL は HTTPS で最もよく知られていますが、SSL の使用用途は HTTP のセキュリティ保護に限られたものではありません。SSL は、SMTP、POP3、IMAP、および LDAP などのその他の TCP プロトコルのセキュリティ保護にも使用することができます。詳細については、
http://wp.netscape.com/eng/security/SSL_2.html を参照してください。SSL セッションの確立は、以下のように行われます。 |
図 46. SSL セッションの確立
|
•
|
SSLv2 － SSL の初期バージョンですが、現在も一般的に使用されています。SSLv2 では、いくつかの脆弱性、制限、および理論上の欠陥 (SSLv3 についての説明で比較します) が指摘されていて、セキュリティに厳格な人々の冷笑、軽蔑の対象であり、軽視されるのが当然とみなされています。
|
|
•
|
SSLv3 － SSLv3 は SSLv2 との下位互換性を保ちつつ、以下の点を改善する目的で作成されました。
|
|
•
|
MAC － MAC (メッセージ認証コード) は、(MD5 または SHA1 のような) アルゴリズムをデータに適用して算出されます。MAC はメッセージ ダイジェストつまり一方向性ハッシュ コードであり、算出は非常に簡単ですが、実際に不可逆的なコードです。言い換えると、MAC だけを使用して、ダイジェストの元になっているメッセージを割り出すことは理論上不可能です。同様に、同一のMAC が算出される 2 つの異なるメッセージを見つけることも困難です。ある所定のデータに関して、受信側で算出された MAC が送信側で算出された MAC と一致する場合、受信側では、転送中にデータが変更されなかったとみなすことができます。
|
|
•
|
Client Hello － TCP セッションの確立後、クライアントからサーバに送信される最初のメッセージ。このメッセージにより SSL セッションが開始されます。 メッセージは次の要素で構成されています。
|
|
•
|
バージョン － クライアントが通信での使用を希望する SSL のバージョン。通常は、クライアントでサポートされている SSL の最新バージョンです。
|
|
•
|
乱数 － 32 ビットのタイムスタンプに 28 バイトの乱数構造を組み合わせたもの。
|
|
•
|
セッションID － セッション ID データが存在しない場合は空 (基本的に新しいセッションの要求の場合) です。 あるいは、前に発行されたセッション ID を表します。
|
|
•
|
暗号スイート － クライアントでサポートされる暗号化アルゴリズムのリストで、優先する順番に並んでいます。
|
|
•
|
圧縮方式 － クライアントでサポートされる圧縮方式のリストです (通常はヌル)。
|
|
•
|
Server Hello － Client Hello に対する SSL サーバの応答。SSL 制御機能によって検査が行われるのは SSL 交換のこの部分です。Server Hello には、セッションでネゴシエートされた SSL のバージョン、暗号、セッション ID、および証明書の情報が含まれています。X.509 サーバの実際の証明書自体は、SSL 交換の別の手順で使用されますが、通常は Server Hello と同じパケットで開始されます (終了も同じ場合があります)。
|
|
•
|
証明書 － X.509 の証明書は、電子的なセキュリティを確保するための、不変のデジタル スタンプです。証明書には、主に 4 つの特性があります。
|
|
•
|
サブジェクト － 共通名 (CN) で識別される証明書の保証。クライアントが https://www.mysonicwall.com のような SSL サイトをブラウズした場合、サーバからサーバの証明書が送信され、クライアントで評価されます。クライアントでは、証明書の日付が有効であること、信頼できる CA によって発行された証明書であること、サブジェクトの CN が 要求したホスト名に一致すること (つまり両方とも"www.mysonicwall.com"であること) が確認されます。サブジェクトのCN が一致しないとブラウザの警告が表示されますが、これは偽装行為の確かな証拠とは限りません。例えば、クライアントが https://mysonicwall.com をブラウズし、www.mysonicwall.com と同じ IP アドレスに解決された場合、サブジェクトの CN がwww.mysonicwall.com と記載されている証明書がサーバから示される場合があります。この場合、接続が完全に適切であるにもかかわらず、クライアントに警告が表示されます。
|
|
•
|
認証局 (CA) － 認証局 (CA) は、証明書のサブジェクトの識別情報を確認することを主な目的として、証明書に署名することができる信頼できる団体です。よく知られている認証局には、VeriSign、Thawte、Equifax、Digital Signature Trust などがあります。一般的に、SSL フレームワークにおいて CA が信頼できると判断されるためには、ほとんどのウェブ ブラウザ、オペレーティング システムおよびランタイム環境で使用されているように、その証明書が信頼できるストアに格納されている必要があります。SonicOS の信頼できるストアには、「システム > 証明書」ページからアクセスできます。CA モデルは信頼の積み重ねに基づいています。 つまり、クライアントは (信頼できるストアに CA の証明書があることによって) CA を信頼し、CA は (証明書ごとにサブジェクトを発行することによって) サブジェクトを信頼するため、クライアントがサブジェクトを信頼する、ということになります。
|
|
•
|
信頼できない CA － 信頼できない CA とは、クライアントの信頼できるストアに含まれていない CA のことです。SSL 制御機能における信頼できない CA とは、証明書が「システム > 証明書」にない CA のことです。
|
|
•
|
自己署名証明書 － 発行者の共通名とサブジェクトの共通名が同一の証明書で、証明書に自己署名されていることを意味します。
|
|
•
|
仮想ホスティング － 1 つのサーバで複数のウェブ サイトをホスティングするために、ウェブ サーバで使用されている方式。一般的な仮想ホスティング実装は名前ベース (ホスト ヘッダー) の仮想ホスティングで、1 つの IP アドレスで複数のウェブ サイトをホスティングできます。ホスト ヘッダー仮想ホスティングでは、サーバがクライアントから送信された"Host:"ヘッダーを評価して、要求されたサイトを判断します。例えば、www.website1.com と www.website2.com が両方とも64.41.140.173 に解決されるとします。この場合に、クライアントが"GET /"とともに"Host: www.website1.com"を送信すると、サーバからそのサイトに該当するコンテンツが返されます。
|
|
•
|
脆弱な暗号 － 相対的に脆弱な対称暗号。暗号が 64 ビット未満の場合、脆弱と分類されます。ほとんどの場合、エクスポート暗号は脆弱な暗号です。以下に、脆弱な暗号のリストを示します。
|
|
2
|
組織独自のプライベート認証局 (CA) を導入している場合は、プライベート CA の証明書を「システム > 証明書」ストアにインポートすることを強くお勧めします (特に、信頼できない CA によって発行された証明書の遮断を有効にする場合)。この処理の詳細については、「システム > 証明書」のセクションを参照してください。
|
|
4
|
Server Hello の断片化 － SSL サーバによって Server Hello が断片化されることがまれにあります。この場合、現在の SSL 制御機能の実装では、Server Hello を復号化できません。SSL制御ポリシーが SSL セッションに適用されず、SSL セッションが許可されます。
|
|
5
|
セッションの終了処理 － SSL 制御機能では、ポリシー違反が検出されると SSL セッションを終了させますが、これは TCP 層でのセッションを終了させるに過ぎません。この時点では SSL セッションが不完全な状態であるため、クライアントのリダイレクトや、終了に関する何らかの情報通知をクライアントに行うことはできません。
|
|
6
|
ホワイトリストの優先順位 － ホワイトリストは、他のすべての SSL 制御要素より優先されます。SSL サーバ証明書がホワイトリストのエントリに一致すると、SSL セッションの他の要素が設定されたポリシーの違反に該当する場合であっても、SSL セッションの続行が必ず許可されます。これは、意図的に行われています。
|
