アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
いたちごっこだが... (スコア:2, 興味深い)
昔:
暗号化する(ベンダー) -> 破る(クラッカー)
今:
暗号化する(ハッカー) -> 破る(企業、官公庁)
Re:いたちごっこだが... (スコア:2, 興味深い)
#誰が訴えるのか、という話はさておき。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:いたちごっこだが... (スコア:1)
どっちかというと「通信の秘密」の問題ですね。
Re:いたちごっこだが... (スコア:2, 興味深い)
通信の秘密ですが、FAQを見ると、SSL化SoftEtherもブロックできると書いてあるんですよねえ。
httpsとか、他のSSLを利用した通信と区別付くものなのでしょうか?
この会社、SSLの暗号も破ったということなんですかね?
だとしたらなんか恐ろしいような。
SSLも破られますよ (スコア:1, 参考になる)
盗聴できてしまいますよ。通信内容の改竄さえ不可能ではないです。
しかしサイト証明書が正しく機能しているのであれば、リアル
タイムでの解読はちょっと不可能と思われます。
Re:SSLも破られますよ (スコア:2, 参考になる)
> 盗聴できてしまいますよ。通信内容の改竄さえ不可能ではないです。
うーん。「サイト証明登録」って何を意味するのでしょう。デジタル証明書に正規のCAの署名がされていない、を意味するのかしらん。更にSSLにおける「中継サーバ」とは何でしょう。SSLアクセラレータ、では無いですよね。プロキシの事を言いたいのかな。
SSLアクセラレータでないプロキシの場合、プロキシは単にエンドポイント間の通信を中継するだけで、暗号化通信の内容にはノータッチです。暗号化通信の内容を傍受出来る、あるいは暗号化通信の内容を改竄出来る(もちろんエンドポイントで解読不能なゴミを垂れ流すのは除きます)とすれば、証明書のクラックその他不正な、そしてほぼ実現不可能な方法に依るしかありません。
証明書がクライアントとサーバ間のどこかですり替えられるならば、暗号化通信の内容を傍受する事は可能です。ですが、それはデジタル証明書が正規のものか私製のものかとは関係無いですね。
更に、上の方法もCAの証明書がクラックされている事が前提となって、現実的には不可能でしょう。
私製のデジタル証明書が問題になるのは、サーバやクライアントのなりすましに対してです。これを防ぐためのCAを基点とする信頼モデルが使用出来ないからです。
対して、SSLのもう１つの要素である暗号化通信の安全性については、デジタル証明書中の公開鍵暗号の強度、あるいは通信に使用される共通鍵暗号の強度に依存します。同強度の暗号を使っているならデジタル証明書が正規、私製によって変わるものではありません。