同一の秘密鍵が異なる製品間で使われている問題 100
ストーリー by hylom
ありそう 部門より
ありそう 部門より
あるAnonymous Coward 曰く、
多数のネットワーク機器などで、同一のHTTPS証明書や秘密鍵が使われているという（ITmedia）。オーストラリアのSEC Consultによる調査で明らかになったもの。
同じメーカー、製品ライン内だけでなく、複数のベンダー間で同じ証明書や鍵が使われているケースもあったそうだ。証明書や秘密鍵がユニークなものでない場合、中間者攻撃などに悪用される可能性がある。
昔買った、LANカードのMACアドレスがマニュアルに印刷されてた (スコア:0)
まぁ、世界ってのはおおらかなんだよ。
Re:昔買った、LANカードのMACアドレスがマニュアルに印刷されてた (スコア:2)
その部分だけ別印刷ってことはない？
一枚もののマニュアルならありそう。
結構シールで張られていたりもする。
Re:昔買った、LANカードのMACアドレスがマニュアルに印刷されてた (スコア:2, 参考になる)
同一セグメント内に同じ MACアドレスが存在する場合には問題が発生するが、ほとんどの場合 NAT経由でインターネットへアクセスする。よって相手先ネットワークの内部へ同一の MACアドレスをもつ Ethernetアダプタが存在していても問題にならない。同一セグメント内で MACアドレスが重複する可能性は低いと思われる。
そして、MACアドレスと SSL証明書は全く次元が違う。SSL暗号化において証明書とは公開鍵と秘密鍵という二つの超大きな素数から成り立っており、その二つの素数は今現在考えられるアルゴリズムでは簡単に素因数分解をすることができないという大前提がある。証明書の有効期限が短いと嘆く輩も多いが、スーパーコンピュータのようなマシンを使い、あるサイトの証明書秘密鍵を手当たり次第に素因数分解を行い解読されるというリスクが証明書の有効期限が長いほど高まる。よって、一定の短い間隔で新しい証明書を RSA社などから「購入」するのだ。
誰かが「素数」の謎を解いた時に、素因数分解という処理は時間がかかるという前提が崩れるので現在のインターネット上における暗号化はすべて破綻する。
そもそも、そうした前提の秘密鍵を使い回しているというだけで「暗号化」の意味はなくなるであろう。素因数分解に頼らずとも「鍵」が共有され何ら処理時間をかけずとも暗号解除が可能だからだ。
Re:昔買った、LANカードのMACアドレスがマニュアルに印刷されてた (スコア:2)
いやちょっと待て。
同一セグメント内に同じ MACアドレスが存在する場合には問題が発生するが、ほとんどの場合 NAT経由でインターネットへアクセスする。よって相手先ネットワークの内部へ同一の MACアドレスをもつ Ethernetアダプタが存在していても問題にならない。
言っていることは間違ってないが、この場合NATは関係ないだろ。
NATせずにルーティングする場合も、セグメントが変わるので問題にはならない。
誰かが「素数」の謎を解いた時に、素因数分解という処理は時間がかかるという前提が崩れるので現在のインターネット上における暗号化はすべて破綻する。
影響が大きいのは確かだけど、「すべて破綻」は大げさだろ。
素因数分解に依らない公開鍵暗号もあるんだから。
Re:昔買った、LANカードのMACアドレスがマニュアルに印刷されてた (スコア:1)
素数から成り立っているってわかってるなら、素因数分解は簡単では？
「簡単」の意味が、解き方が判っている、という意味なら確かに「簡単」。
「簡単」の意味が、現実的な時間で解くことが可能、という意味なら「簡単」ではない。
たとえば、
2299-1=1018517988167243043134222844204689080525734196832968125318070224677190649881668353091698687
は、「素数から成り立っているってわかってる」(合成数)けど、これを実際に素因数分解するのは、結構時間がかかるだろ?
もっと大きな数だとなおさらだね。
Re: (スコア:0)
それって、同じLANカードを買ったら衝突するってこと？
Re:昔買った、LANカードのMACアドレスがマニュアルに印刷されてた (スコア:4, 参考になる)
Ethernetはトークンリングじゃないから、馬鹿ハブやイエローケーブルなら、2つのカードがそれぞれ取り込む。で、ip層で落とす。
まあ、proxy arpとかあるから、複数のipで一つのMACでも他のホストは気にしてない。
やろうと思えば、MACを嘘つくなんていくらでも出来るから、やってみるとおもしろいかもしれないけど、下手すると、スイッチの気が狂うかもしれないから気をつけてね。
Re: (スコア:0)
Appleの製品はMACアドレスとIPアドレスを両方同じにしてスリープ中の機器の通信を代行するから、寝覚めが悪いと衝突してるよ。
http://stuartcheshire.org/SleepProxy/index.html [stuartcheshire.org]
へー (スコア:0)
>証明書や秘密鍵がユニークなものでない場合、中間者攻撃などに悪用される可能性がある。
そうなんだ？
Re:へー (スコア:1)
なあに、公開鍵を公開しない限りはどうという事はない
Re:へー (スコア:2)
本ストーリの問題の場合、公開鍵も漏洩していると考えるのが妥当なので。
Re: (スコア:0)
公開鍵は見せてもいいだろ
Re: (スコア:0)
元ACは馬鹿な書き込み後悔してるよきっと
Re:へー (スコア:1)
「公開鍵認証を使って通信をガードしよう」というのが、「そのだだ漏れのアカン状態でも安全を確保しよう」という発想そのものなので、そこのツッコミは無用。
そうなんだけど、今回の様なネットワーク機器が使うHTTPS通信ってのは、設定変更画面が主な用途だと思うんだよね。
そういう通信を、「だだ漏れネットワーク」に流してしまうポリシはどうかと思うね。
やるならそれこそ、ちゃんとした証明書を入れないとダメ、って話だよね。
1のところに、「じゃあ、分解が絶対に出来ないようなすごいハードウェアにしろよ」とツッコミを入れたくなるかも知れないけど
ROMにハードコーディングされてるならともかくだけど、おそらくファームウェアに書き込まれてるんだろうから、すごいハードウェアとは無関係に読みだされるんじゃないかな。
Re:へー (スコア:1)
「ともかくだけど」
最近、こーゆー意味不明なコメント流行ってるの?
「ROMにハードコーディングされてるならともかくだけど」のことを指してるのかな?
「70社以上のメーカーの組み込みデバイス約4000台のファームウェアイメージを分析した [itmedia.co.jp]」とあって、ROMにハードコーディングされている証拠は何も提示されてないんだよ。
なので、繰り返すけど、今回の問題はすごいハードウェアとは無関係に読みだされる [security.srad.jp]って話。
理屈としては、ファームウェアのイメージ(つまりソフトウェア)の解析だけで十分危険だ、って話なんだな。
で、「ともかくだけど」で何が言いたかったの?
Re:へー (スコア:1)
一つの語句の誤用だけを修正し続けるWikipedia編集者 [it.srad.jp]みたいにただひたすら日本語の誤用を指摘し続けるだけの存在なので内容に踏み込んだ話題を振っても無駄ですよ
Re:へー (スコア:1)
接続詞が連続してるのが問題なのであって
「だけど [weblio.jp]」は接続詞だけど、「ともかく [weblio.jp]」は副詞な。
意味の重複も接続詞の重複も問題ないってことだね。
なんつーのかな。
そんなことを問題にするのなら、鍵括弧の中に極一部だけ引用して何かを指摘したつもりになっていることの方が、よっぽど問題だと思うな。
Re:へー (スコア:1)
やるならそれこそ、ちゃんとした証明書を入れないとダメ、って話だよね。
ちゃんとした、というのがよく分からない。
当該機器のメーカ/ファームウェア開発元が、ではなくて、当該機器のユーザが、って意味。
それって、自分の買ったルータに繋がってるのか、他人のルータに繋がってるのかまで、判別されているわけではなくなる。
なぜそんなことになるのか、理由が判らない。
「ちゃんとした証明局(正しくは認証局)」がFQDNの所有を確認せずにサーバ証明書を発行するとか?
むしろ、それぞれの個体に個別のオレオレ証明書を入れて、「この個体のルータのフィンガープリントはこれなので、こうやって確認してアクセスせよ」というメッセージカードを封入した方が、手間はかかるけど、ちゃんと安全を確認出来る。
それが有効なのに、「ちゃんとした証明局(正しくは認証局)から証明書を発行して貰った証明書」のフィンガープリントを確認するのがダメ、って理由が全然わからない。
Re:へー (スコア:1)
同一のFQDNに対して大量の証明書を発行してもらって出荷する製品ごとに違うのを入れておくということかなぁ…
それじゃ確かにダメだね。
しかし、
むしろ、それぞれの個体に個別のオレオレ証明書を入れて、「この個体のルータのフィンガープリントはこれなので、こうやって確認してアクセスせよ」というメッセージカードを封入した方が、手間はかかるけど、ちゃんと安全を確認出来る。
それが有効なのに、「ちゃんとした証明局(正しくは認証局)から証明書を発行して貰った証明書」のフィンガープリントを確認するのがダメ、って理由が全然わからない。
は相変わらず疑問だね。
余計な金がかかって無駄、って話なら解らんでもないが。
結局、ユーザの手元においておく機器の証明書は俺々相当でユーザが管理運用するのが一番後腐れがないのか。
外から管理する必要があるかどうかも考慮すべきだろうね。
これって要するに (スコア:0)
パスワードの使い回しと似たような側面を持つ話ですかね？
Re:これって要するに (スコア:1)
ちょっと違うような気がするな。
この手の機器で使われている証明書ってのは、サーバ証明書のことだよね。
この手の機器のサーバ証明書は、デフォルトのもの(多分オレオレ証明書)が組み込まれていて、同一機種(もしくは同一OS)であれば、どれも同じものが使われている。
だとすると、同一機種を買って来れば、その中から当該サーバ証明書に対応する秘密鍵を取り出すことができるかもしれない。
秘密鍵を取り出せれば、後は機器とウェブブラウザとの通信経路の間に入れてしまえば、好き放題に中間者攻撃できる。
パスワードも盗めるので、設定は弄れるし、ユーザサービスのHTTPSを愁嘆している機器であれば、クレジットカード番号みたいな秘密情報も盗めるかもしれない。
まあ、結果的には、パスワードの使いまわしで、機器にアクセスされてしまう危険と同じではあるけど。
ただ、機器とウェブブラウザとの通信経路の間に入れるか、ってのは一つのハードルにはなるんじゃないかな。
インターネット経由で機器を管理するとかなら、深刻な問題になり得る。
Re:これって要するに (スコア:1)
証明書が同じなので，正規のネットワーク機器と，中間者攻撃用のネットワーク機器が区別できない，ってだけです
よくわからんのですが、「正規のネットワーク機器」と「中間者攻撃用のネットワーク機器」とは同じ証明書を使う機器で、かつ、その機器を中間者攻撃用に使えるように設定できる、って話ですか?
例えば、その機器のファームウェアを改造して、自分宛でないHTTPSとらえて終端し、ログイン時のパスワードをダンプするようファームウェアを改造するとかですか?
中間者攻撃、ってことだと、それからさらに「正規のネットワーク機器」に転送する必要もありますが。
秘密鍵を取り出すのと、どっちが難しいですかね?
Re:これって要するに (スコア:1)
秘密鍵なんぞとりださなくとも、その機器を使えば成りすませるってこじゃないのか。
普通はなりすませないでしょ?
例えば、Web管理画面にアクセスする場合、ユーザ名とパスワードを入力することになりますが、それは「正規のネットワーク機器」には設定として入っているけど、攻撃者は普通それを取り出すことはできません。
なりすました機器を中間に置いたとしても、ファームウェアの改造なしに、パスワードをダンプさせることは、普通できないと思います。
「正規のネットワーク機器」に物理的にアクセスできて、それからパスワードを取り出せるなら話は別ですが、そうなると今回の脆弱性とは無関係な話になりますね。
Re:これって要するに (スコア:1)
うん、それでIDとパスをユーザーから貰えるよね。
ユーザーにすりゃ正規の管理画面のつもりで入力するのだから。
入力させることまでは、ファームウェアの改造無しにできます。
しかし、正規ファームウェアには、入力されたパスワードをダンプする機能は、ついてませんよね、普通。
少なくとも私は、そんな機能がついているネットワーク機器を見たことがありません。
ただ、パスワードの様なユーザ認証無しに接続するような機能であれば、なりすましは可能です。
あるいは、認証をLDAPの様な別の認証サーバに依っているものなんかは可能かもしれませんね。
Re:これって要するに (スコア:1)
そんな事しなくても偽サイトに誘導するだけで攻撃成立しちゃうんじゃないの？
当該ネットワーク機器には、最初から偽装サイトに誘導するような機能がついてるんですか?
Re:これって要するに (スコア:1)
その機能を付けるのが簡単だって話では？
それほど簡単か?
例えば、Cisco IOSを改造するのは、一般人には難しいよね。
開発環境を整えることすら難しいんじゃない?
*BSDをベースにしているアプライアンスだと比較的簡単ではあるね。
それと、その改造*BSDの中のどこかにある秘密鍵ファイルとパスフレーズを探し当てるのと、どちらが簡単か、って話になるけど、どっちもどっちって感じじゃないかな。
そもそも、秘密鍵ファイルがパスフレーズ保護されてはいないかもしれないしね。
Re:これって要するに (スコア:1)
その中には公開鍵しか入っていないので、同じ証明書をいくら持っていたところで、そこから該当サーバーの秘密鍵を取り出すのは（現実的には）不可能では？
その通りです。
しかし、そんな話はしてません。
HTTPSでサーバ証明書が配られることが問題になっているわけではありませんよね。
同一の(サーバ証明書、秘密鍵)を持っている機器が、普通に販売されていて、誰でも入手できることが問題になっています。
Re:これって要するに (スコア:1)
複数のクライアント機器が同じサーバー証明書を持っていることは、別におかしいことでもなんでもないんじゃないの？
そうです。
だから、あなた以外誰もそのことを問題にしていません。
問題は、当該ネットワーク機器と同一機種を買えば、同じ秘密鍵が入っている、ってことです。
Re:これって要するに (スコア:1)
じゃ「同一機種を買って来れば、その中から当該サーバ証明書に対応する秘密鍵を取り出すことができる」ってどういう意味でいってるの？
別途買ってきた同一機種の中に含まれている秘密鍵を取り出す、って意味です。
Re:これって要するに (スコア:1)
あなたも
同一の(サーバ証明書、秘密鍵)を持っている機器が、普通に販売されていて、誰でも入手できることが問題になっています。
と書いてるでしょ。
「も」とか書かれてもなあ(笑)。
「秘密鍵」って書いてあるのが読めませんかね?
単に秘密鍵とだけ書くと、何のための秘密鍵か判らないので、最初に「当該サーバ証明書に対応する秘密鍵 [srad.jp]」と書いたし、その後は文脈上判るだろうと考えて「(サーバ証明書、秘密鍵) [srad.jp]」という表現をしたわけです。
で、問題なのは、「当該サーバ証明書に対応する秘密鍵 [srad.jp]」が漏れることです。
サーバ証明書が漏れることは、誰も問題にしてません。
お解りいただけましたか?
Re:これって要するに (スコア:1)
HTTPSではクライアント側は秘密鍵など持たないんじゃないの？
そうです。
正確には、サーバ証明書(の中の公開鍵)と対になる秘密鍵は、クライアント側には渡りません。
そんなことを問題にしている人はいません。
ただし、同一機種を買って来れば、その中にその秘密鍵と同一の秘密鍵が入っています。
共通鍵（セッション鍵）を生成して、サーバー側に送ってそれで暗号通信するんだよね。
そうです。
そんなことを問題にしている人はいません。
Re:これって要するに (スコア:1)
これは「同一機種のサーバー」という話をしているの？
はい。
最初からそう書いてる通りです。
クライアントデバイスではなくて？
そんな話をしているのは、あなただけです。
メーカーから買ってきたサーバーに、あらかじめ決められた鍵ペアとサーバー証明書がインストール済みと言っている？
そうです。
が、ここで言う「メーカーから買ってきたサーバー」と言うのは、一般のウェブサーバの類ではなく、スイッチングハブ・ルータ・ファイアウォール・負荷分散装置と言ったネットワーク機器です。
それらのHTTPS機能は普通、インターネットに公開するようなものではありません。
普通は、外部からアクセスできないネットワーク上で使われるものです。
てか、ネットワーク機器ってどういうものか知ってます?
Re:これって要するに (スコア:1)
え～？サーバー証明書にはコモンネームなどの情報も入るのに、どうやってメーカーがあらかじめインストールしておけるの？
インストールすることは可能でしょう。
ウェブブラウザからは、不正な証明書と判断されるだけで。
そもそも外部からアクセスできないネットワークで、中間者攻撃とか気にするの？
気にしない。
もしそういう機器の(サーバ証明書, 秘密鍵)を使うのであれば、そういうネットワークでのみ使うべき、ってことだね。
要するに、お試し機能程度のものなんだよ。
今回の問題は、それを知らない人達が、インターネット環境とかで使ってるかも、って話。
暗号化はされてるからいいだろう、的な。
Re:これって要するに (スコア:1)
それならそもそも暗号化されたセッションが開始されないんで、実害が起きないじゃない。何が問題なの。
「不正な証明書ですけど、接続しますか? yes/no」で、常に「no」を選べば何にも問題ない。
君の指摘の通り。
問題になるのは、「yes」にしとけばいいんじゃね? 程度の考えで使っているような場合。
繰り返し指摘している通り。
だから「それらのHTTPS機能は普通、インターネットに公開するようなものではありません。」というのでは全然なくて、普通にインターネットからアクセスするように作られた物。
それは主観の相違ですね。
私は、デフォルトの(サーバ証明書, 秘密鍵)のままでインターネットに公開するようなものではないと考えます。
インターネットから使う場合は、それなりの証明書に入れ替えて使うべきものです。
要するに、問題は間違った使い方にあると考えます。
例えば、サーバOSの中には、apacheの初回起動時に自動的にダミーのサーバ証明書を生成してHTTPSを開始するものがあります。
そのHTTPS機能はインターネットに公開するものですが、自動生成された証明書はあくまでもダミーであり、そのままインターネットに公開するものではありません。
インターネットに公開する場合は、正しい証明書に置き換えられるべきものです。
それでもなおかつ、「デフォルトの(サーバ証明書, 秘密鍵)のままで普通にインターネットからアクセスするように作られた物」だと考えることは、不可能ではないかも知れません。
しかしそうならば、デフォルトの設定の状態から、自動で「正しいサーバ証明書」に更新する仕組みを考える必要がありますね。
理論的にも経済的にも成り立つ仕組みを考えるのは、難しそうです。
あなたにも困難だと思いますが、どうですか?
Re:これって要するに (スコア:1)
いや、問題になっている機器のメーカーは、そういう機器をそのままインターネットにつなげるものとして売っていて、
初耳なんだが、どのメーカの何と言う機器なの?
少なくとも私は、企業向け機器でそんな説明を聞いたことは無いけどな。
もし本当にそういう風に売っているメーカがあるとすれば、メーカの中の人達は、正に「それを知らない人達」だね。
それを買って配っているISPもそのように使っている
ISPの人は知ってるかもしれないね。
そのうえでなんらかの判断をしているのかもしれない。
例えば、管理されているネットワークの中で使ってるつもりだとか。
あるいは、中間者攻撃を食らっても、被害額が知れてるから構わないとか。
そうでないとすれば、ISPの人たちも「それを知らない人達」に分類されるってだけだね。
大体、知ってればそんな風には使わないだろ?
使うとすれば、それでも構わない、と思えるとき。
それでも構わない、という判断が妥当なら、今回の脆弱性は何ら問題ではない。
Re:これって要するに (スコア:1)
助言ありがとう。
しかし、
ドキュメントまで読む気が起きないので知らない。
その中身を問題にしてるんだが。
Re:これって要するに (スコア:1)
君が、具体的にどのドキュメントがマズいか指摘できないのは理解した。
僕としてはそれで十分だよ。
そもそも、マズいドキュメントが存在しないことを証明する、ってのは、悪魔の照明って言って、まあ、普通そんな要求をするようなヤツは議論ってものを理解していない。
普通は、その反例、つまり、マズいドキュメントの例を一つ以上挙げることができるか、って話をするんだよ。
つまり、読むのはキミの仕事だ。
プロバイダが配るような機器は、機器に添付してユーザに読ませるドキュメントと、メーカがプロバイダに渡すもドキュメントは違う。
なので、前者に関していえば、結論としてマズい記述になっているものはあるかもしれない。
しかしそれは、プロバイダの判断だね。
プロバイダが、リスクを理解してそうしているのなら、それはそれで構わないわけ。
おわかり?
Re:これって要するに (スコア:1)
まあ、落ち着けよ(笑)。
初耳なんだが、どのメーカの何と言う機器なの? 少なくとも私は、企業向け機器でそんな説明を聞いたことは無いけどな。 [srad.jp]
太字部分を華麗にスルーした君は、企業向け機器の実例を一つも提示できない、ってとこまでは読んだよ。
プロバイダから一般消費者に配るような機器の簡易マニュアルには、問題のある記述があるものもあるだろうね。
これらは既に指摘した通りで、プロバイダが適切な判断をしたのであれば、問題ない。
しかし、それすら一つのリンクも君は提示していない。
これは不可能じゃないと思うんだけどなあ。
その内、プロバイダに非がある場合も無くは無いと思うよ。
さ、がんばりたまえ(笑)。
Re:これって要するに (スコア:1)
ほんと見苦しい屁理屈で逃げまわってんなぁ…
そーゆー口汚い文句を書くようになるのは、大抵自分の立場が苦しくなった時(笑)。
冒頭からこれじゃ、ねぇ(笑)。
元から企業向け製品に限定して問題視している話題ではないから。
初耳なんだが、どのメーカの何と言う機器なの? 少なくとも私は、企業向け機器でそんな説明を聞いたことは無いけどな。 [srad.jp]
…と、企業向け機器について言及したんだが、君には読めないのかね?
それ以外のコンシューマ向けの製品には、もしかしたらあるかもしれないし、プロバイダがコンシューマに配るような製品の簡易マニュアルになら、問題のある記述は見つかるかもしれないね。
でもそれは、プロバイダが配る分にはプロバイダの判断。
# プロバイダの判断だからすべてokというわけでもない。
つかほんとにリンク先見てねぇのな。リンク先はプロバイダのサイトじゃねーぞ？
で、そのリンク先の何がどう問題だと言ってるんだい?
具体的に指摘してくれたら、議論してあげるよ。
頑張り給え。
Re:これって要するに (スコア:1)
だからそれは君が企業向け機器についてしか知らないって無知宣言であって問題とする範囲を限定する宣言とは取れないと何度言えば。
そうかもしれないね。
それを証明する反例を一つ提出すれば、もっと説得力があるんだけどなあ。
それが君に一つもできていないことが、実に残念(笑)。
「プロバイダの簡易資料なら以上でも許されるんですー」って寝言は成立しないって教えてるだけ。
なんの理屈も無く教えていただいたところで(笑)。
ちなみに、プロバイダの簡易資料なら何でも問題なし、と言ってるわけじゃないよ。
プロバイダが実施した対策と、その資料の内容を併せて議論しないと評価できない。
そういう議論をしようよ。
議論じゃないね。ただのミスの指摘。ミスを認めないために屁理屈こねるのは議論とは言わないよ。
だから、そのコメントの中の、何が問題だって言ってるんだい？
私が言及した企業向け機器の話ではなかったね。
私としては「ミスの指摘」の話はこの時点で話は終わり。
君とは見解の相違以上の結論は得られない。
一方、コンシューマ向けの機器の話として、マニュアルがどうだから問題だと?
ここからが議論。
理屈の無い強弁はもううんざり。
実のある議論をする方がいいんじゃないか?
Re:これって要するに (スコア:1)
「君の発言はこういう意味になります」に「証明する反例」ってなんだそれ。
そういうことにしたいのですね。
問題がある製品の配布経路の一つにプロバイダが居たってだけで、プロバイダが問題を創りだしたわけじゃないし、プロバイダ「も」杜撰ってだけで本質的にあまり関係ないですよ。
そういうことにしたいのですね。
あなたが見たことがないと抜かした実例がそこに収まってます。
そういうことにしたいのですね。
そのブーメラン、何本もあなたの頭に突き刺さってますよ。傍目には痛々しいんですが、痛くないんですか？
そういうことにしたいのですね。
私としては、後は、読む人の判断に任せて全然かまいません。
さ、君はがんばりたまえ(笑)。
Re:これって要するに (スコア:1)
キミの必死さは伝わって来たよ(笑)。
明日はもっと頑張りたまえ(笑)。
Re:これって要するに (スコア:1)
おはよ。
君も無理しちゃダメだぞ。
明日もがんばりたまえ。
Re: (スコア:0)
Let's Encrypt の証明書は有効期間90日固定 (スコア:4, 興味深い)
1週間後にオープンベータテストが始まる Let's Encrypt は、サーバ証明書の有効期間が90日間固定なので、ご期待にそえるかと思います。
証明書の有効期間が90日間な理由 [letsencrypt.jp]は、下記の通りです。
証明書の有効期間が長すぎると更新のプロセスを忘れてしまいがちなので、自動化するというのは良いアイデアだと思います。
Re: (スコア:0)
10年でも短すぎるのに90日にするのです？
Re:今一つ理解が正しいか不安なんで、確認させてほしい。 (スコア:2)
同じ証明書って、箱から出してそのまま（証明書の発行とか申請しなくても）即使える、証明書取得済みのサーバーって売ってるの？
今回問題になっているのは、いわゆる普通のウェブサーバとかじゃなくて、スイッチングハブとかファイアウォールとかロードバランサとかのネットワーク機器です。
そんなネットワーク機器が売っているかどうか、という話なら、普通に売っています。
いわゆる普通のウェブサーバだと、インストール直後は証明書が存在していないか、お試し用のオレオレ証明書をランダムに生成することが多いんじゃないかと思います。
てかそんなこと可能なの？サーバー名違うだろうに。
可能か不可能か、って話で言えば可能です。
しかし、あなたの指摘の通り、正しい証明書ではありません。
なので、ブラウザでアクセスすると、警告が表示されます。
こういったネットワーク機器のHTTPS接続機能というのは、主に設定変更画面などに使われます。
そういう通信は大抵、インターネットの様な信用できない経路を通さない、というポリシで運用されています。
その限りにおいては、今回の脆弱性は、何の問題にもなりません。
そもそも、HTTPSで通信する必要性すらないかも知れません。
逆にもし、信用できない通信経路を通すのであれば、今回の脆弱性は問題になります。
が、その場合は、適切な証明書・秘密鍵に置き換えれば済む話です。
Re:今一つ理解が正しいか不安なんで、確認させてほしい。 (スコア:1)
CNが違っていて、ウェブブラウザ上では警告が表示されるけど、それを無視しても構わない、という用途に限って使うべきものなんだよ。
例えば、当該ネットワーク機器とウェブブラウザ、その間の通信経路のすべてが完全に管理下にあるクローズドな環境とかね。
要するに、お試し機能以上のものじゃないんだよ。
「よくわからないけど専用ソフト」も使わないと思うね。
Re:今一つ理解が正しいか不安なんで、確認させてほしい。 (スコア:1)
問題になっているのはクライアントデバイスが皆同じ秘密鍵のクライアント証明書を持っている場合か。
まったく違います。
クライアント証明書とそれに対応する秘密鍵は、まったく関係ありません。
サーバ証明書に対する秘密鍵が漏れることが問題になっています。
Re:異なるベンダーで同じ鍵って (スコア:2)
工場出荷状態からの初回起動時に、ユーザにキーを適当に打たせて生成する、っていう方法でも良さそうだけどね。