どっちがセキュアですか？「HTTP」と「オレオレ証明書のHTTPS」

Question

質問

サイトA: HTTPでの通信
サイトB: 自己署名証明書のHTTPSでの通信

のサイトAとサイトBのどちらがセキュアといえるか？
という質問です。

質問背景

個人的にはサイトBの「HTTPSだけど証明書が自己署名証明書」方がセキュアなのではないかと考えています。
なぜなら、自己署名証明書の問題はHTTP通信でも抱えている問題だと思うからです。

ですが、ChromeなどブラウザではHTTPはほとんど警告なしに表示するのに、証明書が信頼できないものは過剰な警告を出すので、
Chromeが「HTTPのほうがマシ（よりセキュア）」と言っているようなきがするのです。
こういう背景で質問して、スッキリしたいと思いました。

私の自己署名証明書の問題点の理解は、以下のサイトからです。

Qiita記事: オレオレ証明書を使いたがる人を例を用いて説得する
から引用させていただくと、

1. 暗号化。サーバ側とクライアント側で暗号化／復号化を行うことにより、通信経路上での盗聴・改竄を防ぎます。

1. 通信相手が正しいことの保障。DNS cache poisoningや、MITM(Man in the middle)によるSSL終端など、攻撃者によって通信相手が変更された場合に警告を表示することで、攻撃者による盗聴・改竄を防ぎます。

1. 改竄の検出。サーバ側で証明書を使って署名することで、通信経路上で改竄された場合にもクライアント側で受信した際に改竄を検出することができます。

1は自己署名証明書でも可能
2, 3は自己署名証明書では問題になる

Answer 1

1は自己署名証明書でも可能

もちろん、オレオレ証明書をルートに入れればそれで問題ないですが、そうしなかった場合、攻撃者が偽の証明書を提示して中間者攻撃を仕掛けている場合も考えられますので、1すら担保されません。「HTTPSなのに証明書がおかしい」というのは、そういった攻撃を示唆するものですので、「単なるHTTP」以上に警告する必要があります。

なお、「オレオレ証明書」と一口に言っても、いくつかパターンがあります（高木浩光さんによる区分）。

このうち、第3種・第4種は「使う人のマシンにルート証明書を取り込む」ことで、（証明書の不正発行に関するリスクを除けば）普通のHTTPSと同様に警告なしで使えます。第5種はちょっと仕方ない部分があるのですが、第6種は単なる設定ミスです。

Answer 2

1. 暗号化。サーバ側とクライアント側で暗号化／復号化を行うことにより、通信経路上での盗聴・改竄を防ぎます。

1は自己署名証明書でも可能

そもそもこれが誤解です。自己署名証明書では、盗聴・改ざんを防げるとは限りません。

そもそも盗聴・改ざんが問題になるのは、通信路上に攻撃者がいるケースです。例えば、以下が考えられます。文字通りネットワークの経路上に攻撃者がいるケースだけではありません。

1. 通信機器を操作できる場所に攻撃者がいて、ミラーリングポートなどから盗聴する
2. 暗号化していない、あるいは弱い暗号化の無線LANを盗聴する
3. 無線LANの偽アクセスポイントをたてる
4. 企業などのPROXYサーバーを操作できる
5. ARPスプーフィング攻撃によりデフォルトゲートウェイを詐称する
6. DNSに対する攻撃により、攻撃対象サーバーの偽物にアクセスさせる

5の例としては、さくらインターネットでの事例があります。

［ARPスプーフィング］他のマシンあての通信を乗っ取り，監視強化が先決

6の事例としては、Secuniaの事例が有名で、LinkedInも同種の攻撃が疑われた事例があります。

Secuniaのサイトにハッキングメッセージ、DNSがハイジャックされる
LinkedInでDNSハイジャックの可能性

そして、上記リストの2以外のケースで中間者攻撃ができます。そうなると、通信相手の認証機能がなければ、盗聴・改ざんは防げません。現に、さくらインターネットの事例では通信内容が改ざんされているわけですし、攻撃形態としては中間者攻撃なので、自己署名証明書によるHTTPSでも盗聴は防ぐことはできません。

また、そもそもHTTPSは、仮に通信路がどんな状況であっても、安全に通信ができるか、安全に通信できない場合は利用者がそれに気づくことができるというものです。例えば独裁国家がネットワークを把握していても、そこの住民のHTTPSの通信は盗聴できないことが求められるのです。

