アカウント名:
パスワード:
根本的に専用証明書を使ってる時点でセキュリティは低下しているので、「何を今更」としか言い様がない。
業務用端末等でユーザー側の挙動を監視するなら中途半端にアプライアンスに頼らず、端末側に管理ソフトウェアをインストールしてそちらで監視すべきだと思うのだが。
# というかCT [wikipedia.org]が出てきた経緯に逆行すること今更されてもなぁ
専用証明書の秘密鍵が漏れなきゃ大丈夫でしょそもそも監視装置が証明書を検証しないのが問題なわけで自分も似たようなの作ってるけど証明書検証してクライアントに通知するなんていうのはそんな難しい処理ではないはずなんだけど作るのめんどくさかったのかな
その「専用証明書の秘密鍵が漏れていない」ことを担保する仕組みがない、というのが問題なのでしょう。
SSL/TLSには、「通信内容の暗号化」と共に「通信相手(双方)の認証」の機能も含まれるわけで、その途中経路に「通信内容を解読する機器」が介在するとすれば、社内や学内の利用者(専用証明書をインストールしたユーザ)はまだ文句を言わないにしても、本来の通信相手(ショッピングサイトなど)がそれを許すのか、というところが問題になります。
おそらくその通信相手は、「俺が話をしているのはユーザであってお前(解読する機器)じゃない。お前が間に入るというのなら、お前が機密を漏らさない証拠を出せ。」と言うでしょう。
それを第三者から見て公平に判断できる仕組みが必要、というわけです。
ソフトウェアベースではなく、ハードウェアベースのHSMモジュールを別途取り付け、それを暗号鍵の保持に利用していることが明示的に確認できるような実装になってないとだめだろうね。製品にHSMモジュールを複数添付して、それを差し替え・取り外し・別のを取り付け・最初に戻すことで、明示的に証明書が変更される・利用不能になる・別のモノに変更される・元にも戻ることがわかれば大丈夫か…?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
根本的に (スコア:0)
根本的に専用証明書を使ってる時点でセキュリティは低下しているので、「何を今更」としか言い様がない。
業務用端末等でユーザー側の挙動を監視するなら中途半端にアプライアンスに頼らず、端末側に管理ソフトウェアをインストールしてそちらで監視すべきだと思うのだが。
# というかCT [wikipedia.org]が出てきた経緯に逆行すること今更されてもなぁ
Re: (スコア:2, 参考になる)
専用証明書の秘密鍵が漏れなきゃ大丈夫でしょ
そもそも監視装置が証明書を検証しないのが問題なわけで
自分も似たようなの作ってるけど
証明書検証してクライアントに通知するなんていうのはそんな難しい処理ではないはずなんだけど
作るのめんどくさかったのかな
Re:根本的に (スコア:0)
その「専用証明書の秘密鍵が漏れていない」ことを担保する仕組みがない、
というのが問題なのでしょう。
SSL/TLSには、「通信内容の暗号化」と共に「通信相手(双方)の認証」の機能も含まれるわけで、
その途中経路に「通信内容を解読する機器」が介在するとすれば、
社内や学内の利用者(専用証明書をインストールしたユーザ)はまだ文句を言わないにしても、
本来の通信相手(ショッピングサイトなど)がそれを許すのか、というところが問題になります。
おそらくその通信相手は、「俺が話をしているのはユーザであってお前(解読する機器)じゃない。
お前が間に入るというのなら、お前が機密を漏らさない証拠を出せ。」
と言うでしょう。
それを第三者から見て公平に判断できる仕組みが必要、というわけです。
Re: (スコア:0)
ソフトウェアベースではなく、ハードウェアベースのHSMモジュールを別途取り付け、
それを暗号鍵の保持に利用していることが明示的に確認できるような実装になってないとだめだろうね。
製品にHSMモジュールを複数添付して、それを差し替え・取り外し・別のを取り付け・最初に戻すことで、
明示的に証明書が変更される・利用不能になる・別のモノに変更される・元にも戻ることがわかれば大丈夫か…?