アカウント名:
パスワード:
「セキュリティの懸念」っていうけれど「遺伝子組み換え野菜への懸念」程度のモヤッっとしたものでは? なんとなく危ないんちがうか?程度で実際的な被害があるのか明確になってません。
>暗号化されていないWi-Fiネットワークのセキュリティを懸念」
ここに注目して話をするのですが、IPレイヤでの個別の通信の暗号化が進んでいるので何が危ないのかな? と。
昔、第一に心配したのはSMBによる共有ですが、それは非Windowsでは関係がない上、今は暗号化されたSMB3.11ですよね。さらにいうと最近の人って SMB共有って使ってる人いるんでしょうか・・。
>オンラインバンキングなどで暗号化されていないWi-Fiを使用する同じセグメントの人は誰がどの銀行にアクセスしているかはわかっても取引内容まではわからない・。一昔前はメールの内容が筒抜けになりましたが、今は一般ユーザは Web APIベースの物を知らずに使っているでしょう。DHCPがのっとられても SSL は危険に気づいてくれる。
完全に安全とは言えませんが、そうでないならこの時代にまだ具体的にどういった環境で何が危ないのか興味があるので知りたいなと思いました。例として、いまだに 生POP使っている人とか。
他スレのコメントを例に使わせていただくと:>仕事の文書のクラウド共有や調べ物をする悪習慣が広がってしまっています調べものしても検索キーは分かりませんし、共有しているファイルは読めませんよね。わかるのは「あ・・(nslookup..)、この人 A社ドメインのサーバにつないでいるからそこの社員かな?」「おっ。IPで開くだけで社内システムのログイン画面が出てきた。外に晒しているのか。」ここまでは出来るでしょうね。探偵さんには意味はあるかもしれませんが、元からInternetに晒しているサーバは危ないです。セグメントの端末すべてについてポートスキャンすると何か見つかるかもしれませんが 一般ユーザのデバイスで openにlistenしているようなものがあるのかしら?
以下セキュリティ被害の出る一例Unicodeによる悪意あるURL目視判断阻止行為は、実際にここでやるとまずいと思うのでそこは説明文記載にしておきます
・あなたはコーヒーショップやバーガーショップで 「暗号化なし」や「WEP」で動作しているAPに接続してmacbookでどや顔しています
・あなたのWEP暗号化は周囲の悪意あるものから1分程度ですでに破られています(暗号化なしなら最初から丸見え)
・あなたはamazon.co.jpを見ようと思い、http://から始まるURLを表示するようブラウザに指示しました
・あなたが操作した結果発生するDNS名前解決要求に、悪意あるものは本来のDNSサーバより先に悪意あるサイトのIPを返しました
・あなたのブラウザは、悪意あるものが示したIPに接続します。ここで悪意あるページ上のスクリプトにより、ブラウザは「amazon.co.jp」ではなく悪意ある(Unicodeを駆使し目視ではまったく判別がつかない)「amazon.co.jp」を表示し、すぐさま「https://から始まる、悪意あるamazon.co.jpのログインページ」を表示します
ここで、「悪意あるamazon.co.jp」が表示するログインページの内容は、「本物のamazon.co.jpのログイン画面と全く同じ画面」です
・「悪意あるamazon.co.jp」には正式な「悪意あるamazon.co.jpとしてのSSL証明書」が存在するため、ブラウザはこのサイトが正当なサイトだとお墨付きを与えて表示します
・この状態で「amazon.co.jp」のユーザ名/パスワードを入力したら即アウト!!
上記は仮にamazon.co.jpを例にしましたが、現実にはhttp://のURLを持つすべてのサイトで上記のような影響を受けうる可能性がありますhttp:/// [http]から始まる www.google.co.jp などのURLを使った場合には検索条件が盗聴されるうえに検索結果のすべてが汚染されて表示される可能性もあります
悪意ある行為を受け始めた時点での回避策:
もっとも最初のブラウザからのアクセスにおいて、必ずhttpではなくhttpsのURLを開く(絶対死守)。さらにhttpsのページからhttpのページへのリダイレクトは警告するブラウザ設定とし(絶対死守)、この警告を絶対に軽視せず警告が出た時点で悪意ある行為にさらされていると判断し速やかに切断する(絶対死守)
ブラウザ以外のアプリすべてにおいて、上記のような動作をしないアプリがないかを常に確認し、上記のような動作をしないアプリは一切使わない(絶対死守)
-> で、そんなの理解してる一般人はどのくらいいます?
amazonはPreloaded HSTSに登録されているので例えとして適切ではないな・あなたはamazon.co.jpを見ようと思い、http://から始まるURLを表示するようブラウザに指示しましたこの時点でブラウザがhttps://amazon.co.jpへ自動的にリダイレクトしますというわけで一般人は何も考えなくてもセキュアにamazonを利用できるというわけだ
書いてあることに基本的には同意ですけど、今はHSTSやHSTSプリロードがあるので、
もっとも最初のブラウザからのアクセスにおいて、必ずhttpではなくhttpsのURLを開く(絶対死守)。
は絶対死守でもないでしょう。
一般人なら、アドレスバーにURLを入力するなんて滅多にやらないと思います。ググったり、せいせいブックマークからのアクセスでしょう。グーグルなら、当然HSTSプリロードに入っているし、ブックマークならちゃんとhttpsのURLになっていれば良いわけです。
というわけで、みんなHTTPSに移行して、さらにHSTSなりHSTSプリロードに対応していけば、ウェブについては最低限安全が保たれると言って良いのではないでしょうか。
ブラウザは「amazon.co.jp」ではなく悪意ある(Unicodeを駆使し目視ではまったく判別がつかない)「amazon.co.jp」を表示し、
今時のウェブブラウザでは、Unicodeの微妙な記号を使うとPunycodeをデコードせずxy--で始まる生の表記になるようです。詳しい人間ならアドレスバーで見分けられると思います。
> というわけで、みんなHTTPSに移行して、さらにHSTSなりHSTSプリロードに対応していけば、> ウェブについては最低限安全が保たれると言って良いのではないでしょうか。> 詳しい人間ならアドレスバーで見分けられると思います。
現在の一般人向けのセキュリティの話において、自論に都合のいい未来での話をされてもまた繰り返しになりますが「公衆WIFIを喜んで使う一般人のレベル」で話をしないと意味がないと思いますよ
たしかに、「みんなHTTPSに移行して~」は(来るかどうか分からない)未来の話です。でも、Amazonみたいな、パスワードなどで機密情報を扱い、一般人が使うほど知名度があるサービスなら、もうみんなHTTPSに移行していて、ある程度は現在でも通用する話だと思ったのですが、甘く考え過ぎでしたでしょうか?
「詳しい人間ならアドレスバーで見分けられると思います。」と書いたほうはまた別の話で、未来永劫すべての一般人にこの方法を普及させるのは無理だと思っているから、「詳しい人間なら」と前置きしました。
一般人は、HTTPかHTTPSかなんて一切気にしないっつーかそもそもURLなんて見ていない。アマゾンって書いてあるんだからアマゾンなんだろって程度。
マイクロソフトなんちゃら~って偽セキュリティ広告を鵜呑みにしてマルウェアインストールし、「マイクロソフトっていってるんだから偽物のわけがない」と宣うのが一般人ですよ。いやマジで。たとえ理系でも情報系に興味ない人ならその程度。
一般人はWindows 10とかmacOS Sierra以上でEdgeとかSafariを使うでしょ? どっちもHSTSにもcertificate pinningにも対応してるよ。Windows 8とかMac OS X Mavericksのような古いOSを排除するのは管理者の義務だよ。
> Windows 8とかMac OS X Mavericksのような古いOSを排除するのは管理者の義務だよ。
そういうのはさんざんWindows10ネガキャンして移行を阻止しているアンチMSの方々に言ってください
偽APに引っかかってる場合などではDNSまで悪意あるものになりますここで一般人がDNSまで悪意あるとした場合に正しくその異常性を把握し回避行為を取るのは現実的に無理です
また、経路上で介入される場合はたとえ正しくSSL処理がされていてもクッキーは改ざんされますここを知らない人はとても多いです
さらに、ルーター自体が悪意あるものであればそこから直接、そうでなくとも暗号化の部分がそもそもない/クラックされたら近隣のwifiクライアント端末から飛び込みで悪意のあるパケットがバンバン飛び込む状況となりますもちろん盗聴もされます
>ここで一般人がDNSまで悪意あるとした場合にこの場合、(ブラウザ等による)証明書のエラーが出ませんか。
>正しくSSL処理がされていてもクッキーは改ざんされますこの正しく処理というのは、証明書のエラーも出ない状況でしょうか。
確かに AP自体が偽物だと危険度はぐっと上がりそうですが
>悪意のあるパケットがバンバン飛び込む状況となります これはブロックされるし、
>もちろん盗聴もされます IPヘッダは読めてもペイロードは復号できませんよね。(全くトンチンカンな事を言ってたら恥ずかしい限りですが)
一般人にとっては証明書のエラーなど無視一択かと。
Microsoft Edge, Mozilla Firefox, Google Chromeとかの通常のブラウザでは、「危険を覚悟で進む」という選択肢は与えられない [badssl.com]よ。IE8とかの一般に使ってはいけない特殊な環境では知らないけど。
#3233901 に半分くらいのことが書いてあるのでそちらを参照残り
> この正しく処理というのは、証明書のエラーも出ない状況でしょうか。SSL上でもクッキーが改ざんされるという件では、証明書エラーは出ません
> IPヘッダは読めてもペイロードは復号できませんよね。安全にVPN経路が結ばれたあとの話、かつVPN経路上の通信だけに限定すればそうなります(VPN自体の強度は別の話)が、VPN経路を結ぶ前の時点ですでにセキュリティリスクがあること、VPN経路を結んだあとでも、多くの場合はVPNを通さない通信も許可されることなどの考慮が必要です
例:社員をVPN接続させるサービスにおいて、クライアントPCのすべての通信をVPN経由にさせる設定とするとクライアントPC上のブラウザの通信とかメーラとかWindowsUpdateとかも全部VPN経由で自社ネットワークを通る高負荷構成になる対策としてVPNを通すのはあくまでも自社VPN(のGWサーバのIP)向けの通信にだけ限定するなど
「正しくSSL処理してても(上位レイヤの)クッキーを改ざんできる」とは、画期的なことかもしれぬ。詳細キボンヌ。
# MITM 攻撃のことを言っているのかもしれんけど、それは証明書チェーンが汚染されていることが# 前提なので、「正しくSSL処理されている」とは言わんし。
「SSL クッキー 改ざん」でググってみてくださいsecure属性を指定しても改変はされ、secure属性を指定しない場合さらに盗聴もされます
ここで残念なことですが、secure属性をつけていても改ざんされるということを知らないままWebに公開するサイト/サービスを構築している例は非常に多いです
親ACです。徳丸せんせいのページを見てみました。何が言いたいのか、大体理解したつもりです。画期的という感じではないですが。
経路上のルータ機器で FQDN が同一な HTTP 偽サイトへ誘導することで、 (1) secure 属性がない Cookie が平文で送られる。(取得・盗聴) (2) 偽サイト上で Cookie を設定する。(作成・改ざん)ということが可能だ、ということですよね。
嘘は言っていないけど、だから? という感想を持ちました。正規のサービス/サイト側で、クライアント(ユーザ)から送られてくる Cookie の内容を完全に信じて処理する時点で、サービス側の設計不備でしかないな、と。# 単なる不用心というか。
セキュリティ確保の観点で啓蒙することは大事だと思うので、ぜひ進めて下さい。
HTSTにすりゃ解決する問題
ググったけど改竄や盗聴をされるなんて書いてるところはなかったぞ
IPレイヤでの通信暗号化なんて広まってる?
ちゃんといえば個別の暗号化が進んでいるのは TCP/UDP の上にのっかってる部分ですね。
IPSec。。。違うかたぶんSSLのことが言いたかったんだと思うけど、IPレイヤではないよね。アプリ層(L5-7)がしっくりくる感じ。
WEPや暗号化なしのオープンWi-Fiって全体的の設計でセキュリティ考えてないだろうから、認証サーバや各種ネットワーク機器に何か仕掛けられてても不思議ではない、というところは?いや仕組とかは詳しくないんで完全に妄想なんですけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
何が懸念されるのかな? (スコア:5, すばらしい洞察)
「セキュリティの懸念」っていうけれど「遺伝子組み換え野菜への懸念」程度のモヤッっとしたものでは? なんとなく危ないんちがうか?程度で実際的な被害があるのか明確になってません。
>暗号化されていないWi-Fiネットワークのセキュリティを懸念」
ここに注目して話をするのですが、IPレイヤでの個別の通信の暗号化が進んでいるので何が危ないのかな? と。
昔、第一に心配したのはSMBによる共有ですが、それは非Windowsでは関係がない上、今は暗号化されたSMB3.11ですよね。さらにいうと最近の人って SMB共有って使ってる人いるんでしょうか・・。
>オンラインバンキングなどで暗号化されていないWi-Fiを使用する
同じセグメントの人は誰がどの銀行にアクセスしているかはわかっても取引内容まではわからない・。
一昔前はメールの内容が筒抜けになりましたが、今は一般ユーザは Web APIベースの物を知らずに使っているでしょう。
DHCPがのっとられても SSL は危険に気づいてくれる。
完全に安全とは言えませんが、そうでないならこの時代にまだ具体的にどういった環境で何が危ないのか興味があるので知りたいなと思いました。例として、いまだに 生POP使っている人とか。
他スレのコメントを例に使わせていただくと:
>仕事の文書のクラウド共有や調べ物をする悪習慣が広がってしまっています
調べものしても検索キーは分かりませんし、共有しているファイルは読めませんよね。わかるのは「あ・・(nslookup..)、この人 A社ドメインのサーバにつないでいるからそこの社員かな?」「おっ。IPで開くだけで社内システムのログイン画面が出てきた。外に晒しているのか。」ここまでは出来るでしょうね。探偵さんには意味はあるかもしれませんが、元からInternetに晒しているサーバは危ないです。
セグメントの端末すべてについてポートスキャンすると何か見つかるかもしれませんが 一般ユーザのデバイスで openにlistenしているようなものがあるのかしら?
Re:何が懸念されるのかな? (スコア:2, 参考になる)
以下セキュリティ被害の出る一例
Unicodeによる悪意あるURL目視判断阻止行為は、実際にここでやるとまずいと思うのでそこは説明文記載にしておきます
・あなたはコーヒーショップやバーガーショップで 「暗号化なし」や「WEP」で動作しているAPに接続してmacbookでどや顔しています
・あなたのWEP暗号化は周囲の悪意あるものから1分程度ですでに破られています(暗号化なしなら最初から丸見え)
・あなたはamazon.co.jpを見ようと思い、http://から始まるURLを表示するようブラウザに指示しました
・あなたが操作した結果発生するDNS名前解決要求に、悪意あるものは本来のDNSサーバより先に悪意あるサイトのIPを返しました
・あなたのブラウザは、悪意あるものが示したIPに接続します。ここで悪意あるページ上のスクリプトにより、
ブラウザは「amazon.co.jp」ではなく悪意ある(Unicodeを駆使し目視ではまったく判別がつかない)「amazon.co.jp」を表示し、
すぐさま「https://から始まる、悪意あるamazon.co.jpのログインページ」を表示します
ここで、「悪意あるamazon.co.jp」が表示するログインページの内容は、「本物のamazon.co.jpのログイン画面と全く同じ画面」です
・「悪意あるamazon.co.jp」には正式な「悪意あるamazon.co.jpとしてのSSL証明書」が存在するため、ブラウザはこのサイトが正当なサイトだとお墨付きを与えて表示します
・この状態で「amazon.co.jp」のユーザ名/パスワードを入力したら即アウト!!
上記は仮にamazon.co.jpを例にしましたが、現実にはhttp://のURLを持つすべてのサイトで上記のような影響を受けうる可能性があります
http:/// [http]から始まる www.google.co.jp などのURLを使った場合には検索条件が盗聴されるうえに検索結果のすべてが汚染されて表示される可能性もあります
悪意ある行為を受け始めた時点での回避策:
もっとも最初のブラウザからのアクセスにおいて、必ずhttpではなくhttpsのURLを開く(絶対死守)。さらにhttpsのページからhttpのページへのリダイレクトは警告するブラウザ設定とし(絶対死守)、この警告を絶対に軽視せず警告が出た時点で悪意ある行為にさらされていると判断し速やかに切断する(絶対死守)
ブラウザ以外のアプリすべてにおいて、上記のような動作をしないアプリがないかを常に確認し、上記のような動作をしないアプリは一切使わない(絶対死守)
-> で、そんなの理解してる一般人はどのくらいいます?
Re:何が懸念されるのかな? (スコア:4, すばらしい洞察)
amazonはPreloaded HSTSに登録されているので例えとして適切ではないな
・あなたはamazon.co.jpを見ようと思い、http://から始まるURLを表示するようブラウザに指示しました
この時点でブラウザがhttps://amazon.co.jpへ自動的にリダイレクトします
というわけで一般人は何も考えなくてもセキュアにamazonを利用できるというわけだ
Re:何が懸念されるのかな? (スコア:1)
書いてあることに基本的には同意ですけど、今はHSTSやHSTSプリロードがあるので、
もっとも最初のブラウザからのアクセスにおいて、必ずhttpではなくhttpsのURLを開く(絶対死守)。
は絶対死守でもないでしょう。
一般人なら、アドレスバーにURLを入力するなんて滅多にやらないと思います。ググったり、せいせいブックマークからのアクセスでしょう。グーグルなら、当然HSTSプリロードに入っているし、ブックマークならちゃんとhttpsのURLになっていれば良いわけです。
というわけで、みんなHTTPSに移行して、さらにHSTSなりHSTSプリロードに対応していけば、ウェブについては最低限安全が保たれると言って良いのではないでしょうか。
ブラウザは「amazon.co.jp」ではなく悪意ある(Unicodeを駆使し目視ではまったく判別がつかない)「amazon.co.jp」を表示し、
今時のウェブブラウザでは、Unicodeの微妙な記号を使うとPunycodeをデコードせずxy--で始まる生の表記になるようです。詳しい人間ならアドレスバーで見分けられると思います。
Re: (スコア:0)
> というわけで、みんなHTTPSに移行して、さらにHSTSなりHSTSプリロードに対応していけば、
> ウェブについては最低限安全が保たれると言って良いのではないでしょうか。
> 詳しい人間ならアドレスバーで見分けられると思います。
現在の一般人向けのセキュリティの話において、自論に都合のいい未来での話をされても
また繰り返しになりますが
「公衆WIFIを喜んで使う一般人のレベル」で話をしないと意味がないと思いますよ
Re: (スコア:0)
たしかに、「みんなHTTPSに移行して~」は(来るかどうか分からない)未来の話です。でも、Amazonみたいな、パスワードなどで機密情報を扱い、一般人が使うほど知名度があるサービスなら、もうみんなHTTPSに移行していて、ある程度は現在でも通用する話だと思ったのですが、甘く考え過ぎでしたでしょうか?
「詳しい人間ならアドレスバーで見分けられると思います。」と書いたほうはまた別の話で、未来永劫すべての一般人にこの方法を普及させるのは無理だと思っているから、「詳しい人間なら」と前置きしました。
Re:何が懸念されるのかな? (スコア:2, すばらしい洞察)
一般人は、HTTPかHTTPSかなんて一切気にしないっつーかそもそもURLなんて見ていない。
アマゾンって書いてあるんだからアマゾンなんだろって程度。
マイクロソフトなんちゃら~って偽セキュリティ広告を鵜呑みにしてマルウェアインストールし、
「マイクロソフトっていってるんだから偽物のわけがない」
と宣うのが一般人ですよ。いやマジで。
たとえ理系でも情報系に興味ない人ならその程度。
Re: (スコア:0)
一般人はWindows 10とかmacOS Sierra以上でEdgeとかSafariを使うでしょ? どっちもHSTSにもcertificate pinningにも対応してるよ。
Windows 8とかMac OS X Mavericksのような古いOSを排除するのは管理者の義務だよ。
Re: (スコア:0)
> Windows 8とかMac OS X Mavericksのような古いOSを排除するのは管理者の義務だよ。
そういうのはさんざんWindows10ネガキャンして移行を阻止しているアンチMSの方々に言ってください
Re:何が懸念されるのかな? (スコア:1)
偽APに引っかかってる場合などではDNSまで悪意あるものになります
ここで一般人がDNSまで悪意あるとした場合に正しくその異常性を把握し回避行為を取るのは現実的に無理です
また、経路上で介入される場合はたとえ正しくSSL処理がされていてもクッキーは改ざんされます
ここを知らない人はとても多いです
さらに、ルーター自体が悪意あるものであればそこから直接、
そうでなくとも暗号化の部分がそもそもない/クラックされたら
近隣のwifiクライアント端末から飛び込みで
悪意のあるパケットがバンバン飛び込む状況となります
もちろん盗聴もされます
Re:何が懸念されるのかな? (スコア:1)
>ここで一般人がDNSまで悪意あるとした場合に
この場合、(ブラウザ等による)証明書のエラーが出ませんか。
>正しくSSL処理がされていてもクッキーは改ざんされます
この正しく処理というのは、証明書のエラーも出ない状況でしょうか。
確かに AP自体が偽物だと危険度はぐっと上がりそうですが
>悪意のあるパケットがバンバン飛び込む状況となります
これはブロックされるし、
>もちろん盗聴もされます
IPヘッダは読めてもペイロードは復号できませんよね。
(全くトンチンカンな事を言ってたら恥ずかしい限りですが)
Re:何が懸念されるのかな? (スコア:2)
一般人にとっては証明書のエラーなど無視一択かと。
Re:何が懸念されるのかな? (スコア:2, 参考になる)
Microsoft Edge, Mozilla Firefox, Google Chromeとかの通常のブラウザでは、「危険を覚悟で進む」という選択肢は与えられない [badssl.com]よ。
IE8とかの一般に使ってはいけない特殊な環境では知らないけど。
Re:何が懸念されるのかな? (スコア:1)
#3233901 に半分くらいのことが書いてあるのでそちらを参照
残り
> この正しく処理というのは、証明書のエラーも出ない状況でしょうか。
SSL上でもクッキーが改ざんされるという件では、証明書エラーは出ません
> IPヘッダは読めてもペイロードは復号できませんよね。
安全にVPN経路が結ばれたあとの話、かつVPN経路上の通信だけに限定すればそうなります(VPN自体の強度は別の話)が、
VPN経路を結ぶ前の時点ですでにセキュリティリスクがあること、
VPN経路を結んだあとでも、多くの場合はVPNを通さない通信も許可されることなどの考慮が必要です
例:社員をVPN接続させるサービスにおいて、
クライアントPCのすべての通信をVPN経由にさせる設定とすると
クライアントPC上のブラウザの通信とかメーラとかWindowsUpdateとかも全部VPN経由で自社ネットワークを通る高負荷構成になる
対策としてVPNを通すのはあくまでも自社VPN(のGWサーバのIP)向けの通信にだけ限定するなど
Re: (スコア:0)
「正しくSSL処理してても(上位レイヤの)クッキーを改ざんできる」とは、画期的なことかもしれぬ。
詳細キボンヌ。
# MITM 攻撃のことを言っているのかもしれんけど、それは証明書チェーンが汚染されていることが
# 前提なので、「正しくSSL処理されている」とは言わんし。
Re: (スコア:0)
「SSL クッキー 改ざん」でググってみてください
secure属性を指定しても改変はされ、secure属性を指定しない場合さらに盗聴もされます
ここで残念なことですが、
secure属性をつけていても改ざんされるということを知らないままWebに公開するサイト/サービスを構築している例は非常に多いです
Re:何が懸念されるのかな? (スコア:2, すばらしい洞察)
親ACです。
徳丸せんせいのページを見てみました。
何が言いたいのか、大体理解したつもりです。画期的という感じではないですが。
経路上のルータ機器で FQDN が同一な HTTP 偽サイトへ誘導することで、
(1) secure 属性がない Cookie が平文で送られる。(取得・盗聴)
(2) 偽サイト上で Cookie を設定する。(作成・改ざん)
ということが可能だ、ということですよね。
嘘は言っていないけど、だから? という感想を持ちました。
正規のサービス/サイト側で、クライアント(ユーザ)から送られてくる Cookie の内容を
完全に信じて処理する時点で、サービス側の設計不備でしかないな、と。
# 単なる不用心というか。
セキュリティ確保の観点で啓蒙することは大事だと思うので、ぜひ進めて下さい。
Re: (スコア:0)
HTSTにすりゃ解決する問題
Re: (スコア:0)
ググったけど改竄や盗聴をされるなんて書いてるところはなかったぞ
Re: (スコア:0)
IPレイヤでの通信暗号化なんて広まってる?
Re:何が懸念されるのかな? (スコア:2)
ちゃんといえば個別の暗号化が進んでいるのは TCP/UDP の上にのっかってる部分ですね。
Re: (スコア:0)
IPSec。。。違うか
たぶんSSLのことが言いたかったんだと思うけど、IPレイヤではないよね。
アプリ層(L5-7)がしっくりくる感じ。
Re: (スコア:0)
WEPや暗号化なしのオープンWi-Fiって全体的の設計でセキュリティ考えてないだろうから、
認証サーバや各種ネットワーク機器に何か仕掛けられてても不思議ではない、
というところは?
いや仕組とかは詳しくないんで完全に妄想なんですけどね。