SSL フォワード プロキシの概要
セキュア ソケット レイヤー (SSL) は、インターネットに暗号化テクノロジを提供するアプリケーション レベルのプロトコルです。SSLは(TLS)とも呼ばれ Transport Layer Security 、プライバシー、認証、機密性、およびデータ整合性の組み合わせを通じて、クライアントとサーバー間のデータの安全な送信を保証します。SSL は、このレベルのセキュリティで、証明書と秘密キーと公開キーの交換ペアに依存します。
サーバー認証は、Web ブラウザーで Web サーバーの ID を検証できるようにすることで、不正な送信から保護します。機密性メカニズムにより、通信はプライベートになります。SSLは、データを暗号化して機密性を強制し、権限のないユーザーが電子通信を盗聴するのを防ぎます。最後に、メッセージの整合性により、通信の内容が改ざんされていないことが保証されます。
SSL フォワードプロキシは透過プロキシです。つまり、クライアントとサーバーの間でSSL暗号化と復号化を実行しますが、サーバーもクライアントもその存在を検出できません。SSL フォワード プロキシは、ペイロードを暗号化および復号化するためのキーを確実に保持します。
サーバーの場合、SSL フォワード プロキシはクライアントとして機能します - SSL フォワード プロキシは共有プリマスター キーを生成するため、暗号化および復号化するキーを決定します。
クライアントの場合、SSL フォワードプロキシーはサーバーとして機能し、SSL フォワードプロキシーは最初に元のサーバーを認証し、元のサーバー証明書の公開鍵を既知の鍵に置き換えます。次に、証明書の元の発行者を独自の ID に置き換えることによって新しい証明書を生成し、この新しい証明書を独自の公開キー (プロキシ プロファイル構成の一部として提供される) で署名します。クライアントは、このような証明書を受け入れると、証明書の公開キーで暗号化された共有プリマスター キーを送信します。SSL フォワードプロキシは元の鍵を独自の鍵に置き換えたため、共有のプリマスター鍵を受け取ることができます。復号化と暗号化は各方向(クライアントとサーバー)で行われ、キーは暗号化と復号化の両方で異なります。
図 1 は、SSL フォワードプロキシが暗号化されたペイロードでどのように機能するかを示しています。アプリケーションファイアウォール(AppFW)が設定されている場合、SSL フォワードプロキシーは、クライアントからの SSL セッションを終了する SSL サーバーとして機能し、サーバーに対して新しい SSL セッションが確立されます。デバイスは、すべての SSL 転送プロキシ トラフィックを復号化し、再暗号化します。SSL フォワード プロキシは、次のサービスを使用します。
クライアント側の SSL-T-SSL ターミネータ。
サーバー側の SSL-I-SSL イニシエーター。
設定されたAppFWサービスは、復号化されたSSLセッションを使用します。

