アカウント名:
パスワード:
iOSやレガシーなガラケー(フィーチャーフォン)など、ファームウェア組み込みの証明書の有効無効が個別対応できないものは全部危険ですね。今思いついたのはその二つですが、まだまだあると思います。
日本のフィーチャーフォンにトルコの認証局の証明書が入っているとはとても思えない。
証明書の仕組みわかってる?
元のACとは別人だが分からないので教えてくれ。
証明書ってのは、公開鍵の正当性を証明するものだよね。山田さんが公開している証明書で暗号の解読ができればその証明書で解読できる暗号を作れる秘密鍵を持った人しかいないので、この暗号データは山田さんしかありえない、と言うのが証明書の基本。
ただしこの状態だと、その公開鍵証明書は、そもそも本当に山田さんと結びつけられたものなのかと言う事が分からない。その時「山田さんが公開している公開鍵証明書である」と言う事を証明する手段が、その上位の証明書ということだよね?
その上位の証明書というのが
元ACが「TURKTRUSTの証明書が日本のフィーチャーフォンに入ってるとは思えない」と語っているけど、この推測が確かで、証明書の更新ができないような古いフィーチャーフォンにはTURKTRUSTのルート証明書が入っていないのだとすると、元が絶たれるわけでフィーチャーフォンは素性の分からない証明書だよと最低でも警告を出してくる(オレオレ証明書と同じ事になる)んじゃ無いかなあ。
ここ笑うとこ?
例が悪いから誤解されたのかな。
山田さんが公開している証明書で暗号の解読ができればその証明書で解読できる暗号を作れる秘密鍵を持った人しかいないので、この暗号データは山田さんしかありえない、と言うのが証明書の基本。
ここだけ読むと公開鍵暗号は暗号解読だけしかできず、公開鍵は常にどこかに公開されているものと言う風に読めなくもないけど(だから「証明書が入ってないのに素性の分からない証明書だと警告してくると言うのは矛盾している」と言った勘違いをしてしまうのでは無いかな)SSL通信をする時は
1. サーバからクライアントに暗号化のための公開鍵証明書が送られてくる2. クライアント側は暗号化のための公開鍵証明書が本当に明記されている相手のものかどうかの証明を上位の証明書を確認する →持っている上位の証明書を使って証明書の署名を復号できれば、署名は対になっている秘密鍵で作られたと確認できる 上位の公開鍵証明書の発行者が信頼できるものであるならばそれも信頼できる (今回はこの中間の証明書が盗まれたので「上位の証明書の発行者が信頼できる」と言う前提が崩れた)3. 証明書が正規であると言う確認が取れたら、クライアント側が共通鍵を生成して公開鍵証明書を用いて暗号化、サーバに送る4. 以降は共通鍵で暗号通信が行われる
と言う手順になる。例で言うと「山田さんが公開している公開鍵で暗号化したものは、山田さんが持っている秘密鍵でしか復号化できないので、復号化できるなら相手は山田さんしかありえない」と言う事。で上位の証明書がないと、上記2の手順で「この証明書が本当に山田さんだという確証が得られなかった」と言う理由でエラーが出るという。また中間証明書と、実際に暗号化通信を始めるときに使われる証明書は復号化に使われるのと暗号化につかわれるので違いがある。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
updateできないデバイスは危険 (スコア:0)
iOSやレガシーなガラケー(フィーチャーフォン)など、ファームウェア組み込みの証明書の有効無効が
個別対応できないものは全部危険ですね。今思いついたのはその二つですが、まだまだあると思います。
Re: (スコア:0)
日本のフィーチャーフォンにトルコの認証局の証明書が入っているとはとても思えない。
Re: (スコア:0)
証明書の仕組みわかってる?
Re: (スコア:0)
元のACとは別人だが分からないので教えてくれ。
証明書ってのは、公開鍵の正当性を証明するものだよね。
山田さんが公開している証明書で暗号の解読ができればその証明書で解読できる暗号を作れる秘密鍵を持った人しかいないので、この暗号データは山田さんしかありえない、と言うのが証明書の基本。
ただしこの状態だと、その公開鍵証明書は、そもそも本当に山田さんと結びつけられたものなのかと言う事が分からない。
その時「山田さんが公開している公開鍵証明書である」と言う事を証明する手段が、その上位の証明書ということだよね?
その上位の証明書というのが
Re: (スコア:0)
ここ笑うとこ?
Re:updateできないデバイスは危険 (スコア:0)
例が悪いから誤解されたのかな。
山田さんが公開している証明書で暗号の解読ができればその証明書で解読できる暗号を作れる秘密鍵を持った人しかいないので、この暗号データは山田さんしかありえない、と言うのが証明書の基本。
ここだけ読むと公開鍵暗号は暗号解読だけしかできず、公開鍵は常にどこかに公開されているものと言う風に読めなくもないけど(だから「証明書が入ってないのに素性の分からない証明書だと警告してくると言うのは矛盾している」と言った勘違いをしてしまうのでは無いかな)SSL通信をする時は
1. サーバからクライアントに暗号化のための公開鍵証明書が送られてくる
2. クライアント側は暗号化のための公開鍵証明書が本当に明記されている相手のものかどうかの証明を上位の証明書を確認する
→持っている上位の証明書を使って証明書の署名を復号できれば、署名は対になっている秘密鍵で作られたと確認できる
上位の公開鍵証明書の発行者が信頼できるものであるならばそれも信頼できる
(今回はこの中間の証明書が盗まれたので「上位の証明書の発行者が信頼できる」と言う前提が崩れた)
3. 証明書が正規であると言う確認が取れたら、クライアント側が共通鍵を生成して公開鍵証明書を用いて暗号化、サーバに送る
4. 以降は共通鍵で暗号通信が行われる
と言う手順になる。
例で言うと「山田さんが公開している公開鍵で暗号化したものは、山田さんが持っている秘密鍵でしか復号化できないので、復号化できるなら相手は山田さんしかありえない」と言う事。
で上位の証明書がないと、上記2の手順で「この証明書が本当に山田さんだという確証が得られなかった」と言う理由でエラーが出るという。
また中間証明書と、実際に暗号化通信を始めるときに使われる証明書は復号化に使われるのと暗号化につかわれるので違いがある。