高木浩光＠自宅の日記

■ PKIよくある勘違い(1)「オレオレ証明書でもSSLは正常に機能する」

「オレオレ証明書クイズ」なるものが実施されていたようだ。

(1) 案内文の前半にある「暗号化は正常に行われます」は正しいでしょうか。

設問が悪い。案の定、正常だと回答する人が現れ、模範解答を見て 「間違っていなかったようだ」などと言っている。

たとえば、

金庫の上にその鍵が置いてあります。この金庫は正常に機能しているでしょうか？

と問うことのバカバカしさなら理解できるだろうか。あるいは、

共通鍵暗号による暗号化通信をしています。鍵は一緒に配送します*1。この暗号は正常に機能しているでしょうか？

ならどうか。暗号そのものは作動しているだろうが、それを言ったところで何 か意味があるのか？ つまり、プロトコル全体として正常に機能しているかが 問われている文脈において、個々の暗号アルゴリズムが作動しているかどうか を云々すること自体が誤りだということだ。

「今の話は共通鍵暗号じゃなくて公開鍵暗号だろ」って？ オーケー、では、 次の比較に対してどう答えるか。

1. 共通鍵暗号による暗号化通信
2. 公開鍵暗号による暗号化通信で認証なし（認証検証時の警告を無視する使用形態）
3. 公開鍵暗号による暗号化通信で認証あり

平均的な技術者達の間の認識として、公開鍵暗号は世紀の大発明で（それはそ うなのだが）、共通鍵暗号でなしえなかったことを（何でも）解決してくれる という印象が持たれているところがあるのではないか。

たしかに上の 1.と 3.を比較すれば 3.の方が優れている。事前に鍵を秘密裏 に交換し合っておく手順を省いて、リアルで会ったことのない相手とでも即座に 安全な通信が実現できるからだ。

では、1.と 2. を比べたときはどうか。「3.ほどではないが 1.よりは 2. の 方がまし」と言えるだろうか？ それは誤りである。

安全面で 2.は 1.よりも劣っていることに注意したい。1.では、共通鍵を事前 に秘密裏に入手できていることが利用時の前提である（ことが誰にも明白のも のとして認識される）のに対し、2.では、公開鍵を事前に安全に入手すること を前提にしてしない。なぜなら、警告が出るところを無視するのだからだ。

金庫の上に鍵が置かれているなら鍵を手にとって開ければよい。共通鍵暗号の 鍵が平文でいっしょに配送されている暗号化通信ならば、暗号文の傍受と同時 に鍵も傍受してその鍵で暗号文を復号すればよい。公開鍵暗号の公開鍵がいっ しょに配送されている暗号化通信では、傍受点で、流れてきた鍵を、別途用意 した自作鍵に差し替えて流してしまえば、それで暗号化されて戻ってくる暗号 文を復号できる。

こういうのを「正常に機能している」とは言わない。

それでもなお、証明書の検証を無視してSSLで暗号化通信をすることにも、 意義はあるのだという声は出てくるだろう。たしかに何もしないよりはましだ。 共通鍵暗号で鍵がいっしょに配送されてくる暗号化通信では、傍受するだけで 暗号文を復号できたのに対し、SSLのネゴシエーション時に公開鍵を差し替え るには、通信内容の改ざんが必要になるのだから、それが可能な状況というの は、単に傍受ができる状況よりは少な目かもしれない。

じつは、TLS（SSLはRFCでは「TLS」として定義された）には、そうした用途のための 通信モード（「完全な匿名モード」）も用意されている。そのことについて、RFC 2246に 次のように書かれている。

F.1.1. Authentication and key exchange

TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. （略）

TLS は 3つの認証モードをサポートしている。：双方の認証、サーバー認証と認証されないクライアントおよび完全な匿名である。サーバーが認証されるときは、そのチャネルはなりすまし攻撃に対しては安全であるが、完全な匿名セッションでは性質上そのような攻撃にさらされやすい。（略）

F.1.1.1. Anonymous key exchange

Completely anonymous sessions can be established using RSA or Diffie-Hellman for key exchange. With anonymous RSA, the client encrypts a pre_master_secret with the server's uncertified public key extracted from ...（略）

鍵交換において RSA または Diffie-Hellman を使用することで、完全に匿名なセッションを確立することができる。匿名 RSA では、クライアントは ServerKeyExchange メッセージから抽出された、認証のされていないサーバーの公開鍵を使用して ...（略）

Warning: Completely anonymous connections only provide protection against passive eavesdropping. Unless an independent tamper-proof channel is used to verify that the finished messages were not replaced by an attacker, server authentication is required in environments where active man-in-the-middle attacks are a concern.

警告： 完全に匿名なコネクションでは、受動的な盗聴者に対する保護しか提供されない。改竄の行われない独立したチャネルを使用して Finished メッセージが攻撃者により置きかえられてはいないことを確認しない限り、能動的ななりすまし攻撃の懸念がある環境では、サーバー認証が必要となる。

RFC 2246, The TLS Protocol Version 1.0, F.1.1. Authentication and key exchange

The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks and is therefore deprecated.

以下の暗号スイートは、どちら側のパーティーも認証されることのない、完全に匿名な Diffie-Hellman 通信に使用される。このモードは、なりすまし攻撃を受けやすいため、推奨されないことに注意。

CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };

RFC 2246, The TLS Protocol Version 1.0, A.5. The CipherSuite

7.4.2. Server certificate

The server must send a certificate whenever the agreed-upon key exchange method is not an anonymous one. This message will always immediately follow the server hello message.

