
HTTPS監視装置にセキュリティ低下の危険性 19
ストーリー by hylom
古い装置とか危なそうだ 部門より
古い装置とか危なそうだ 部門より
HTTPS通信を監視するセキュリティ装置の一部で、TLSによる保護が十分ではなく、セキュリティ強度が低下する恐れがあるという(ZDNet Japan、JPCERTによる「HTTPS 通信監視機器によるセキュリティ強度低下の問題」という注意喚起)。
HTTPSではクライアント-サーバー間で暗号化されたデータがやり取りされるため、通常その経路に流れるデータを観測してもその中身を読み取ることはできない。そのため、HTTPS通信を監視する装置を利用する場合、クライアント側に専用の証明書をインストールすることで監視装置が暗号化されたデータを復号して読み取れるようにしておく必要がある。この場合、クライアントは監視装置の信頼性については証明書を用いて検証できるが、監視装置と目的のWebサーバーとの間の通信については、クライアントからはコントロールすることができない。
最近発表された論文によれば、多くの監視機器がWebサーバーの証明書チェーンを正しく検証していないという。そのため、監視機器とWebサーバーの間で中間者攻撃が行われる可能性があるという。
各機関では、ユーザーに監視機器が証明書チェーンを適切に検証しているかどうかや、検証結果に関する警告やエラーをクライアント側にレポートしているかを確認してほしいと呼び掛けている。
根本的に (スコア:0)
根本的に専用証明書を使ってる時点でセキュリティは低下しているので、「何を今更」としか言い様がない。
業務用端末等でユーザー側の挙動を監視するなら中途半端にアプライアンスに頼らず、端末側に管理ソフトウェアをインストールしてそちらで監視すべきだと思うのだが。
# というかCT [wikipedia.org]が出てきた経緯に逆行すること今更されてもなぁ
Re:根本的に (スコア:2, 参考になる)
専用証明書の秘密鍵が漏れなきゃ大丈夫でしょ
そもそも監視装置が証明書を検証しないのが問題なわけで
自分も似たようなの作ってるけど
証明書検証してクライアントに通知するなんていうのはそんな難しい処理ではないはずなんだけど
作るのめんどくさかったのかな
Re:根本的に (スコア:1)
いや、全然大丈夫じゃない。
何のために証明書の透過性が要求されるようになったか [symantec.com]ってことを考えたら、本来やっちゃいけないことだよ、それは。
まあ一般的なリテラシーを超えるレベルで、個人が「常時、自分の端末に不正な証明書がインストールされていないことを確認しつつ使う」というなら兎も角、一般人も使うような環境に「秘密通信の中間で読み替えを行う処理」なんてのを許容するようなポリシーそのものが問題だ。
Re: (スコア:0)
そりゃ中間者攻撃なんてやらないほうがいいに決まってるけど
CTも監視装置が検証すりゃいいでしょ
Re: (スコア:0)
中間者攻撃を防ぐための仕組みなんで、監視装置(中間者)が検証しても意味ないのだが・・・
Re: (スコア:0)
どういう理屈で無意味になるの?
監視装置が検証するかブラウザが検証するかの違いしかないはずだけど
Re: (スコア:0)
ブラウザが監査情報を取得できなくてエラー吐くんだけど、やったことない?
# CT確認するのって大概EV SSLだと思うんだけど
Re: (スコア:0)
監視装置自体が中間者で、クライアントから見れば常に安全ではないことがわかっているのと同じですね。
監視の為にセキュリティレベルを下げる仕組みだから当然のことですが。
Re: (スコア:0)
chromeだけがエラー出したわ
Re: (スコア:0)
その手の実装はChromeが早いってだけで、遅かれ早かれブラウザはそういう方向に向かうだろうなぁ
# AndroidのChromeもエラー吐くんだろうか
Re: (スコア:0)
作るのは簡単でも工程的にテストが難しいんだと思う。
Re: (スコア:0)
LenovoやDellみたいに同じ秘密鍵を使うんですね。わかります。
Re: (スコア:0)
その「専用証明書の秘密鍵が漏れていない」ことを担保する仕組みがない、
というのが問題なのでしょう。
SSL/TLSには、「通信内容の暗号化」と共に「通信相手(双方)の認証」の機能も含まれるわけで、
その途中経路に「通信内容を解読する機器」が介在するとすれば、
社内や学内の利用者(専用証明書をインストールしたユーザ)はまだ文句を言わないにしても、
本来の通信相手(ショッピングサイトなど)がそれを許すのか、というところが問題になります。
おそらくその通信相手は、「俺が話をしているのはユーザであってお前(解読する機器)じゃない。
お前が間に入るというのなら、お前が機密を漏らさない証拠を出せ。」
と言うでしょう。
それを第三者から見て公平に判断できる仕組みが必要、というわけです。
Re: (スコア:0)
ソフトウェアベースではなく、ハードウェアベースのHSMモジュールを別途取り付け、
それを暗号鍵の保持に利用していることが明示的に確認できるような実装になってないとだめだろうね。
製品にHSMモジュールを複数添付して、それを差し替え・取り外し・別のを取り付け・最初に戻すことで、
明示的に証明書が変更される・利用不能になる・別のモノに変更される・元にも戻ることがわかれば大丈夫か…?
Re: (スコア:0)
自営してますが、クライアントに元証明書も添付して送ってます。
Re: (スコア:0)
デバッガですよ。
あるいは、「検閲してるんですから、この社内ネットワーク(例)でアホなことはやめてください」って牽制です。
検閲サーバの証明書を受け入れない野良アプリケーションも排除。
仕様じゃなかったの? (スコア:0)
NSA「ちっまたバックドアを見つけられた」
中国「せやな」
錚々たるアンチウイルスソフトが名を連ねてますなぁ (スコア:0)
やはりWindows Defender最強伝説か
いつも思うんだけど (スコア:0)
この手の監視装置自体が脆弱性だよなぁ。発想が完全に中間者攻撃だし。
そもそも「監視装置の開発者たち」「監視装置を運用する人たち」その他諸々、関わる人間すべてが善良であると誰が言い切れるんだろ?
たとえばそこに、100億円入った銀行口座にアクセスできる情報が流れた瞬間を目撃して、何割が善人でいられるのだろうか?