アカウント名:
パスワード:
根本的に専用証明書を使ってる時点でセキュリティは低下しているので、「何を今更」としか言い様がない。
業務用端末等でユーザー側の挙動を監視するなら中途半端にアプライアンスに頼らず、端末側に管理ソフトウェアをインストールしてそちらで監視すべきだと思うのだが。
# というかCT [wikipedia.org]が出てきた経緯に逆行すること今更されてもなぁ
専用証明書の秘密鍵が漏れなきゃ大丈夫でしょそもそも監視装置が証明書を検証しないのが問題なわけで自分も似たようなの作ってるけど証明書検証してクライアントに通知するなんていうのはそんな難しい処理ではないはずなんだけど作るのめんどくさかったのかな
いや、全然大丈夫じゃない。
何のために証明書の透過性が要求されるようになったか [symantec.com]ってことを考えたら、本来やっちゃいけないことだよ、それは。
まあ一般的なリテラシーを超えるレベルで、個人が「常時、自分の端末に不正な証明書がインストールされていないことを確認しつつ使う」というなら兎も角、一般人も使うような環境に「秘密通信の中間で読み替えを行う処理」なんてのを許容するようなポリシーそのものが問題だ。
そりゃ中間者攻撃なんてやらないほうがいいに決まってるけどCTも監視装置が検証すりゃいいでしょ
中間者攻撃を防ぐための仕組みなんで、監視装置（中間者）が検証しても意味ないのだが・・・
どういう理屈で無意味になるの？監視装置が検証するかブラウザが検証するかの違いしかないはずだけど
ブラウザが監査情報を取得できなくてエラー吐くんだけど、やったことない？
# CT確認するのって大概EV SSLだと思うんだけど
監視装置自体が中間者で、クライアントから見れば常に安全ではないことがわかっているのと同じですね。監視の為にセキュリティレベルを下げる仕組みだから当然のことですが。
chromeだけがエラー出したわ
その手の実装はChromeが早いってだけで、遅かれ早かれブラウザはそういう方向に向かうだろうなぁ
# AndroidのChromeもエラー吐くんだろうか
作るのは簡単でも工程的にテストが難しいんだと思う。
専用証明書の秘密鍵が漏れなきゃ大丈夫でしょ
LenovoやDellみたいに同じ秘密鍵を使うんですね。わかります。
その「専用証明書の秘密鍵が漏れていない」ことを担保する仕組みがない、というのが問題なのでしょう。
SSL/TLSには、「通信内容の暗号化」と共に「通信相手(双方)の認証」の機能も含まれるわけで、その途中経路に「通信内容を解読する機器」が介在するとすれば、社内や学内の利用者(専用証明書をインストールしたユーザ)はまだ文句を言わないにしても、本来の通信相手(ショッピングサイトなど)がそれを許すのか、というところが問題になります。
おそらくその通信相手は、「俺が話をしているのはユーザであってお前(解読する機器)じゃない。お前が間に入るというのなら、お前が機密を漏らさない証拠を出せ。」と言うでしょう。
それを第三者から見て公平に判断できる仕組みが必要、というわけです。
ソフトウェアベースではなく、ハードウェアベースのHSMモジュールを別途取り付け、それを暗号鍵の保持に利用していることが明示的に確認できるような実装になってないとだめだろうね。製品にHSMモジュールを複数添付して、それを差し替え・取り外し・別のを取り付け・最初に戻すことで、明示的に証明書が変更される・利用不能になる・別のモノに変更される・元にも戻ることがわかれば大丈夫か…?
自営してますが、クライアントに元証明書も添付して送ってます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
根本的に (スコア: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)
自営してますが、クライアントに元証明書も添付して送ってます。