質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.48%
セキュリティー

このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。

SSL

SSL(Secure Sockets Layer)とは、暗号化されたプロトコルで、インターネット上での通信セキュリティを提供しています。

Q&A

解決済

4回答

4287閲覧

SSL通信と公共フリーWifiにおいて、具体的なリスクを知りたい。

takoyaki9

総合スコア9

セキュリティー

このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。

SSL

SSL(Secure Sockets Layer)とは、暗号化されたプロトコルで、インターネット上での通信セキュリティを提供しています。

2グッド

10クリップ

投稿2018/11/24 13:58

編集2018/11/28 08:10

#知りたいこと
(1)SSLのサイトしか使わないなら公共のフリーWifiでパスワードや重要な通信を行ってもOK?
(2)非SSLサイトでも公共Wifiなど攻撃者と同じネットワークの中にいないなら大丈夫?
(3)公共のフリーWifiを使っていても、パスワード等の重要な通信を行わなければ問題ない?(非SSL通信で)
(4)非SSLと公共フリーWifiの具体的なリスクを知りたい

####(1)SSLのサイトしか使わないなら公共のフリーWifiでパスワードや重要な通信を行ってもOK?
フリーWifiの問題点は下記だと認識しています。

攻撃者と同じネットワークに入ってしまう可能性があり、
パケットキャプチャ等を使われるとSSL通信以外の通信が平文で見られてしまい
パスワード等の重要情報が見られてしまうこと

上記で正しいなら、
SSLサイトしか使わないなら
公共のフリーWifiは重要なサイトでログイン等を行ってもOKということでしょうか?

もし、ブラウザが保持しているクッキーやローカルストレージの値まで見られてしまうということであれば
SSLなどは関係無しに危ないと思うのですが、
通信中のパケットだけが攻撃対象なら大丈夫なの?と疑問に思っています。

###(2)非SSLサイトでも公共Wifiなど攻撃者と同じネットワークの中にいないなら大丈夫?
(1)の認識から、
SSLじゃなくても公共Wifiなどを使わないなら傍受のリスクはない?と疑問に思っています。

###(3)公共のフリーWifiを使っていても、パスワード等の重要な通信を行わなければ問題ない?(非SSL通信で)
(1)の認識から、
そのように思っています。

###(4)非SSLと公共フリーWifiの具体的なリスクを知りたい
セキュリティに関して、
具体的にどういった理由でどのようなリスクがあるのかを知りたいです。

例えば、
公共のWifiは通信が傍受される可能性があるから危険
といった抽象的な話ではなく、

下記のように
どのような手法でどのような被害が起こるのかを教えていただきたいです。

(例)
パケットキャプチャは同じネットワーク内のパケットを見ることができ、
非SSL通信でのパケットにはパスワード等が平文で記載されている。
そのため、公共Wifiで非SSLを行っているサイトに(パスワードを入力して)ログインを行うと、
パケットキャプチャによってパスワードがバレてしまい、
傍受したパスワードを利用してサイトになりすましログインされてしまうリスクがある。

不足している情報等があれば
補足させていただきますので
以上、よろしくお願いします。

追記 2018.11.28
ockeghem様のご回答で
かなり理解が進んだのですが、
その中でまだ理解が怪しい箇所があるため、

ockeghem様とのコメントのやりとりに関して
ご回答をお待ちしております!

yodel, annderber👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答4

0

ベストアンサー

(1)SSLのサイトしか使わないなら公共のフリーWifiでパスワードや重要な通信を行ってもOK?

基本的にはYESです。
しかし、「SSLのサイトしか使わない」というのは実は難しいことです。takoyaki9さんはスマホを使っていませんか? そして、スマホを使っている場合、スマホアプリのすべてがSSLを使っているか否かを把握していますか?
そういう問題意識から以下のようなブログ記事を書いたことがあります。

最近は多くのスマホアプリでSSLを使うようになってきましたが、まだHTTPがゼロというわけではないですし、利用者からSSLの利用有無はわからないので、すべてのサイトでSSLを使うという運用には困難があると思います。

(2)非SSLサイトでも公共Wifiなど攻撃者と同じネットワークの中にいないなら大丈夫?

そうとは限りません。基本的な前提として、インターネット上の盗聴などは無線LAN環境のみで起こるわけてはなく、また、利用者の近傍のネットワークでのみ起きるとは限らないからです。
サイト側で起こる問題として、サーバーへの侵入以外に以下の可能性があります。

  • DNSに対する攻撃
  • ARPスプーフィング

