アカウント名:
パスワード:
「セキュリティの懸念」っていうけれど「遺伝子組み換え野菜への懸念」程度のモヤッっとしたものでは? なんとなく危ないんちがうか?程度で実際的な被害があるのか明確になってません。
>暗号化されていないWi-Fiネットワークのセキュリティを懸念」
ここに注目して話をするのですが、IPレイヤでの個別の通信の暗号化が進んでいるので何が危ないのかな? と。
昔、第一に心配したのはSMBによる共有ですが、それは非Windowsでは関係がない上、今は暗号化されたSMB3.11ですよね。さらにいうと最近の人って SMB共有って使ってる人いるんでしょうか・・。
>オンラインバン
偽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にすりゃ解決する問題
ググったけど改竄や盗聴をされるなんて書いてるところはなかったぞ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
何が懸念されるのかな? (スコア:5, すばらしい洞察)
「セキュリティの懸念」っていうけれど「遺伝子組み換え野菜への懸念」程度のモヤッっとしたものでは? なんとなく危ないんちがうか?程度で実際的な被害があるのか明確になってません。
>暗号化されていないWi-Fiネットワークのセキュリティを懸念」
ここに注目して話をするのですが、IPレイヤでの個別の通信の暗号化が進んでいるので何が危ないのかな? と。
昔、第一に心配したのはSMBによる共有ですが、それは非Windowsでは関係がない上、今は暗号化されたSMB3.11ですよね。さらにいうと最近の人って SMB共有って使ってる人いるんでしょうか・・。
>オンラインバン
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)
ググったけど改竄や盗聴をされるなんて書いてるところはなかったぞ