アカウント名:
パスワード:
変なたとえ話はしたくありませんが、それまで有効だった『錠前』に対して、錠自体のセキュリティが甘いから、『ピッキングツール』や『ピッキングのノウハウ』が流通したということに対して、技術的な発展だから、ピッキングツールの公開や行使は阻害さ
FireWallを無効にすることも、ピッキング技術を使って錠前を無効にすることも、 どちらも「安全のための機構を無効化する」と言う点では同じでしょ。 内から開けるとか外から開けるとかは本質的に別の話。
馬鹿かおまえは。「ピッキング技術と同じだ」と持ち出せば、それを聞いた人は、「外からでも開け
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
他のセキュリティーホール要因は良いのか? (スコア:1, 興味深い)
どれも過去に(現在もか?)セキュリティーホールの要因になっているよね。
SoftEther は今までのやつとくらべて何が問題だろう。
一番は新しい方法に対抗するノウハウが無いことかな。そう考えると「一時」であれば配付を止める事に意味が有るかも知れない。
未知の物を恐れるのは正しい事だし。但し「一時」であれば。
Re:他のセキュリティーホール要因は良いのか? (スコア:1, すばらしい洞察)
現在の企業や学校などの組織のネットワークは、インターネットとは異なるセキュリティポリシー(たとえば、内部から外部へのWebアクセスは許可するが、逆はダメどか)を実現するために、ファイアウォールに依存しているのが現実で、SoftEtherは、組織内部の人間が容易に、下手をするとまったく危険性に気が付かずに、ファイアウォールの存在を無効にできてしまう点で危険といえます。
逆に、HTTPやSMTPというか、それらの実装におけるセキュリティホールは、ソフトウェアのアップデートで対応でき
Re:他のセキュリティーホール要因は良いのか? (スコア:-1, フレームのもと)
Re:他のセキュリティーホール要因は良いのか? (スコア:0)
(まあ、否定するのにやっきなんだろうけど)
FireWallを無効にすることも、ピッキング技術を使って錠前を無効にすることも、
どちらも「安全のための機構を無効化する」と言う点では同じでしょ。
内から開けるとか外から開けるとかは本質的に別の話。
(どっちからだって無効になること自体が問題なわけで)
Re:他のセキュリティーホール要因は良いのか? (スコア:-1, フレームのもと)
馬鹿かおまえは。「ピッキング技術と同じだ」と持ち出せば、それを聞いた人は、「外からでも開け
Re:他のセキュリティーホール要因は良いのか? (スコア:0)
・ある事例はAという点で一緒なのでたとえ話をしてみた
ということで、即、
・Bと点で違うからそのたとえ話はおかしい
というのがおかしいのは明白でしょう。
その論
Re:他のセキュリティーホール要因は良いのか? (スコア:0)
Aという点でしか一致しないような話はたとえ話として成立していませんし、
それをたとえ話だとして持ち出すことで話を捻じ曲げてしまうことから有害であると言えます。
>とか言うことも成り立ってしまいます
まったく成り立ちませんが、あなたはなんの話をしているつもりなのでしょうか?