アカウント名:
パスワード:
内容は見られなくなるよね
すでに解読できているのかもしれない。128bit暗号が長らく輸出禁止で、それが解禁されたのは解読の目処が立ったためかもしれない。
常識的には解読不能なんだけどねぇ…。中間者攻撃とかやられたら抜けちゃうのかな。
ということは、世の中、いわゆるオレオレ証明局を自力で適切に運用した方が安全。
にはならないと思うけど。
SSL/TLS でルート CA の協力を得て中間者攻撃、となると、DNSキャッシュポイズニングなどを使って、本来のサイトじゃないサーバに繋がせて、そのサーバが SSL/TLS の終端として動くようにする、という事になると思うけど、CA の協力が無いと普通は証明書の検証に失敗するところ、CA の協力があればそれを回避できる。だから、元の証明書が自己証明書か否かに関係ないと思うけど...。
あっ、逆に「アレッ、証明書のエラーが出ないなぁ」で気がつく？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
SSL通信はどうだったの (スコア:0)
内容は見られなくなるよね
Re:SSL通信はどうだったの (スコア:1)
すでに解読できているのかもしれない。
128bit暗号が長らく輸出禁止で、それが解禁されたのは解読の目処が立ったためかもしれない。
常識的には解読不能なんだけどねぇ…。
中間者攻撃とかやられたら抜けちゃうのかな。
Re:SSL通信はどうだったの (スコア:1)
ということは、世の中、いわゆるオレオレ証明局を自力で適切に運用した方が安全。
Re:SSL通信はどうだったの (スコア:3, おもしろおかしい)
ということは、世の中、いわゆるオレオレ証明局を自力で適切に運用した方が安全。
にはならないと思うけど。
SSL/TLS でルート CA の協力を得て中間者攻撃、となると、DNSキャッシュポイズニングなどを使って、本来のサイトじゃないサーバに繋がせて、そのサーバが SSL/TLS の終端として動くようにする、という事になると思うけど、CA の協力が無いと普通は証明書の検証に失敗するところ、CA の協力があればそれを回避できる。だから、元の証明書が自己証明書か否かに関係ないと思うけど...。
あっ、逆に「アレッ、証明書のエラーが出ないなぁ」で気がつく？
Re:SSL通信はどうだったの (スコア:1)
文字通り回線の途中に何かを仕掛けるんだから、傍受するだけではなく通信内容の書き換えまでやれば、
そこでセッションをぶった切って割り込むような文字通りの中間者攻撃が出来るんじゃないかと、想定していました。
後半は、自己証明書の場合は自分がルートCAだから、協力者にはなり得ない、ぐらいのつもりでした。