DNSに対する攻撃にも複数の種類がありますが、割合多いのはDNSのレジストラが狙われるケースです。

ARPスプーフィングとして、さくらインターネットの事例が有名ですが、利用者のネットワーク環境で起こる可能性もあります。

(3)公共のフリーWifiを使っていても、パスワード等の重要な通信を行わなければ問題ない?(非SSL通信で)

基本的な前提として、ネットワークの盗聴の可能性がある場合の多くで、改ざんの可能性もあります。以前私が書いた以下の記事も参考になると思います。

なので、重要な情報を送信しないからと言って安全とは限らず、偽の情報をつかまされる可能性も考える必要があります。
ネットワーク盗聴には他の方法もありますが、詳しくはセキュリティの教科書等を参照ください。

(4)非SSLと公共フリーWifiの具体的なリスクを知りたい

これは個別に書いていくと大変なので、今までに示した参照記事をご覧ください。特に、最後の記事が参考になると思います。


コメント頂いた内容について追記します。

■その1
DNSハイジャックが起こると、
URLとIPアドレスの関係が正しくなくなるので、

リクエスト内容が意図したサーバに届かなくなる可能性がある。
(本来リクエストを飛ばそうとしたサーバではなく、攻撃者に仕組まれたIPアドレスのサーバへリクエストを送ってしまう)

これは正しいですね。

そのため、攻撃者と同じネットワークにいなくても
リクエスト内容が見られてしまう可能性があるという理解で合っているか
(この場合、パケットを途中で盗聴する訳ではなくリクエスト自体が攻撃者のサーバに届いてしまうので、SSLでも非SSLでもリクエスト内容がバレてしまう。)

これも正しいです。
SSLの場合は注釈が必要です。盗聴には、攻撃者が用意したサーバーに正規のサーバー証明書が入っている必要があります。しかし、ドメイン名ハイジャックされた状態ではサーバー証明書を作ることができるので、結果として、SSLの場合でも盗聴できる可能性が高いと言えます。

■その2
用語に関して下記のような認識を持っています。
「レジストリ」= IPとURLの組み合わせを知っているトップドメイン
「レジストラ」= レジストリにその組み合わせを登録する人

これは違います。
レジストリは.JPや.COMのようなトップレベルドメイン(TLD)を仕切っている組織のことです。たとえばJPドメインを仕切っているのはJPRSですから、JPRSはJPドメインのレジストリということになります。
レジストラはドメイン名の販売代理店と考えるとわかりやすいと思います。お名前.COMを運営するGMOインターネット株式会社はレジストラの例です。ただし、レジストラは単にドメイン名を販売するだけでなく、ドメイン名の管理システムをユーザーに提供します。

上記の理解が正しい場合、レジストラが狙われるとはつまり、
悪意のあるユーザがレジストラに不正アクセス等を行って、
そこから(攻撃者がレジストラを経由して)レジストリに誤った情報を登録するという理解で合っていますでしょうか?

これは概ね正しいですね。レジストラが狙われるというのは、前述したレジストラ提供のドメイン名管理システムが攻撃されるということです。レジストラのシステムはレジストリのシステムにつながっているので、結果としてレジストリが管理する情報が書き換えられることになります。

■その3
ARPスプーフィングされると、
ARPキャッシュ(IPとMACアドレスの組み合わせを保存しているキャッシュという理解です。)が
意図しないものに書き換えられる(IPとMACアドレスが不一致した状態になる)ので
その1と同様に攻撃者にリクエスト内容が見られてしまう。

そのとおりです。

■その4
DNSハイジャックもARPスプーフィングも一言でいうなら、
「URLを入力してアクセスしたが、そのリクエストが意図したサーバへ届かない」という理解で合っていますでしょうか?

そのとおりです。

■その5
DNSハイジャックされている場合、
URLとIPが一致しない状況になるので、
ブラウザ上でhttpsでアクセスしているつもりでも
実際はSSLになっていないという状態も起こりうるのでしょうか??

違います。違うのはIPアドレスのみですし、ブラウザ上でhttpsであれば実際の通信もhttpsです。

投稿2018/11/25 03:16

編集2018/11/28 11:59
ockeghem

総合スコア11701

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

takoyaki9

2018/11/28 08:00

