アカウント名:
パスワード:
この場合ルータのDNSハイジャックの脆弱性の方が問題のような気もしますが、公衆無線LANでの使用を考えるとアプリの平文アップデートもいい加減やめてほしいですね。自宅回線であってもISPの向こう側で経路ハイジャックされないとも限りませんし。
海外メーカーPCのプリインストールソフトウェアの脆弱性問題は以前にも指摘されている [security.srad.jp]ことで改善が進んだのですが、国内メーカーの方は誰も指摘していないので割と放置気味な印象です。最近ではSONYの「Music Center fo
アップデーターは、動く実装は簡単でも、セキュアな実装はとにかく面倒だから玉石混交という。
普通のSSL/TLSの経路暗号化では、ドメイン失効や乗っ取りに伴うハイジャックに対応出来ないので経路だけ対策してもダメです。# TLS/SSL証明書をチェックするのもアリでしょうが、デプロイを考えたら難ありでしょう。 配信にVPN使って専用サーバーからダウンロードしてもVPN強制切断でハイジャックされた [security.srad.jp]とかも有るし。
オレオレでも良いからとにかくファイ
うっかり期限切れしたり(うんこボタン [it.srad.jp])、うっかり鍵を紛失して(Google Playストアも同じだけど)アップデートができなくなるとか、そういうのも怖いね。期限切れって自分のミスでも稀に起き得るけどかなり久しぶりに起動/アップデートしようとした場合、時計に問題がある場合とか(デフォルトのNTPが停止するとか?/大抵時計を誤魔化して対処できたりするが)、数年間とか更新が停止するような個人製作のソフトウェアとかだと普通に問題になりかねないから地味に注意ポイント。まぁそんなシナリオでは手動更新させて
モダンOSであればroot証明書を適宜自動更新する仕組みが整っているので、期限切れやrevokeしても新しい証明書を発行することで難なくカバーできるはずです。そうした仕組みを利用していなかったり、オレオレ証明書を使うと、手動更新する羽目になります。
ルータのFW改造との折り合いについては「自動更新では署名検証をする」「手動更新では署名検証をしない」(または手動更新を許さない)という形が落とし所ではないでしょうか。Androidスマートフォンがまさにそうですね。
その自動更新される証明書の安全性はどうやって保証されるの? モダンOSとやらは魔法じゃないよ。
SSL通信などと異なるのは、証明書チェーンは正しくても、第三者の正規証明書を受け入れたら意味がない点。結局、アップデータが信用できる証明書なのかチェックしないと。
「ドメイン乗っ取られました、チェーン的には正しい証明書なので信頼して入れちゃいました。」では困るのです。
そのチェックってどこまでやればいい?
サーバ証明書でもコード署名証明書でもチェーンとCNをチェックすることで第三者の正規証明書を弾いてると思うけど、もしかして悪意のある第三者が同一CNのコード署名証明書を正規に取得する可能性を言ってる? DVサーバ証明書ならともかくコード署名証明書でそんなことあるのかなぁ。
そこまで考慮すると予めクライアント側に信用できる証明書をぶち込んでおくか、公開鍵ピンニングみたいなことでもしないといけなくなるけど、そうすると3年ごとに訪れる証明書切り替えの度に大量のユーザーの切り捨てが発生する予感。2段階識更新にすればいける?
コード署名証明書もDVとOVの中間的なのとEV二種類で、カーネルドライバでなければ非EVで通ります。CNに入るのは、SSL/TLSの基本ユニークなFQDNと違って、個人名や組織名 [globalsign.com]です。他の項目や確認内容は本リンク先の下部に記載 [globalsign.com]
コードサイニングのサブジェクト内容が発行年か業者によるのか仕様が安定しない印象が。結局クライアント側にオレオレ証明書仕込んで追加検証で本物か確認するのが一番楽。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
ASUS以外が標的になる可能性 (スコア:0)
この場合ルータのDNSハイジャックの脆弱性の方が問題のような気もしますが、公衆無線LANでの使用を考えるとアプリの平文アップデートもいい加減やめてほしいですね。自宅回線であってもISPの向こう側で経路ハイジャックされないとも限りませんし。
海外メーカーPCのプリインストールソフトウェアの脆弱性問題は以前にも指摘されている [security.srad.jp]ことで改善が進んだのですが、国内メーカーの方は誰も指摘していないので割と放置気味な印象です。最近ではSONYの「Music Center fo
Re: (スコア:0)
アップデーターは、動く実装は簡単でも、セキュアな実装はとにかく面倒だから玉石混交という。
普通のSSL/TLSの経路暗号化では、ドメイン失効や乗っ取りに伴うハイジャックに対応出来ないので経路だけ対策してもダメです。
# TLS/SSL証明書をチェックするのもアリでしょうが、デプロイを考えたら難ありでしょう。
配信にVPN使って専用サーバーからダウンロードしてもVPN強制切断でハイジャックされた [security.srad.jp]とかも有るし。
オレオレでも良いからとにかくファイ
Re: (スコア:0)
うっかり期限切れしたり(うんこボタン [it.srad.jp])、うっかり鍵を紛失して(Google Playストアも同じだけど)アップデートができなくなるとか、そういうのも怖いね。
期限切れって自分のミスでも稀に起き得るけどかなり久しぶりに起動/アップデートしようとした場合、時計に問題がある場合とか(デフォルトのNTPが停止するとか?/大抵時計を誤魔化して対処できたりするが)、数年間とか更新が停止するような個人製作のソフトウェアとかだと普通に問題になりかねないから地味に注意ポイント。
まぁそんなシナリオでは手動更新させて
Re:ASUS以外が標的になる可能性 (スコア:1)
モダンOSであればroot証明書を適宜自動更新する仕組みが整っているので、期限切れやrevokeしても新しい証明書を発行することで難なくカバーできるはずです。そうした仕組みを利用していなかったり、オレオレ証明書を使うと、手動更新する羽目になります。
ルータのFW改造との折り合いについては「自動更新では署名検証をする」「手動更新では署名検証をしない」(または手動更新を許さない)という形が落とし所ではないでしょうか。Androidスマートフォンがまさにそうですね。
Re: (スコア:0)
その自動更新される証明書の安全性はどうやって保証されるの? モダンOSとやらは魔法じゃないよ。
Re: (スコア:0)
SSL通信などと異なるのは、証明書チェーンは正しくても、第三者の正規証明書を受け入れたら意味がない点。
結局、アップデータが信用できる証明書なのかチェックしないと。
「ドメイン乗っ取られました、チェーン的には正しい証明書なので信頼して入れちゃいました。」では困るのです。
Re: (スコア:0)
そのチェックってどこまでやればいい?
サーバ証明書でもコード署名証明書でもチェーンとCNをチェックすることで第三者の正規証明書を弾いてると思うけど、もしかして悪意のある第三者が同一CNのコード署名証明書を正規に取得する可能性を言ってる? DVサーバ証明書ならともかくコード署名証明書でそんなことあるのかなぁ。
そこまで考慮すると予めクライアント側に信用できる証明書をぶち込んでおくか、公開鍵ピンニングみたいなことでもしないといけなくなるけど、そうすると3年ごとに訪れる証明書切り替えの度に大量のユーザーの切り捨てが発生する予感。2段階識更新にすればいける?
Re: (スコア:0)
コード署名証明書もDVとOVの中間的なのとEV二種類で、カーネルドライバでなければ非EVで通ります。
CNに入るのは、SSL/TLSの基本ユニークなFQDNと違って、個人名や組織名 [globalsign.com]です。
他の項目や確認内容は本リンク先の下部に記載 [globalsign.com]
コードサイニングのサブジェクト内容が発行年か業者によるのか仕様が安定しない印象が。
結局クライアント側にオレオレ証明書仕込んで追加検証で本物か確認するのが一番楽。