このトピックは、次のセクションで構成されています。
プロキシ モードでサポートされている暗号方式
SSL 暗号は、暗号化暗号、認証方法、および圧縮で構成されます。 表 1 に、サポートされている暗号のリストを示します。NULL 暗号は除外されます。
以下の SSL プロトコルがサポートされています。
SSLv3
TLS1
SSL 暗号 | 鍵交換アルゴリズム | データ暗号化 | メッセージの整合性 |
---|---|---|---|
ECDHE-ECDSA-AES-256-GCM- SHA384 |
ECDHE/DSA 鍵交換 |
256 ビット AES/GCM |
SHA384 ハッシュ |
ECDHE-ECDSA-AES-128-GCM-SHA256 |
ECDHE/DSA 鍵交換 |
128 ビット AES/GCM |
SHA256 ハッシュ |
ECDHE-ECDSA-AES-256-CBC- SHA384 |
ECDHE/DSA 鍵交換 |
256ビットAES/CBC |
SHA384 ハッシュ |
ECDHE-ECDSA-AES-128-CBC-SHA256 |
ECDHE/DSA 鍵交換 |
128 ビット AES/CBC |
SHA256 ハッシュ |
ECDHE-ECDSA-AES-256-CBC-SHA |
ECDHE/DSA 鍵交換 |
256ビットAES/CBC |
SHA ハッシュ |
ECDHE-ECDSA-AES-128-CBC-SHA |
ECDHE/DSA 鍵交換 |
128 ビット AES/CBC |
SHA ハッシュ |
ECDHE-RSA-AES256-GCM-SHA384 |
ECDHE/RSA 鍵交換 |
256 ビット AES/GCM |
SHA384 ハッシュ |
ECDHE-RSA-AES256-CBC-SHA384 |
ECDHE/RSA 鍵交換 |
256ビットAES/CBC |
SHA384 ハッシュ |
ECDHE-RSA-AES256-CBC-SHA |
ECDHE/RSA 鍵交換 |
256ビットAES/CBC |
SHA ハッシュ |
ECDHE-RSA-AES128-GCM-SHA256 |
ECDHE/RSA 鍵交換 |
128 ビット AES/GCM |
SHA256 ハッシュ |
ECDHE-RSA-AES128-CBC-SHA256 |
ECDHE/RSA 鍵交換 |
128 ビット AES/CBC |
SHA256 ハッシュ |
ECDHE-RSA-AES128-CBC-SHA |
ECDHE/RSA 鍵交換 |
128 ビット AES/CBC |
SHA ハッシュ |
RSA-AES256-GCM-SHA384 |
ECDHE/RSA 鍵交換 |
256 ビット AES/GCM |
SHA384 ハッシュ |
RSA-AES256-CBC-SHA256 |
ECDHE/RSA 鍵交換 |
256ビットAES/CBC |
SHA256 ハッシュ |
RSA-AES128-GCM-SHA256 |
ECDHE/RSA 鍵交換 |
128 ビット AES/GCM |
SHA256 ハッシュ |
RSA-AES128-CBC-SHA256 |
ECDHE/RSA 鍵交換 |
128 ビット AES/CBC |
SHA256 ハッシュ |
RSA-AES128-CBC-SHA |
RSA 鍵交換 |
128 ビット AES/CBC |
SHA ハッシュ |
RSA-AES256-CBC-SHA |
RSA 鍵交換 |
256ビットAES/CBC |
SHA ハッシュ |
サーバー認証
クライアントとデバイス間の暗黙的な信頼(クライアントがデバイスによって生成された証明書を受け入れるため)は、SSLプロキシの重要な側面です。サーバー認証が侵害されないことが非常に重要です。ただし、実際には、自己署名証明書と異常のある証明書が豊富にあります。異常には、期限切れの証明書、ドメイン名と一致しない共通名のインスタンスなどが含まれます。
SSL フォワード プロキシがサーバー認証を完全に無視するように指定できます。この場合、SSL フォワード プロキシは、サーバー証明書の検証プロセス中に発生したエラー (CA 署名の検証の失敗、自己署名証明書、証明書の有効期限など) を無視します。
SSL 転送プロキシー・プロファイルの作成時に、SSL プロキシーがサーバー認証エラーを無視するかどうかを指定できます。
サーバー認証エラーを無視 しないように 指定すると、次のシナリオが発生します。
認証が成功した場合は、キーを置き換え、発行者名をプロキシ プロファイルのルート CA 証明書で構成されている発行者名に変更することで、新しい証明書が生成されます。
認証に失敗すると、接続は切断されます。
サーバー認証エラーを無視するように指定すると、次のシナリオが発生します。
メモ:このオプションを認証用に構成すると、Web サイトがまったく認証されないため、お勧めしません。ただし、このオプションを使用すると、SSL セッションがドロップされる根本原因を効果的に特定できます。
証明書が自己署名の場合は、キーのみを置き換えることによって新しい証明書が生成されます。発行者名は変更されません。これにより、証明書が無効であるという警告がクライアント ブラウザーに表示されます。
証明書の有効期限が切れている場合、または共通名がドメイン名と一致しない場合は、キーを置き換え、発行者名を SSL-PROXY に変更することで、新しい証明書が生成されます。 DUMMY_CERT:SRVR 認証エラーのために生成されます。これにより、証明書が無効であるという警告がクライアント ブラウザーに表示されます。
ルート CA
公開キー基盤 (PKI) 階層では、ルート CA は信頼パスの最上位にあります。ルート CA は、サーバー証明書を信頼できる証明書として識別します。
信頼済み CA リスト
SSL フォワードプロキシーは、クライアントとサーバー間のデータの安全な伝送を保証します。セキュア接続を確立する前に、SSL フォワード・プロキシーは 認証局 (CA) 証明書を調べて、サーバー証明書の署名を検証します。このため、サーバーを効果的に認証するには、信頼できる CA 証明書の妥当なリストが必要です。
セッションの再開
SSL セッションとは、フル・ハンドシェークの実行時に作成されるパラメーターと暗号鍵のセットのことです。接続は、セッション内で発生する会話またはアクティブなデータ転送です。完全な SSL ハンドシェークとマスター鍵の生成の計算オーバーヘッドはかなりのものです。短時間のセッションでは、SSL ハンドシェークにかかる時間がデータ転送の時間より長くなることがあります。スループットを向上させながら、適切なレベルのセキュリティーを維持するために、SSL セッション再開は、セッションをキャッシングするメカニズムを提供し、事前マスター秘密鍵や合意された暗号などのセッション情報をクライアントとサーバーの両方でキャッシュできます。キャッシュされた情報は、セッション ID によって識別されます。その後の接続では、両者は、新しいプリマスター秘密鍵を作成するのではなく、セッションIDを使用して情報を取得することに合意します。セッション再開により、 ハンドシェイク プロセスが短縮され、SSL トランザクションが高速化されます。
SSL プロキシ ログ
SSL プロキシー・プロファイルでロギングが使用可能になっている場合、SSL プロキシーは 表 2 に示すメッセージを生成できます。
ログの種類 |
説明 |
---|---|
|
SSL プロキシによってセッションがドロップされたときに生成されるログ。 |
|
軽微なエラーが発生した後でも、SSLプロキシによってセッションが処理されたときに生成されるログ。 |
|
非 SSL セッションが最初に SSL セッションと間違えられた場合に生成されるログ。 |
|
セッションが許可されたときに生成されるログ。 |
|
エラーの報告に使用されるログ。 |
|
警告の報告に使用されるログ。 |
|
一般情報のレポートに使用されるログ。 |
すべてのログには同様の情報が含まれています。メッセージ フィールドには、ログ生成の理由が含まれています。表 3 に示されている 3 つの接頭部のうちの 1 つは、メッセージのソースを識別します。その他のフィールドには、説明的なラベルが付けられています。
プレフィックス |
説明 |
---|---|
システム |
デバイスに関連するエラー、または SSL プロキシープロファイルの一部として実行されたアクションのために生成されたログ。ほとんどのログはこのカテゴリに分類されます。 |
OpenSSL エラー |
opensslライブラリによってエラーが検出された場合に ハンドシェイク プロセス中に生成されるログ。 |
証明書エラー |
証明書でエラーが検出された場合にハンドシェイク プロセス中に生成されるログ(X.509 関連のエラー)。 |