参考サイトまで添付して頂きありがとうございます! 非常に勉強になりました! ご回答いただいた内容を 自分なりに噛み砕いていて、 5点ほど理解が怪しいところが合ったので 認識が正しいかどうか見て頂けないでしょうか?? ■その1 DNSハイジャックが起こると、 URLとIPアドレスの関係が正しくなくなるので、 リクエスト内容が意図したサーバに届かなくなる可能性がある。 (本来リクエストを飛ばそうとしたサーバではなく、攻撃者に仕組まれたIPアドレスのサーバへリクエストを送ってしまう) そのため、攻撃者と同じネットワークにいなくても リクエスト内容が見られてしまう可能性があるという理解で合っているか (この場合、パケットを途中で盗聴する訳ではなくリクエスト自体が攻撃者のサーバに届いてしまうので、SSLでも非SSLでもリクエスト内容がバレてしまう。) 以上の理解で合っていますでしょうか? ■その2 用語に関して下記のような認識を持っています。 「レジストリ」= IPとURLの組み合わせを知っているトップドメイン 「レジストラ」= レジストリにその組み合わせを登録する人 上記の理解が正しい場合、レジストラが狙われるとはつまり、 悪意のあるユーザがレジストラに不正アクセス等を行って、 そこから(攻撃者がレジストラを経由して)レジストリに誤った情報を登録するという理解で合っていますでしょうか? ■その3 ARPスプーフィングされると、 ARPキャッシュ(IPとMACアドレスの組み合わせを保存しているキャッシュという理解です。)が 意図しないものに書き換えられる(IPとMACアドレスが不一致した状態になる)ので その1と同様に攻撃者にリクエスト内容が見られてしまう。 という理解で合っていますでしょうか?? ■その4 DNSハイジャックもARPスプーフィングも一言でいうなら、 「URLを入力してアクセスしたが、そのリクエストが意図したサーバへ届かない」という理解で合っていますでしょうか? ■その5 DNSハイジャックされている場合、 URLとIPが一致しない状況になるので、 ブラウザ上でhttpsでアクセスしているつもりでも 実際はSSLになっていないという状態も起こりうるのでしょうか?? 長文になってしまい恐縮ですが、 ご教示頂けると嬉しいです!
takoyaki9

2018/11/29 10:41

コメントに対するご回答までご丁寧にありがとうございます!! レジストラとレジストリが曖昧だったのですが、 具体例を出して頂いたおかげで 理解できました! 今回でめちゃくちゃ勉強になりました!! ありがとうございました!
guest

0

概ね正しいと思います。
他には、

Wifiアクセスポイントの設定で、子機同士で通信出来る設定になっている場合は(あまりないと思いますが)、自機のOSやアプリに脆弱性があると、そこを攻撃される可能性があります。

イービルツイン(evil twin)という、偽物のアクセスポイント(SSIDやパスワードが公開されていれば作るのは簡単)に間違って繋いでしまう可能性があります。
この場合でも、そこを経由して本物のサイトに繋いだ場合は、SSLの場合はエンドエンド間で暗号化するので(電波を盗聴されるのと同じくらい)大丈夫ですが、偽のサイトに繋がされた場合は、危なそうです。もちろん、SSLでないと全部見られます。

投稿2018/11/24 15:00

otn

総合スコア84499

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

公共フリーWifiとしてますが、果たしてそれが本当の公共フリーwifiかどうかどうやって判断するんでしょうか。

投稿2018/11/24 22:34

y_waiwai

総合スコア87747

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

無線技術を使用した通信の危険性と、信頼性の低いネットワークを使用する危険性は全く別物です。

・無線技術の危険性
電波の届く範囲で、通信内容の漏洩の危険があります。アクセスポイント-端末間のセキュリティはアクセスポイント側に主導権があるので、適切な対応(暗号化/脆弱性対策等)がなされていない場合、通信パケットが漏洩する危険性があります。https を使用した通信は、端末-サーバ間で暗号化されるため、サーバ側に問題がない限り、通常の有線接続と同程度には安全になります。

・信頼性の低いネットワークの危険性
物理レイヤからアプリケーションレイヤに対して各種トラップを仕掛けることが可能となります。名前解決すら信頼できません。物理レイヤ以上のすべてが信頼できなくなるので、https を使用していようがいまいが関係なく危険性は高いです。

投稿2018/11/24 23:11

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.48%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問