アカウント名:
パスワード:
>証明書や秘密鍵がユニークなものでない場合、中間者攻撃などに悪用される可能性がある。
そうなんだ?
なんか言葉足らずな感じですよね。Webサーバとして機能するネットワーク製品に組み込まれた証明書を悪用してなりすましをするってことなんでしょうけど、具体的にどうするのか、ちょっとピンと来ません。もうちょい説明してほしいですね。
1. 悪者が製品Aを買ってきて、頑張って分解するなりリバースエンジニアリングをかけるなりして秘密鍵を取り出す2. 同じ秘密鍵を使っている製品Bを使っている人xが、https経由でBに何かを設定しようとしているところに何らかの方法で割り込む3. xは通信相手をBの公開鍵で検証してBと通信しているつもりになっているけど、実はAから抜き出した秘密鍵を使った悪者と通信させられている
こう。
2のところで、x←[悪者]→Bと、悪者が完全に通信内容を書き換えてしまえる立場に無いと攻撃が成立しなくて、いや、そんなだだ漏れネッ
「公開鍵認証を使って通信をガードしよう」というのが、「そのだだ漏れのアカン状態でも安全を確保しよう」という発想そのものなので、そこのツッコミは無用。
そうなんだけど、今回の様なネットワーク機器が使うHTTPS通信ってのは、設定変更画面が主な用途だと思うんだよね。そういう通信を、「だだ漏れネットワーク」に流してしまうポリシはどうかと思うね。やるならそれこそ、ちゃんとした証明書を入れないとダメ、って話だよね。
1のところに、「じゃあ、分解が絶対に出来ないようなすごいハードウェアにしろよ」とツッコミを入れたくなるかも知れないけど
ROMにハードコーディングされてるならともかくだけど、おそらくファームウェアに書き込まれてるんだろうから、すごいハードウェアとは無関係に読みだされるんじゃないかな。
>そういう通信を、「だだ漏れネットワーク」に流してしまうポリシはどうかと思うね。
まあ、なので実際問題としては、非常に限定的な問題だと思う。
>やるならそれこそ、ちゃんとした証明書を入れないとダメ、って話だよね。
ちゃんとした、というのがよく分からない。ちゃんとした証明局から証明書を発行して貰った証明書、と言うんであれば、むしろ役に立たないような気がする。
例えば、example社がルータに、https://setting.example.comというURLで開く設定画面を入れるとして、それぞれの機械用に別個の秘密鍵を用意して(同じ秘密鍵でもいいけど)証明書を買ってインス
やるならそれこそ、ちゃんとした証明書を入れないとダメ、って話だよね。
ちゃんとした、というのがよく分からない。
当該機器のメーカ/ファームウェア開発元が、ではなくて、当該機器のユーザが、って意味。
それって、自分の買ったルータに繋がってるのか、他人のルータに繋がってるのかまで、判別されているわけではなくなる。
なぜそんなことになるのか、理由が判らない。「ちゃんとした証明局(正しくは認証局)」がFQDNの所有を確認せずにサーバ証明書を発行するとか?
むしろ、それぞれの個体に個別のオレオレ証明書を入れて、「この個体のルータのフィンガープリントはこれなので、こうやって確認してアクセスせよ」というメッセージカードを封入した方が、手間はかかるけど、ちゃんと安全を確認出来る。
それが有効なのに、「ちゃんとした証明局(正しくは認証局)から証明書を発行して貰った証明書」のフィンガープリントを確認するのがダメ、って理由が全然わからない。
> なぜそんなことになるのか、理由が判らない。> 「ちゃんとした証明局(正しくは認証局)」がFQDNの所有を確認せずにサーバ証明書を発行するとか?
同一のFQDNに対して大量の証明書を発行してもらって出荷する製品ごとに違うのを入れておくということかなぁ…そんな取り方できるのかって問題もあるけど、それやったところで俺々にならないだけで何の意味もないという。むしろ製品のシリアルナンバーが入ったドメイン名毎に証明書を発行してもらって入れたほうが良いだろうけど、その場合だって証明書をユーザの手元にばらまいてしまうって時点で色々危ないし、ユーザがドメイン名のシリアルナンバーを毎回確認しないと結局意味が無いってオチ。
結局、ユーザの手元においておく機器の証明書は俺々相当でユーザが管理運用するのが一番後腐れがないのか。
同一のFQDNに対して大量の証明書を発行してもらって出荷する製品ごとに違うのを入れておくということかなぁ…
それじゃ確かにダメだね。しかし、
は相変わらず疑問だね。余計な金がかかって無駄、って話なら解らんでもないが。
外から管理する必要があるかどうかも考慮すべきだろうね。
それが有効なのに、「ちゃんとした証明局(正しくは認証局)から証明書を発行して貰った証明書」のフィンガープリントを確認するのがダメ、って理由が全然わからない。は相変わらず疑問だね。
は相変わらず疑問だね。
オレオレ証明書の派手な警告が出てる方がチェックするユーザ数は増えるだろうというか、何もしなくても警告無しでTLS検証OKの表示が出る状態で指紋確認するユーザって希少だと思う。
まったくもってその通り。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
へー (スコア:0)
>証明書や秘密鍵がユニークなものでない場合、中間者攻撃などに悪用される可能性がある。
そうなんだ?
Re: (スコア:0)
なんか言葉足らずな感じですよね。
Webサーバとして機能するネットワーク製品に組み込まれた証明書を悪用してなりすましをするってことなんでしょうけど、
具体的にどうするのか、ちょっとピンと来ません。
もうちょい説明してほしいですね。
Re: (スコア:0)
1. 悪者が製品Aを買ってきて、頑張って分解するなりリバースエンジニアリングをかけるなりして秘密鍵を取り出す
2. 同じ秘密鍵を使っている製品Bを使っている人xが、https経由でBに何かを設定しようとしているところに何らかの方法で割り込む
3. xは通信相手をBの公開鍵で検証してBと通信しているつもりになっているけど、実はAから抜き出した秘密鍵を使った悪者と通信させられている
こう。
2のところで、x←[悪者]→Bと、悪者が完全に通信内容を書き換えてしまえる立場に無いと攻撃が成立しなくて、
いや、そんなだだ漏れネッ
Re: (スコア:1)
「公開鍵認証を使って通信をガードしよう」というのが、「そのだだ漏れのアカン状態でも安全を確保しよう」という発想そのものなので、そこのツッコミは無用。
そうなんだけど、今回の様なネットワーク機器が使うHTTPS通信ってのは、設定変更画面が主な用途だと思うんだよね。
そういう通信を、「だだ漏れネットワーク」に流してしまうポリシはどうかと思うね。
やるならそれこそ、ちゃんとした証明書を入れないとダメ、って話だよね。
1のところに、「じゃあ、分解が絶対に出来ないようなすごいハードウェアにしろよ」とツッコミを入れたくなるかも知れないけど
ROMにハードコーディングされてるならともかくだけど、おそらくファームウェアに書き込まれてるんだろうから、すごいハードウェアとは無関係に読みだされるんじゃないかな。
Re: (スコア:0)
>そういう通信を、「だだ漏れネットワーク」に流してしまうポリシはどうかと思うね。
まあ、なので実際問題としては、非常に限定的な問題だと思う。
>やるならそれこそ、ちゃんとした証明書を入れないとダメ、って話だよね。
ちゃんとした、というのがよく分からない。
ちゃんとした証明局から証明書を発行して貰った証明書、と言うんであれば、むしろ役に立たないような気がする。
例えば、example社がルータに、https://setting.example.comというURLで開く設定画面を入れるとして、
それぞれの機械用に別個の秘密鍵を用意して(同じ秘密鍵でもいいけど)証明書を買ってインス
Re:へー (スコア:1)
やるならそれこそ、ちゃんとした証明書を入れないとダメ、って話だよね。
ちゃんとした、というのがよく分からない。
当該機器のメーカ/ファームウェア開発元が、ではなくて、当該機器のユーザが、って意味。
それって、自分の買ったルータに繋がってるのか、他人のルータに繋がってるのかまで、判別されているわけではなくなる。
なぜそんなことになるのか、理由が判らない。
「ちゃんとした証明局(正しくは認証局)」がFQDNの所有を確認せずにサーバ証明書を発行するとか?
むしろ、それぞれの個体に個別のオレオレ証明書を入れて、「この個体のルータのフィンガープリントはこれなので、こうやって確認してアクセスせよ」というメッセージカードを封入した方が、手間はかかるけど、ちゃんと安全を確認出来る。
それが有効なのに、「ちゃんとした証明局(正しくは認証局)から証明書を発行して貰った証明書」のフィンガープリントを確認するのがダメ、って理由が全然わからない。
Re: (スコア:0)
> なぜそんなことになるのか、理由が判らない。
> 「ちゃんとした証明局(正しくは認証局)」がFQDNの所有を確認せずにサーバ証明書を発行するとか?
同一のFQDNに対して大量の証明書を発行してもらって出荷する製品ごとに違うのを入れておくということかなぁ…
そんな取り方できるのかって問題もあるけど、それやったところで俺々にならないだけで何の意味もないという。
むしろ製品のシリアルナンバーが入ったドメイン名毎に証明書を発行してもらって入れたほうが良いだろうけど、
その場合だって証明書をユーザの手元にばらまいてしまうって時点で色々危ないし、
ユーザがドメイン名のシリアルナンバーを毎回確認しないと結局意味が無いってオチ。
結局、ユーザの手元においておく機器の証明書は俺々相当でユーザが管理運用するのが一番後腐れがないのか。
Re:へー (スコア:1)
同一のFQDNに対して大量の証明書を発行してもらって出荷する製品ごとに違うのを入れておくということかなぁ…
それじゃ確かにダメだね。
しかし、
むしろ、それぞれの個体に個別のオレオレ証明書を入れて、「この個体のルータのフィンガープリントはこれなので、こうやって確認してアクセスせよ」というメッセージカードを封入した方が、手間はかかるけど、ちゃんと安全を確認出来る。
それが有効なのに、「ちゃんとした証明局(正しくは認証局)から証明書を発行して貰った証明書」のフィンガープリントを確認するのがダメ、って理由が全然わからない。
は相変わらず疑問だね。
余計な金がかかって無駄、って話なら解らんでもないが。
結局、ユーザの手元においておく機器の証明書は俺々相当でユーザが管理運用するのが一番後腐れがないのか。
外から管理する必要があるかどうかも考慮すべきだろうね。
Re: (スコア:0)
オレオレ証明書の派手な警告が出てる方がチェックするユーザ数は増えるだろうというか、
何もしなくても警告無しでTLS検証OKの表示が出る状態で指紋確認するユーザって希少だと思う。
まったくもってその通り。