アカウント名:
パスワード:
>証明書や秘密鍵がユニークなものでない場合、中間者攻撃などに悪用される可能性がある。
そうなんだ?
なんか言葉足らずな感じですよね。Webサーバとして機能するネットワーク製品に組み込まれた証明書を悪用してなりすましをするってことなんでしょうけど、具体的にどうするのか、ちょっとピンと来ません。もうちょい説明してほしいですね。
1. 悪者が製品Aを買ってきて、頑張って分解するなりリバースエンジニアリングをかけるなりして秘密鍵を取り出す2. 同じ秘密鍵を使っている製品Bを使っている人xが、https経由でBに何かを設定しようとしているところに何らかの方法で割り込む3. xは通信相手をBの公開鍵で検証してBと通信しているつもりになっているけど、実はAから抜き出した秘密鍵を使った悪者と通信させられている
こう。
2のところで、x←[悪者]→Bと、悪者が完全に通信内容を書き換えてしまえる立場に無いと攻撃が成立しなくて、いや、そんなだだ漏れネッ
「公開鍵認証を使って通信をガードしよう」というのが、「そのだだ漏れのアカン状態でも安全を確保しよう」という発想そのものなので、そこのツッコミは無用。
そうなんだけど、今回の様なネットワーク機器が使うHTTPS通信ってのは、設定変更画面が主な用途だと思うんだよね。そういう通信を、「だだ漏れネットワーク」に流してしまうポリシはどうかと思うね。やるならそれこそ、ちゃんとした証明書を入れないとダメ、って話だよね。
1のところに、「じゃあ、分解が絶対に出来ないようなすごいハードウェアにしろよ」とツッコミを入れたくなるかも知れないけど
ROMにハードコーディングされてるならともかくだけど、おそらくファームウェアに書き込まれてるんだろうから、すごいハードウェアとは無関係に読みだされるんじゃないかな。
「ともかくだけど」
最近、こーゆー意味不明なコメント流行ってるの?「ROMにハードコーディングされてるならともかくだけど」のことを指してるのかな?「70社以上のメーカーの組み込みデバイス約4000台のファームウェアイメージを分析した [itmedia.co.jp]」とあって、ROMにハードコーディングされている証拠は何も提示されてないんだよ。なので、繰り返すけど、今回の問題はすごいハードウェアとは無関係に読みだされる [security.srad.jp]って話。理屈としては、ファームウェアのイメージ(つまりソフトウェア)の解析だけで十分危険だ、って話なんだな。
で、「ともかくだけど」で何が言いたかったの?
一つの語句の誤用だけを修正し続けるWikipedia編集者 [it.srad.jp]みたいにただひたすら日本語の誤用を指摘し続けるだけの存在なので内容に踏み込んだ話題を振っても無駄ですよ
「ともかく」に「だけど」の意味も含まれてるから冗長ってことでしょう。「話は別だけどだけど」みたいな。
接続詞が連続してるのが問題なのであって、意味は重複していないと思いますが。「この話はともかく」のような使い方だと「だけど」を含むと解釈し難いですし、「ROMにハードコーディングされているのだけど」だと明らかにおかしいですし、「ROMにハードコーディングされていればよいのだけど」等では語が増えてしまいますし…ちょっと考えてみたけど文章を大きく変えずに接続語を「だけど」にして問題がなく繋ぐ方法をちょっと思いつけませんでした。
「ROMにハードコーディングされてるならともかくなのだけど」省略されていると仮定して考えてみたが、違和感が減った気もするし、もっと変になった気もする。「ROMにハードコーディングされてるならともかく」…一番違和感はないが、ひねりが効いてなくてちょっとつまらない。
接続詞が連続してるのが問題なのであって
「だけど [weblio.jp]」は接続詞だけど、「ともかく [weblio.jp]」は副詞な。意味の重複も接続詞の重複も問題ないってことだね。
なんつーのかな。そんなことを問題にするのなら、鍵括弧の中に極一部だけ引用して何かを指摘したつもりになっていることの方が、よっぽど問題だと思うな。
> …一番違和感はないが、ひねりが効いてなくてちょっとつまらない。
いや別にヒネリや面白味を盛り込むような箇所じゃないのでは…。本来の文章をヒネるほど違和感が増して件のツッコミに至る、と。
まあたしかに野暮っちゃ野暮ですが、編集者のtypoや言い回しをいちいちあげつらう事にはプラスのおもおかモデが付いて自分達のコメントに矛先が向くとオフトピとしてマイナスモデが付く流れは傍で見ていてあまりフェアな感じしないですね。
>そういう通信を、「だだ漏れネットワーク」に流してしまうポリシはどうかと思うね。
まあ、なので実際問題としては、非常に限定的な問題だと思う。
>やるならそれこそ、ちゃんとした証明書を入れないとダメ、って話だよね。
ちゃんとした、というのがよく分からない。ちゃんとした証明局から証明書を発行して貰った証明書、と言うんであれば、むしろ役に立たないような気がする。
例えば、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)
「ともかくだけど」
Re:へー (スコア:1)
「ともかくだけど」
最近、こーゆー意味不明なコメント流行ってるの?
「ROMにハードコーディングされてるならともかくだけど」のことを指してるのかな?
「70社以上のメーカーの組み込みデバイス約4000台のファームウェアイメージを分析した [itmedia.co.jp]」とあって、ROMにハードコーディングされている証拠は何も提示されてないんだよ。
なので、繰り返すけど、今回の問題はすごいハードウェアとは無関係に読みだされる [security.srad.jp]って話。
理屈としては、ファームウェアのイメージ(つまりソフトウェア)の解析だけで十分危険だ、って話なんだな。
で、「ともかくだけど」で何が言いたかったの?
Re:へー (スコア:1)
一つの語句の誤用だけを修正し続けるWikipedia編集者 [it.srad.jp]みたいにただひたすら日本語の誤用を指摘し続けるだけの存在なので内容に踏み込んだ話題を振っても無駄ですよ
Re: (スコア:0)
「ともかく」に「だけど」の意味も含まれてるから冗長ってことでしょう。
「話は別だけどだけど」みたいな。
Re: (スコア:0)
接続詞が連続してるのが問題なのであって、意味は重複していないと思いますが。
「この話はともかく」のような使い方だと「だけど」を含むと解釈し難いですし、
「ROMにハードコーディングされているのだけど」だと明らかにおかしいですし、
「ROMにハードコーディングされていればよいのだけど」等では語が増えてしまいますし…
ちょっと考えてみたけど文章を大きく変えずに接続語を「だけど」にして問題がなく繋ぐ方法をちょっと思いつけませんでした。
「ROMにハードコーディングされてるならともかくなのだけど」
省略されていると仮定して考えてみたが、違和感が減った気もするし、もっと変になった気もする。
「ROMにハードコーディングされてるならともかく」
…一番違和感はないが、ひねりが効いてなくてちょっとつまらない。
Re:へー (スコア:1)
接続詞が連続してるのが問題なのであって
「だけど [weblio.jp]」は接続詞だけど、「ともかく [weblio.jp]」は副詞な。
意味の重複も接続詞の重複も問題ないってことだね。
なんつーのかな。
そんなことを問題にするのなら、鍵括弧の中に極一部だけ引用して何かを指摘したつもりになっていることの方が、よっぽど問題だと思うな。
Re: (スコア:0)
> …一番違和感はないが、ひねりが効いてなくてちょっとつまらない。
いや別にヒネリや面白味を盛り込むような箇所じゃないのでは…。
本来の文章をヒネるほど違和感が増して件のツッコミに至る、と。
まあたしかに野暮っちゃ野暮ですが、
編集者のtypoや言い回しをいちいちあげつらう事にはプラスのおもおかモデが付いて
自分達のコメントに矛先が向くとオフトピとしてマイナスモデが付く流れは
傍で見ていてあまりフェアな感じしないですね。
Re: (スコア:0)
>そういう通信を、「だだ漏れネットワーク」に流してしまうポリシはどうかと思うね。
まあ、なので実際問題としては、非常に限定的な問題だと思う。
>やるならそれこそ、ちゃんとした証明書を入れないとダメ、って話だよね。
ちゃんとした、というのがよく分からない。
ちゃんとした証明局から証明書を発行して貰った証明書、と言うんであれば、むしろ役に立たないような気がする。
例えば、example社がルータに、https://setting.example.comというURLで開く設定画面を入れるとして、
それぞれの機械用に別個の秘密鍵を用意して(同じ秘密鍵でもいいけど)証明書を買ってインス
Re:へー (スコア:1)
やるならそれこそ、ちゃんとした証明書を入れないとダメ、って話だよね。
ちゃんとした、というのがよく分からない。
当該機器のメーカ/ファームウェア開発元が、ではなくて、当該機器のユーザが、って意味。
それって、自分の買ったルータに繋がってるのか、他人のルータに繋がってるのかまで、判別されているわけではなくなる。
なぜそんなことになるのか、理由が判らない。
「ちゃんとした証明局(正しくは認証局)」がFQDNの所有を確認せずにサーバ証明書を発行するとか?
むしろ、それぞれの個体に個別のオレオレ証明書を入れて、「この個体のルータのフィンガープリントはこれなので、こうやって確認してアクセスせよ」というメッセージカードを封入した方が、手間はかかるけど、ちゃんと安全を確認出来る。
それが有効なのに、「ちゃんとした証明局(正しくは認証局)から証明書を発行して貰った証明書」のフィンガープリントを確認するのがダメ、って理由が全然わからない。
Re: (スコア:0)
> なぜそんなことになるのか、理由が判らない。
> 「ちゃんとした証明局(正しくは認証局)」がFQDNの所有を確認せずにサーバ証明書を発行するとか?
同一のFQDNに対して大量の証明書を発行してもらって出荷する製品ごとに違うのを入れておくということかなぁ…
そんな取り方できるのかって問題もあるけど、それやったところで俺々にならないだけで何の意味もないという。
むしろ製品のシリアルナンバーが入ったドメイン名毎に証明書を発行してもらって入れたほうが良いだろうけど、
その場合だって証明書をユーザの手元にばらまいてしまうって時点で色々危ないし、
ユーザがドメイン名のシリアルナンバーを毎回確認しないと結局意味が無いってオチ。
結局、ユーザの手元においておく機器の証明書は俺々相当でユーザが管理運用するのが一番後腐れがないのか。
Re:へー (スコア:1)
同一のFQDNに対して大量の証明書を発行してもらって出荷する製品ごとに違うのを入れておくということかなぁ…
それじゃ確かにダメだね。
しかし、
むしろ、それぞれの個体に個別のオレオレ証明書を入れて、「この個体のルータのフィンガープリントはこれなので、こうやって確認してアクセスせよ」というメッセージカードを封入した方が、手間はかかるけど、ちゃんと安全を確認出来る。
それが有効なのに、「ちゃんとした証明局(正しくは認証局)から証明書を発行して貰った証明書」のフィンガープリントを確認するのがダメ、って理由が全然わからない。
は相変わらず疑問だね。
余計な金がかかって無駄、って話なら解らんでもないが。
結局、ユーザの手元においておく機器の証明書は俺々相当でユーザが管理運用するのが一番後腐れがないのか。
外から管理する必要があるかどうかも考慮すべきだろうね。
Re: (スコア:0)
オレオレ証明書の派手な警告が出てる方がチェックするユーザ数は増えるだろうというか、
何もしなくても警告無しでTLS検証OKの表示が出る状態で指紋確認するユーザって希少だと思う。
まったくもってその通り。