証明書の署名の置き換えについて

SonicWALLのDPI-SSLは、恐らく中間者攻撃 (man-in-the-middle attack、MITM）の技術を利用しているため、HTTPSサーバーとの通信をSonicWALLが中間者となってHTTPSの通信のパケットを見てウイルスに感染していないかをDPIエンジンでチェックしていると思われます。

SonicWALLの説明として"オリジナル証明書の署名承認局を置き換えます。"がありますが、第三者証明機関（ベリサイン等）から署名されている証明書の署名を書き換えることができるととらえることができます。

理解できない点として、第三者証明機関が署名した証明書の認証局の情報を書き換えられるという説明が分かりません。

----------------------------------------------------------------------------------------------------------------------
証明書再署名の認可
この証明書は、認可局の証明書がファイアウォールに信頼されている場合に限り、 オリジナル証明書の署名承認局を置き換えます。
認可局が信頼されていない場合、証明書は自己署名されます。
証明書のエラーを防ぐためには、DPI-SSL に保護されている機器によって信頼された 証明書を指定してください。
http://tz210j.demo.sonicwall.com/sslSpyConfigure …
----------------------------------------------------------------------------------------------------------------------

お手数をおかけしますが、この点についてご存知でしたらご教示頂けますようお願い致します。

＜確認させていただきたい点＞
1.証明書は01DCDC・・・のようになっていますが、その証明書を署名している認証局部分がどこに入っているかわかるのでしょうか。
2.証明書を署名している認証局の部分が分かる場合、証明書にある拇印の部分がそうでしょうか。もしそうだとした場合、証明書の
01DCDC・・・の中にそのまま拇印が入っているということでしょうか。

No.2 ベストアンサー 回答者： kadusaya2 回答日時： 2013/11/04 02:20

こっちにも回答しときます。

証明書をバイナリの状態で読むのはかなり大変ですよ。

証明書はASN.1で記述されていますので、「型＋サイズ＋データ」で構成されています。
証明書全体が「30H（Secuense型）」でパッケージングされていますので、最初は必ず 30H です。01H は証明書ではありません。

理論的な構成を説明すると、まず証明書は
「基本領域 ＋ 署名アルゴリズム ＋ 認証局署名」 で構成されます。
現状、署名アルゴリズムは「SHA-1 with RSA encryption」か「SHA-256 with RSA encryption」のどちらかです。
基本領域をこの署名アルゴリズムで処理した値が認証局署名になります。

基本領域はさらに「バージョン ＋ シリアル番号 ＋ 署名アルゴリズム ＋ 発行者（認証局）＋ 有効期間 ＋ 所有者 ＋ 公開鍵情報 ＋ 拡張領域」で構成されます。
CSRを作成した時の Country、Organization Name、Common Name などは所有者の中に入っています。もちろん暗号化などされていません。
発行者には認証局の Country、Organization Name、Common Name などが入っています。
バージョン ～ 所有者 の情報はいわば人間用であり、テキストの内容がそのまま記載されています。信頼チェーンの構築やアクセス制限などに使われる情報は拡張領域に入っています。
拡張領域には「認証局識別子」「鍵用途」「基本制約」「失効リスト配布場所」などが順不同で構成されています。証明書を発行した認証局の検索には「認証局識別子」が使用されます。

拇印（フィンガープリント）は証明書の中には格納されていません。証明書全体を SHA-1 や HSA-256 でハッシュした値であり、証明書全体が正常に受け取れたか（ダウンロードできたか）否かの確認に使われるのみです。
証明書が改竄されていないかの確認は、「基本領域」 を 「署名アルゴリズム」 で処理し、「認証局署名」 と比較します。

以上です。

この回答への補足

ありがとうございます。

ちょうど、login.yahoo.co.jpが３階層なのでそれを例とした場合、基本領域の中に 発行者（認証局）であるGlobalSignが入っていますので、発行者（認証局）をSonicWALL DPI‐SSL用の 発行者（認証局）に
置き換えて、署名暗号化アルゴリズムで処理すれば、認証局署名がGlobalSignではなく、SonicWALL DPI-SSL用の認証局署名になるので、SSLクライアントがlogin.yahoo.co.jpにアクセスしたときにSonicWALL
はDPIによるチェックが行えるということですね。

補足日時：2013/11/04 09:30

この回答へのお礼

ありがとうございます。

SonicOS 5.8.1 管理者ガイドに下記の記載がありました。
-------------------------------------------------
一般に、クライアントＤＰＩ-ＳＳＬ の配備シナリオは、ＬＡＮ 上のクライアントがＷＡＮ 上のコンテンツを参照するときにＨＴＴＰＳ トラフィックを検査するために使用します。 クライアントＤＰＩ-ＳＳＬ のシナリオでは、ＳｏｎｉｃＷＡＬＬ ＵＴＭ 装置は検査対象のコンテンツに対する証明書と秘密鍵を所持していないのが普通です。 装置は、ＤＰＩ-ＳＳＬ 検査を実行した後で、リモート サーバから送信された証明書を書き直し、新規に生成したこの証明書に署名します。 これには、クライアントＤＰＩ-ＳＳＬ の設定で指定した証明書が使用されます。 既定では、これはＳｏｎｉｃＷＡＬＬ の認証局 （ＣＡ） の証明書ですが、別の証明書を指定することもできます。 証明書の信頼のエラーを防ぐために、ユーザに対しては、ブラウザの信頼済み証明書の一覧にこの証明書を追加するよう指示する必要があります。
-------------------------------------------------

HTTPSサーバー <--> UTM装置 <--> HTTPSクライアント

クライアントＤＰＩ-ＳＳＬの動作の流れとしては、恐らく下記のようになると解釈しました。
サーバーＤＰＩ-ＳＳＬについては、UTM装置にHTTPSサーバーのサーバー証明書、中間証明書、ルート証明書をインポートするので、クライアントＤＰＩ-ＳＳＬのようにHTTPSクライアントにSonicWALL DPI-SSL証明書は必要ないと解釈しています。ただ、HTTPSサーバーのサーバー証明書に署名しているのが自己CAの場合、HTTPSクライアントに自己CAのルート証明書が必要ですが・・・。

1.HTTPSクライアントがSSLの要求。
2.HTTPSサーバーからサーバー証明書とサーバー証明書に署名しているルート証明書をUTM装置が取得。
3.取得したサーバー証明書からCSRを作成。
4.UTM装置がCSRに署名をする。
5.HTTPSクライアントにUTM装置が署名したサーバー証明書とSonicWALL DPI-SSL CA証明書を送信。
6.「署名をルート認証局の公開鍵で復号したデータ」と「サーバー証明書のハッシュ値」が一致するかどうかを確かめる。
(このとき、SonicWALL DPI-SSL CA証明書の公開鍵を使用する。）
7.「署名をルート認証局の公開鍵で復号したデータ」と「サーバー証明書のハッシュ値」が一致している場合、HTTPSサーバー証明書の公開鍵は信頼できる。
8.HTTPSクライアントは共通鍵を生成。
9.共通鍵を公開鍵で暗号化してUTM装置に送信。
10.UTM装置は秘密鍵を使用して共通鍵を復号化する。
11.HTTPSクライアントは共通鍵を使用してデータを暗号化する。
12.UTM装置は共通鍵を使用してデータを復号化する。
13.復号化されたデータをDPI処理(ゲートウェイアンチウイルス、侵入防御、アンチスパイウェア、コンテンツフィルタサービス）する。
14.DPI処理をして問題なければ、UTM装置がHTTPSクライアントとしてHTTPSサーバーにSSLの要求。
15.HTTPSサーバーからサーバー証明書とサーバー証明書に署名しているルート証明書をUTM装置が取得。
16.「署名をルート認証局の公開鍵で復号したデータ」と「サーバー証明書のハッシュ値」が一致するかどうかを確かめる。
(このとき、サーバー証明書に署名してるルート証明書の公開鍵を使用する。）
17.「署名をルート認証局の公開鍵で復号したデータ」と「サーバー証明書のハッシュ値」が一致している場合、HTTPSサーバー証明書の公開鍵は信頼できる。
18.UTM装置が共通鍵を生成。
19.共通鍵を公開鍵で暗号化してHTTPSサーバーに送信。
20.HTTPSサーバーは秘密鍵を使用して共通鍵を復号化する。
21.UTM装置は共通鍵を使用してデータを暗号化する。
22.HTTPSサーバーは共通鍵を使用してデータを復号化する。

お礼日時：2013/12/06 01:11

No.1 回答者： VDSL 回答日時： 2013/11/03 15:18

こんにちわ。

> 1.証明書は01DCDC・・・のようになっていますが、その証明書を署名している認証局部分がどこに入っているかわかるのでしょうか。

"証明書を署名している認証局部分"が何を指すのかいまいちよくわかりませんが、認証局が打つ署名という前提でお話を勧めます。

まず、証明書のフォーマットは、X.509という規格に従って構成されています。
この規格は公開されており、署名の位置ももちろんわかります(参考URL参照)。
わからなければ、その署名の正当性を第三者が検証できないので、ある意味あたりまえですね。

> 2.証明書を署名している認証局の部分が分かる場合、証明書にある拇印の部分がそうでしょうか。もしそうだとした場合、証明書の01DCDC・・・の中にそのまま拇印が入っているということでしょうか。

証明書に含まれる認証局の署名とは、証明書が証明しようとする内容をハッシュ関数にかけた結果として得られた文字列を、認証局の秘密鍵で暗号化したものです。証明書が証明しようとする内容はSonicwallも読み取れるので、そのハッシュを"自分(Sonicwall)の"秘密鍵で暗号化すれば、署名部分だけ置き換えた証明書が出来上がります。質問者さんが書かれている"証明書再署名"とは、この行為を指していると思います。

たとえば、クライアント - Sonicwall - インターネットと通信が流れる状態で、クライアントがhttps://www.google.comにアクセスした場合を考えてみてください。google.comとの暗号化通信はSonicwallが終端し、復号した結果に基づいてDPIが行われます。ここまではいいと思います。

さて、クライアント - Sonicwallについてですが、クライアント側はgoogle.comと暗号化通信を行っていると思っているわけですから、通信に利用する証明書の"証明しようとする内容"は、google.comの証明書と同一である必要があることはわかると思います。

しかし、Sonicwallはgoogle.comの秘密鍵を持っていないので、受け取った通信をそのままクライアントに送ることはできても、クライアントからgoogle.comに送られた通信を解読することができません。そこで、"証明しようとする内容"はそのままにし、署名だけ自分の秘密鍵で打った証明書を利用して、クライアントとのSSL通信を行うのです。こうすることで、クライアントからgoogle.comに送られた通信についてもDPIできるようになります。

クライアントから見ると、"証明したい内容"に含まれるサイト名はgoogle.comですので、そこについては問題ありません。ただし、署名しているのがSonicwallであるため、Sonicwallの証明書の署名の検証ができないというエラーが出ます。

> 証明書のエラーを防ぐためには、DPI-SSL に保護されている機器によって信頼された 証明書を指定してください。

これは、おそらくSonicwallのルート証明書をクライアントにインポートすれば、署名の検証に成功するようになる = エラーが出なくなるということを言っているのだと思います。

参考URL：http://ja.wikipedia.org/wiki/X.509

この回答への補足

ご説明頂きありがとうございます。

下記の認識であっておりますでしょうか。

認証局に署名を行ってもらってもCSRを発行した際に入力したCountry Name、State or Province Name、Locality Name、Organization Name、Organizational Unit Name、Common Nameなどは暗号化されていないので、もう一度、SonicWALLが
認証局として署名することによって、その証明書はSonicWALLによって署名されていることとなる。

SSLクライアントにSonicWALLのDPI-SSL用の証明書をインストールしておけば、証明書のパス検証でエラーにならない。

SSLクライアントが仮にhttps://www.google.comにアクセスをした場合、SSLクライアントはhttps://www.google.comにアクセスしていると思っているが、実際にはSonicWALLと通信を行っている。
その際に使用する公開鍵はSonicWALLと通信するための公開鍵が使用される。SonicWALLは秘密鍵を使用して複合化を行い、パケットを見てゲートウェイアンチウイルス、侵入防御などのフィンガープリントと一致しているかのチェックをDPIエンジンでチェックを行う。

ゲートウェイアンチウイルス、侵入防御などのフィンガープリントと一致していない場合、https://www.google.comの公開鍵を使用して暗号化を行い、https://www.google.comにパケットを送信する。

補足日時：2013/11/03 19:12