サーバーは、クライアントとの間で合意された鍵交換方式が匿名方式でないときには、サーバー証明書を送信しなければならない。このメッセージは常に、 ServerHello メッセージの直後に送信される。

RFC 2246, The TLS Protocol Version 1.0, 7.4.2. Server certificate

つまり、クライアント側（たとえばWebブラウザ）が ClientHelloメッセージにおいて、TLS_DH_anon_ の値を送信して、完全匿名モードでの接続を希望したなら、そのときに限り、（man-in-the-middle攻撃の危険性を承知の上で）そのような通信が行われることになっている。それがSSL（TLS）の仕様だ。

サーバ証明書としてオレオレ証明書を使うことは、完全匿名モードでの通信をしようとするのと技術的に同じ結果をもたらすのだから、クライアントが完全匿名モードを希望していないのにサーバ側で勝手にそれを強制するのに等しく、プロトコルに違反する。

そして、完全匿名モードでの通信を希望するクライアントがあるかというと、現在主流のWebブラウザらは、そのための機能を持ち合わせていないようだ。（[memo:8057], [memo:8059]）

以上の理屈から、オレオレ証明書で https:// ページを提供していながら、「正常に機能しています」と表明するのは（「SSLが正常に機能している」という意味においては）虚偽の表明だ――ということになる。

一般に、Webページにおいて「暗号化されて送信されます」と書かれていたら、 読者はSSLのことを指すと思って読むのだから*2、 「私は『暗号は正常に機能している』とは書いたが『SSLは正常に機能している』 とは書いてない」とかいう言い訳は認められないだろう。

■ 不当表示防止法で取り締まれないか

長崎産の豚肉を鹿児島産と表示して販売するくらいのことは、個人的にはべつに気にならないが、このところは、不当景品類及び不当表示防止法で厳しく取り締まられているようだし、最近では、温泉でないのに温泉だと表示していた宿の問題が槍玉にあがっていた。

それに対して、SSLの不当表示はどうか。

SSLとして機能していないのに、「暗号化は正常に行われます」などと表示して、指摘されても直さない。

そういう不当表示を、不当景品類及び不当表示防止法で一掃できないだろうか。

第２条

２　この法律で「表示」とは、顧客を誘引するための手段として、事業者が自己の供給する商品又は役務の内容又は取引条件その他これらの取引に関する事項について行なう広告その他の表示であつて、公正取引委員会が指定するものをいう。

第４条

事業者は、自己の供給する商品又は役務の取引について、次の各号に掲げる表示をしてはならない。

1．商品又は役務の品質、規格その他の内容について、一般消費者に対し、実際のものよりも著しく優良であると示し、又は事実に相違して当該事業者と競争関係にある他の事業者に係るものよりも著しく優良であると示すことにより、不当に顧客を誘引し、公正な競争を阻害するおそれがあると認められる表示

（略）

3．前２号に掲げるもののほか、商品又は役務の取引に関する事項について一般消費者に誤認されるおそれがある表示であつて、不当に顧客を誘引し、公正な競争を阻害するおそれがあると認めて公正取引委員会が指定するもの

不当景品類及び不当表示防止法

東京都の消費生活センターにこう解説されていた。

優良誤認（第４条第１号）

品質、規格、その他の内容についての不当表示

（１）商品又は役務の品質、規格その他の内容について実際のものより著しく優良であると一般消費者に誤認される表示

（２）競争事業者の供給する商品又は役務の内容よりも自己の供給するものが著しく優良であると誤認される表示

ここでいう、「品質」とは、その商品に使用されている原材料、添加物、効能、安全性をいい、「規格」とは、国、公共団体及び民間団体が定めた規格、等級などをいいます。また、「その他の内容」とは、間接的に品質または規格に影響を及ぼすもの、例えば、原産国、有効期限、製造方法などをいいます。

不当な表示は禁止されています, 東京都消費生活センター

有効期限や製造方法のようなものですら不当表示の対象になるのだから、明確な規格のあるSSL（TLS）に適合していないものを使っていながら、そうであるかのように言っているのは、十分にこの法律の対象になるのではなかろうか。

■ 「バークシャー州長崎県」と「高知県ニューバリー市」は姉妹都市か

「サーバ管理者日誌」のこのエントリによると、長崎県電子申請システムのサーバ証明書のDNには、「S = Berkshire」と書かれているという。長崎県は黒豚が名産だっただろうか？

図1: LGPKI Application CAから「バークシャー州長崎県」の名で発行された証明書

あちこち見てまわっていたら、他にも、高知県総務部行政経営改革室が運営する「ぷらっとこうち」というサイトで、サーバ証明書に「L = Newbury」という記述があった。こちらは、そもそもがオレオレ中の認証局発行なので、もはやどうでもよい*3。しかも有効期限切れだ。

図2: オレオレ中の認証局発行の「高知県ニューバリー市」と名乗るオレオレ証明書

どうしてこういうことになっているかは、「Berkshire Newbury openssl」で検索してみると、おおかた想像がつく。

高知県の事例はそもそもが論外の外にあるのでお話にならないが、長崎県のサーバ証明書は、きちんとLGPKIのApplication CAから発行されている。こんな証明書を出してしまうようなところに、RA（登録局）ないしIA（発行局）の責任を担う資格があるのか？

少なくとも、この証明書を直ちに失効させる（revokeする）べきだろう。初の事例(?)として、LGPKIの失効システムがどのように機能するかという点でも興味深い。