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

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

新規登録して質問してみよう
ただいま回答率
85.50%
セキュリティー

このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。

暗号化

ネットワークを通じてデジタルデータをやり取りする際に、第三者に解読されることのないよう、アルゴリズムを用いてデータを変換すること。

Q&A

解決済

7回答

4282閲覧

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

GOROGORO

総合スコア66

セキュリティー

このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。

暗号化

ネットワークを通じてデジタルデータをやり取りする際に、第三者に解読されることのないよう、アルゴリズムを用いてデータを変換すること。

2グッド

1クリップ

投稿2016/02/11 12:54

こんにちは。

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に対して新規に証明書を申請して利用すれば良いと思っています。

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

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

hsk, ps13zier👍を押しています

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

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

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

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答7

0

ベストアンサー

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

投稿2016/02/11 14:36

TaichiYanagiya

総合スコア12141

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kimtea

2016/03/25 03:13 編集

削除
YsMana

2016/03/22 12:02

「第三者がhttps://test.comで悪さをできるか」という質問に対する回答として正しいと思います。
kimtea

2016/03/25 03:13 編集

削除
YsMana

2016/03/22 12:31 編集

私も、回答者も、「失効リスト」が配布されないなどとは一言も書いていません。 質問者は、「証明書が偽造されたら」という仮定の下で、「どんな悪さが可能」か、「どんな被害が発生する」かを質問しているので、その回答としてはこうなるというだけです。 失効リストは、証明書に問題がある場合の「対策」なので、回答になっていません。 もちろん、対策も重要なのでそれについて触れるのは結構なことだと思います。
kimtea

2016/03/25 03:13 編集

削除
hsk

2016/03/23 01:26 編集

(削除)
TaichiYanagiya

2016/03/23 00:42

皆様コメントありがとうございます。 偽造された証明書(正規のCA署名付き)+DNSキャッシュポイズニング攻撃は CRL で回避できるという点で「間違っている回答」ということですね。 サーバー側でなく、クライアント証明書についても同様ですね。 確かに CRL の視点は抜けていましたが、全否定しなくても ... 3回も ... (^_^; 自分なりに CRL について調べたのですがわからないことが出てきました。 (1) 「CRL に入れるべき」と誰がどのように偽装された証明書を見抜くのか。フィッシングなど、実際に被害が発生してから? 偽装された証明書を網羅できるのか。 (2) CA自身が発行したものではない証明書を失効することができるのか(証明書のチェーンが自CAであることを逆手に取って)。証明書のシリアル番号だけわかればいいので、技術的にはできそうですが、問題はないのだろうか。 (3) 偽装された証明書のシリアル番号が、正規の証明書のものと重複していた場合、どうするのか。 (1)で網羅できないと、DigiNotar のように CA ごとバッサリということになるのだと思います。 そう考えると、CA の信用を落とす「攻撃」になりますね。
hsk

2016/03/23 02: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が発行した有効な証明書を失効させることも可能でしょうね。
guest

0

こんにちは。

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

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

投稿2016/02/12 04:18

hsk

総合スコア728

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kimtea

2016/03/25 03:14 編集

削除
hsk

2016/03/22 02:21 編集

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

2016/03/25 03:14 編集

削除
guest

0

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

投稿2016/03/25 02:59

編集2016/03/25 03:20
kimtea

総合スコア98

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

投稿2016/03/22 15:45

編集2016/03/25 03:18
kimtea

総合スコア98

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

投稿2016/03/22 15:26

編集2016/03/25 03:20
kimtea

総合スコア98

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

raccy

2016/03/22 21: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拇印の証明書は許される恐れがあるため、根本的に解決しているとは言い切れません。
raccy

2016/03/22 22:35

勘違いされる恐れがあることについて補足します。 SSL/TLSは**通信の**改竄検知に使うハッシュアルゴリズムとしてSHA-1(正確にはHMAC-SHA1)を使うことがありますが、今回質問者が問題としている証明書のSHA-1というのは、この通信改竄検知に使われるSHA-1のことではありません。 kimteaさんの回答は、質問に対する回答としては「答えになっていない」ですが、「間違っている」ことを書いているわけではありません。なので私は、勘違いを正そうと思いコメントを書きましたが、回答に対するマイナス評価は入れていません。他の方がマイナス評価にした理由までは私にはわかりません。
kimtea

2016/03/25 03:21 編集

削除
guest

0

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

投稿2016/03/22 01:11

編集2016/03/25 03:17
kimtea

総合スコア98

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

投稿2016/03/21 17:21

編集2016/03/25 03:03
kimtea

総合スコア98

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

raccy

2016/03/21 22:27 編集

SHA-1が暗号強度が弱いという話とSSL/TLS自体の脆弱性の話は別の話ですよ。SHA-1だと現実的なコストと時間で証明書が偽造できるのが問題であるので、質問者さんの認識が間違っているようには思えませんが?
kimtea

2016/03/25 03:19 編集

削除
raccy

2016/03/22 09:55

私は「SSL/TLS**自体**の脆弱性」と書いており、SSL/TLSとは全く関係が無いとは書いていません。 質問者が言っていSHA-1の問題はX.509証明書自体の問題であり、通信の暗号強度が落ちるといった通信の信頼性の話ではありません。証明書の信頼性の話です。この違いがわからなければ、質問者が疑問にしていることもわからないと思います。
kimtea

2016/03/25 03:17 編集

削除
YsMana

2016/03/22 12: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に脆弱性があること」や「暗号の危殆化問題」を否定したりしていません。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問