質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.06%

SHA1を利用した証明書を偽造された場合想定される被害について

解決済

回答 7

投稿

  • 評価
  • クリップ 1
  • VIEW 3,552

score 71

こんにちは。

microsoftやGoogleからSHA1を使用した証明書の廃止スケジュールが出ています。

マイクロソフト ルート証明書プログラムでの SHA-1 ハッシュ アルゴリズムの廃止
https://technet.microsoft.com/ja-jp/library/security/2880823.aspx

Google、「SHA-1」サポート中止のスケジュールを発表
http://www.itmedia.co.jp/enterprise/articles/1409/08/news043.html

コンピュータの処理能力向上によってSHA1を利用していると、
ある証明書と同じメッセージダイジェストになる公開鍵を生成するコストが下がってきているため、
偽の公開鍵と本物のCA署名をくっつければ偽の証明書ができあがってしまうことになる
という脆弱性に対応するためと理解しています。
・参考
http://2u-moomin.blog.so-net.ne.jp/2014-09-28

偽の証明書が出来上がるというのは理解したのですが、
偽の証明書が出来上がったときにどんな問題が発生するのかが良く理解できていません。

例えばhttps://test.comといったサイトがあったとして、
このサイトで利用している証明書が偽造されたとします。

しかし、偽造されたからと言ってhttps://test.comというドメインは、すでに取得されているので
第三者がhttps://test.comというサイトを立ち上げて、何か悪いことをすることはできないはずです。
また、https://test.comと中身が酷似したhttps://test-b.comといったサイトを立ち上げて何か悪いことをする場合、
https://test-b.comに対して新規に証明書を申請して利用すれば良いと思っています。

そもそも偽物が作られてしまうこと自体は問題なのかもしれませんが、
証明書を偽造された場合、どのような被害が発生することが考えられるのでしょうか?

すいませんが、お分かりになるかたお教えください。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 7

checkベストアンサー

+4

DNSキャッシュポイズニングとか、DNSサーバー(リゾルバー)自体を乗っ取って、偽者のIPアドレスを返すようにするとか。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/03/23 08:11 編集

    (削除)

    キャンセル

  • 2016/03/23 09:42

    皆様コメントありがとうございます。
    偽造された証明書(正規のCA署名付き)+DNSキャッシュポイズニング攻撃は CRL で回避できるという点で「間違っている回答」ということですね。
    サーバー側でなく、クライアント証明書についても同様ですね。
    確かに CRL の視点は抜けていましたが、全否定しなくても ... 3回も ... (^_^;

    自分なりに CRL について調べたのですがわからないことが出てきました。
    (1) 「CRL に入れるべき」と誰がどのように偽装された証明書を見抜くのか。フィッシングなど、実際に被害が発生してから? 偽装された証明書を網羅できるのか。
    (2) CA自身が発行したものではない証明書を失効することができるのか(証明書のチェーンが自CAであることを逆手に取って)。証明書のシリアル番号だけわかればいいので、技術的にはできそうですが、問題はないのだろうか。
    (3) 偽装された証明書のシリアル番号が、正規の証明書のものと重複していた場合、どうするのか。

    (1)で網羅できないと、DigiNotar のように CA ごとバッサリということになるのだと思います。
    そう考えると、CA の信用を落とす「攻撃」になりますね。

    キャンセル

  • 2016/03/23 11:33

    ご回答は間違ってはいないと思いますよ。失効リストが反映される前に、被害を受ける可能性は十分あるのです。
    失効リストの件が補足されていたら至上なのでしょうが、それは他の原因で証明書に問題が発生した場合でも同じことかと。

    (2)について、証明書はシリアル番号はCAごとに付され、発行者名+シリアル番号で特定できる(RFC 5280 の 4.1.2.2 : It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate))とされるので、RFC的には偽造された証明書を乗っ取られたCAが失効させることは可能でしょう。逆にDoS攻撃よろしく、悪意のある者が偽造した証明書に偽のCRL配布ポイントを記載してそこに誘導し、乗っ取った証明書のCAが発行した有効な証明書を失効させることも可能でしょうね。

    キャンセル

+3

こんにちは。

例としては、Lenovo社の「Superfish」や、Dell社の「eDellRoot」に酷似した状況が懸念されます。Superfishらは、自前ルート証明書をOSへ信頼させていたわけですが、、ユーザーが、証明書の信頼チェーンを調べたときに、おおもとの発行元がSymantec(Verisign)であったりするのでことさら安心してしまうでしょう。
デバイスドライバの署名警告も出せなくできますね。Microsoft謹製のように見せることも可能になりますし。
とはいえ、確かにSymantec社などから証明書の発行を受ければ、いくらでも証明書を作成できますね。もっとも、この脆弱性を利用して、登記のない架空の組織が、存在証明つき証明書を偽造したり、が可能になります。