そうなると、ブラウザ側では、意図的な自己署名証明書による運用と盗聴による偽の証明書を区別することはできないので、自己署名証明書は一律に強い警告を出すしかないわけです。これはHTTPSの原理上、ブラウザに求められる機能です。

まとめると以下の通りです。

• HTTPによるサイトAと自己署名証明書HTTPSによるサイトBを比べると、サイトBの方が盗聴を防げる余地はあるが、その確実性は期待ほどのものではない
• HTTPSは、そもそも安全に接続するか、安全性が担保できないなら接続しないという性格のものであるので、安全でない場合にブラウザが強い警告を表示するのは妥当である

Answer 3

サイトA: HTTPでの通信
サイトB: 自己署名証明書のHTTPSでの通信

この2つでの比較であれば、サイトBの方がマシですが、一般的な https でユーザが求めるレベルに達していないという警告をブラウザが発しています。

http と https のサイトではユーザから求められるセキュリティ度合いが違うことが警告の根底です。

ファーストフード店でクレジットカードが使えなくてもイラッとしないけど、レストランで使えないとイラッとする。みたいなものです。

Answer 4

HTTPで運用されているサーバは、データがセキュアである必要がないと考えて運用されている。
だから、HTTPでブラウザからアクセスされても問題とは思わない。
そもそもHTTPでは証明書や暗号化は使わないので、警告も無い。
地方自治体の公園に、誰が入っても文句を言われないようなもの。

HTTPSで運用されているサーバは、データ(サーバに送られてくるデータも、ブラウザに返されるデータも)がセキュア(改変されず、他に漏れない)である必要があると考えて運用されている。
だから、信用ある証明書を求めるし、警告も出す。
市役所で戸籍謄本を取る時に、免許証など公的機関が発行した写真付きの書類が要求されるようなもの。

HTTPとHTTPSは必要に応じて使い分ければ良いのであって、「どちらがセキュアか」で競い合うものではないと思います。用途が違うのですから。

=

もちろん、HTTPとHTTPSのどちらがセキュアかといえば、SecureのSがついているHTTPSです。
信頼性のある証明書を使った場合と、信頼性のない証明書を使った場合では、信頼性のある証明書を使ったほうがセキュアです。

このような自明なことを質問したかった訳ではないと思いましたので、このような回答をいたしました。

Answer 5

解決済みの質問ですし、前記回答に追加情報が有る訳ではないのですが解は明白である点を強調したいので書きます。

公開サーバで自己証明のhttpsを構成してはいけません。自己証明局を立てるツールはあくまでも試験用なのであってテスト環境意外で使用してはいけません。ブラウザが自己証明のサイトをアクセスする際、厳重な警告メッセージを表示した後「非常に危険ですがアクセスしますか？」のメッセージを承知してアクセスすることになります。ユーザがこれを慣例としてしまったら、本当の詐称サイトにアクセスしても気づくことができません。

選択肢として選ばないべきだと考えます。

Comments

[退会済みユーザー]

少し確認したいのですが、

> 自己証明局を立てるツールはあくまでも試験用なのであってテスト環境意外で使用してはいけません。

プライベート認証局のことだと思うのですが、これって何かに縛られています？

[BlueMoon]

ツールを使って自分で作成した証明書を使用し、エンジニア個人で簡易に構築できるCAを差したものです。また、認証局の証明書をブラウザにインポートせずに利用しているケースです。BtoBなどで利用するプライベート認証局の意図では有りません。

[BlueMoon]

プライベート認証局を使用してブラウザにサーバー証明書がインストールされてあれば、ブラウザに警告メッセージは表示されないので問題有りません。

[BlueMoon]

個人で簡易にhttpsを構築する手段が有るが、それにはリスクが有るということを示す意図です。

[退会済みユーザー]

自己証明局という「ツールを使って自分で作成した証明書を使用し、エンジニア個人で簡易に構築できるCA」を定義する言葉があったんですね。知りませんでした。少し調べてみましたが、用語定義が見つかりませんでした。独自翻訳ですかね？元の単語とできれば、定義しているドキュメントを教えてください。
また、多分そのドキュメントに記載されているのだと思いますが、使用条件を確認したいので、「自己証明局のテスト環境以外で使用禁止」に関しても記述箇所を教えていただけると助かります。
使用禁止となっていることを知りませんでした＾＾；