証明書の信頼性に関する各ソフトウエアの厳格性、結構ゆるいなぁとつねづね感じています。アドレス欄に×印がついたりしたり、メールに壊れた鍵マークを付すくらいで、一般の利用者が何か気にするのかなぁ...最近のブラウザは、ようやく、証明書の内容が破たんしていたりして怪しいサイトへつなごうとすると、コンテンツを取得するまえに警告表示したりブロックしたりするようになりましたが。。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/03/22 10:04 編集

    削除

    キャンセル

  • 2016/03/22 11:21 編集

    >kimteaさん
    >偽の証明書が出来上がったときにどんな問題が発生するのかが良く理解できていません。
    こちらの答えをしたのですけど、何か問題ありますか?

    キャンセル

  • 2016/03/22 20:41 編集

    削除

    キャンセル

0

本スレッドの書き込みに関しては、「削除処理」させていただきます。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/03/23 06:57

    X.509とSSL/TLSの区別がきちんとできていることを前提に書いていましたが、言葉足らずだったようです。今回の質問者の話は
    X.509証明書において拇印のハッシュアルゴリズムにSHA-1が使われた場合
    の問題点です。そういう意味で「別の話」と書いたのですが、言葉が足りなさすぎて「関係が無い」と解釈されてしまったようです。申し訳ありません。改めて、言い直します。

    (X.509証明書の拇印に使われる)SHA-1が暗号強度が弱い(ため、偽の証明書が現実的コストで作成され、それが悪用される恐れがある)という話とSSL/TLS自体の脆弱性(によって、通信内容が第三者によって復号可能になる、本来は正しくない証明書でも認証してしまうなどが発生する恐れ)の話は(同じくSSL/TLS全体に関わる話ですが、それぞれ独立した規格の)別の話(として、区別して考えるべき)ですよ。

    補足ですが、SHA-1が弱いために作れてしまう「偽の証明書」を本物か偽物か判断するには本物を別途入手して比較するしかなく、「偽の証明書」だけが与えられた状況で偽物であると判別することができません。「偽の証明書」はSSL/TLSの規格上は正しい証明書であり、SSL/TLSによって弾かれるべき正しくない証明書という意味ではありません。上の文にある「正しくない証明書」と言う中に、問題となっている「偽の証明書」は含まれませんので、ご注意下さい。

    なお、TLS1.2まではX.509証明書の拇印ハッシュアルゴリズムにSHA-1が使われることは許されるようで、TLS1.3のdraft-09になって初めて非推奨となりました。
    https://tlswg.github.io/tls13-spec/#rfc.section.1.2.p.7
    ただし、クライアント側があらかじめ許可すれば非推奨のSHA-1拇印の証明書を使うことは許されます。(クライアント側が許可しなければ、TLS1.3は通信を閉じます)
    https://tlswg.github.io/tls13-spec/#rfc.section.6.3.4.1.1.p.5
    現ドラフトのTLS1.3を使ったとしても、SHA-1拇印の証明書は許される恐れがあるため、根本的に解決しているとは言い切れません。

    キャンセル

  • 2016/03/23 07:35

    勘違いされる恐れがあることについて補足します。

    SSL/TLSは**通信の**改竄検知に使うハッシュアルゴリズムとしてSHA-1(正確にはHMAC-SHA1)を使うことがありますが、今回質問者が問題としている証明書のSHA-1というのは、この通信改竄検知に使われるSHA-1のことではありません。

    kimteaさんの回答は、質問に対する回答としては「答えになっていない」ですが、「間違っている」ことを書いているわけではありません。なので私は、勘違いを正そうと思いコメントを書きましたが、回答に対するマイナス評価は入れていません。他の方がマイナス評価にした理由までは私にはわかりません。

    キャンセル

  • 2016/03/23 08:03 編集

    削除

    キャンセル

0

本スレッドの書き込みに関しては、「削除処理」させていただきます。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

本スレッドの書き込みに関しては、「削除処理」させていただきます。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

-1

本スレッドの書き込みに関しては、「削除処理」させていただきます。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

-6

本スレッドの書き込みに関しては、「削除処理」させていただきます。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/03/22 18:55

    私は「SSL/TLS**自体**の脆弱性」と書いており、SSL/TLSとは全く関係が無いとは書いていません。

    質問者が言っていSHA-1の問題はX.509証明書自体の問題であり、通信の暗号強度が落ちるといった通信の信頼性の話ではありません。証明書の信頼性の話です。この違いがわからなければ、質問者が疑問にしていることもわからないと思います。

    キャンセル

  • 2016/03/22 21:01 編集

    削除

    キャンセル

  • 2016/03/22 21:23

    raccyさんは、SHA-1の脆弱性とSSL/TLS自体の脆弱性は関係が無いと言っています。
    それに対して、 kimteaさんはSHA-1が脆弱だと言っているだけで、会話がかみ合ってないです。(raccyさんはSHA-1が脆弱でないとは言っていない。)

    例えばTLSに対する攻撃であるCRIME攻撃や、OpenSSLの脆弱性であるHeartbleedなどは、SHA-1とは無関係です。

    もちろん、TLSでSHA-1を有効にしていれば、SHA-1の脆弱性の影響は受けるでしょうけど、そのこととSSL/TLSに存在する各脆弱性の原因がSHA-1にあるかどうかは別問題です。


    あと、認識が間違っているというならどこが間違っているのか明確に示してください。
    質問者も、他の回答者も、「SHA-1に脆弱性があること」や「暗号の危殆化問題」を否定したりしていません。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.06%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る