- ベストアンサー
OKWaveの質問は暗号化されていない？
はじめまして。 表題の通りなのです。 OKWaveはログイン時にはhttpsでサーバ・クライアント間の通信を 暗号化しているようですが、質問を投稿する時は、httpsが表示されていない ため、平文のまま通信しているのでしょうか？ もし、そうであるならば、質問内容は傍受可能ということでしょうか？ （私が何を質問したのか、ネット盗聴者にはバレている？） 有知識者さま、教えて下さい。
- ネットトラブル
- 回答数5
- ありがとう数5
- みんなの回答 （5）
- 専門家の回答
質問者が選んだベストアンサー
その他の回答 (4)
- 774danger
- ベストアンサー率53% (1010/1877)
他の方も書かれているとおり、いずれ公開されるデータを暗号化して送る意味は全くないでしょう であれば、httpよりもhttpsで送信するほうが多少なりとも暗号化による処理でサーバ/クライアントに負荷がかかりますから、少しでも(特にサーバ側の)負荷を軽くするためにhttpを使うのは当然かと思います 少し大きな会社なら掲示板のようなものへの書き込みは全て保存していたりするので、OKWaveも含め不用意に書き込みを行わないほうが無難 まあそもそも盗聴なんかしなくても、 http://mlab.dyndns.org/okgoo/ でIDで検索かければ過去にどんな質問しているのかバレバレですし
お礼
回答して頂きありがとうございます。 お礼が遅くなり申し訳ございません。 回答頂いたサイトは何ですか？ 危ないサイトですか。 怖いです。
- koi1234
- ベストアンサー率53% (1866/3459)
既に回答ついてる重複になってしまいますが平文で流れていても 質問者さんが心配されている 「私が何を質問したのか、ネット盗聴者にはバレている」 には直結しません その盗聴者が家族で同一LAN内でPC使ってる とかいうことなら話が変わりますけど 全くの第3者が簡単にそういった特定をすることは不可能と思って問題ありません ※ 技術的な話でいえばできなくはないけどそういった行為は本人の人生を 狂わすのに十分なリスクを負ったうえで実行することとなります それなりの権限持った連中がそれなりの手続き踏んだうえで調べれば わかりますので暗号化されているから特定できないといったこともありません 仮にそういったように感じられることがあるなら 他の箇所でのデータのやり取りが似ているとか 同一IDであるとかで 相手が勝手に想像してかま懸けてるだけだと思ってください
お礼
回答して頂きありがとうございます。 御礼が遅くなり申し訳ありません。 安心しました。
- Shin1994
- ベストアンサー率22% (551/2493)
有識者ではないですが回答させていただきます。 そういう事になりますけど、別に暗号化される必要はないと思います。OKwaveも、そのことは分かっていると思います。だって、どうせ公開される情報をわざわざ暗号化する意味がないではないですか。傍受されても、なんの問題もないし問題になるような情報をこうした公共の場に書くこと自体間違ってるわけですから。
お礼
回答して頂きありがとうございます。 お礼が遅くなり申し訳ありません。
平文だったと思います。 ログイン時はパスワードがあるのでSSLを使いますが、質問文はこうやって公開される物なので、それを暗号化しても意味がありませんからね。 SSLで無駄にサーバーのパワーを使う必要も無いですし。 > もし、そうであるならば、質問内容は傍受可能ということでしょうか？ OKWaveの質問はネットで誰でも見ることができるのでそれを傍受というなら、可能と言う事になりますが、普通は傍受とは言わないと思います。
お礼
回答して頂き、ありがとうございます。 お礼が遅くなり、申し訳ありません。
関連するQ&A
- MySQLのログインを暗号化できますか？
MySQLのログインを暗号化できますか？ connectを張るときに"user id=○○; password=××; database=△△;Data Source=■■" をインターネット経由で送ってます。 この部分はオラクルだとデフォルトで暗号化されてるが、 MySQLでは平文のままだという話をききます。 1.平文のまま流れてるというのは本当なんでしょうか？ 2.もし、平文のままなんだとすると、SSLみたく暗号通信化する方法は MySQL自体に実装されてるんでしょうか？ それとも自前でトンネルを掘る必要があるんでしょうか？ 平文のまま流れてるなら、いつかは盗聴されるように感じています。 上記について、ご存知の方おられましたらよろしくお願い申し上げます。
- ベストアンサー
- MySQL
- 公開鍵暗号について
失礼します。 公開鍵暗号についてです。 Linux系OSカテゴリで質問することではないかもしれませんが、 sshサーバーの設定の際に疑問になったことなのでここで質問させてください。 公開鍵暗号方式について無勉強だったので調べていると、 Wikipediaより、 １．通信を受ける者（受信者）は自分の公開鍵（暗号化のための鍵）P を全世界に公開する。 ２．受信者に対して暗号通信をしたい者（送信者）は、公開鍵 P を使ってメッセージを暗号化してから送信する。 ３．受信者は、公開鍵 P と対になる秘密鍵（復号のための鍵）S を密かに持っている。この S を使って受信内容を復号し、送信者からのメッセージを読む。 ４．暗号通信を不正に傍受しようとする者（傍受者）が、送信者が送信した暗号化されたメッセージを傍受したとする。傍受者は、公開鍵 P は知っているが、秘密鍵 S は受信者だけが知っている情報であるので分からない。P から S を割り出すことは（計算時間的に）極めて難しい。そのため、暗号文を復号することはおよそできない。 とありました。 sshを使ってサーバーにアクセスする場合、秘密鍵はクライアント側が持つことになりますが、 そのとき、サーバーからクライアントへのデータは秘密鍵があるので解読できるのは理解できます。 しかし、その反対はサーバー側に秘密鍵がないので無理なのでは？ 不勉強でここで悩んでいます。 どなたかご教授いただけないでしょうか？ また、ssh用に作成した秘密鍵は「厳重に保管しておく」とよく書かれていますが、 具体的にどうするのかはっきりしません。 パスワード保護でもすればよいのでしょうか？ これについても宜しくお願い致します。
- ベストアンサー
- Linux系OS
- FTPSの暗号化範囲について
FTPクライアントからFTPサーバへファイルを置こうと しています。 FTPはIDとPWが平文であるため、FTPSを使おうと 考えています。 ここで、疑問なんですが、IDとPWは暗号化されるはずですが 実際やりとりするファイル自体は暗号化されて流れる のでしょうか？ 通信速度が遅くなるため、IDとPWのみが暗号化されて ファイル自体のパケットは暗号化せずに回線に流すのが希望です。
- ベストアンサー
- ネットワーク
- AES暗号は解けるのでしょうか？
米ニューヨーク・タイムズ紙(9月27日付)によると、オバマ民主党政権は来年の連邦議会に向け"盗聴法改正法案"を準備している。今回の改正では、インターネット向け通信傍受の強化をねらっており、ブラックベリー端末による暗号メールやフェースブックなどのソーシャル・ネットワーク、スカイプのようなP2P電話などが含まれている。 という話ですが、 せっかく盗聴しても、AESで暗号化されていて解読できなければせっかく法律を改正しても意味が無いように思えます。 アメリカ政府は、標準として推奨しているAES暗号を解けるのでしょうか？ それとも、暗号通信を奨励するためにこんな法律を提出しているのでしょうか？
- ベストアンサー
- ネットワーク
- 有線LANの暗号化
会社が雑居ビルの複数フロアにあるため、各フロア間（縦管）にUTPケーブルを通してLANを構築しています。このケーブルはビルの共用部（天井裏）を通っているため、悪意の第３者侵入による情報傍受の危険性があります。（UTPケーブルを切断して加工し、リピータハブやネットワークタップを付けて情報を抜き取る） そこで、有線LANの通信内容を暗号化したいと考えております。 質問(1) クライアントには何もソフトをインストールせず、ネットワーク機器だけで暗号化を実現する場合、どのような方法があるか、教えてください。 質問(2) クライアントにソフトをインストールすることにより、安価に対応できる方法があれば、教えてください。 なお、縦管のLANの通信速度は1Gbit/sで、すべてIPによる通信です。暗号化以外の方法でも、第３者による情報傍受を防ぐ方法があれば、構いません。ルータを各階に設置してIPsecも考えましたが、1Gbit/sを実現するためには費用がかかりすぎて断念しました。
- ベストアンサー
- ネットワーク
- SSLじゃない通信は危険？
SSLで暗号化していない通信は傍受（盗聴）されて危険なのでしょうか？ 無線だけの問題ですか？ 無線でもWPAなどで暗号化されていればSSLは不要ですか？
- ベストアンサー
- ウィルス・マルウェア
- 自己署名証明書（オレオレ証明書）の暗号化について
SSL暗号化通信の仕組み自体は，下記URLの通りとして把握しております． (1*) http://www.twsvc.com/about_ssl (2*) http://www.ibm.com/developerworks/jp/websphere/library/web/web_security/pdf/2_6.pdf これを，オレオレ証明書を用いた暗号化通信で考えると，セキュリティに関する識者である高木氏は，自分の日記にて以下のように書いています． >共通鍵暗号による暗号化通信をしています。鍵は一緒に配送します。この暗号は正常に機能しているでしょうか？ >「今の話は共通鍵暗号じゃなくて公開鍵暗号だろ」って？ オーケー、では、次の比較に対してどう答えるか。 >1.共通鍵暗号による暗号化通信 >2.公開鍵暗号による暗号化通信で認証なし（認証検証時の警告を無視する使用形態） >3.公開鍵暗号による暗号化通信で認証あり （略） >では、1.と 2. を比べたときはどうか。「3.ほどではないが 1.よりは 2. の方がまし」と言えるだろうか？ それは誤りである。 （略） >公開鍵暗号の公開鍵がいっしょに配送されている暗号化通信では、傍受点で、流れてきた鍵を、別途用意した自作鍵に差し替えて流してしまえば、それで暗号化されて戻ってくる暗号文を復号できる。 ※詳細は，高木氏の「PKIよくある勘違い(1)「オレオレ証明書でもSSLは正常に機能する」」をご参照ください． ここで，疑問になるのが，”傍受点で、流れてきた鍵を、別途用意した自作鍵に差し替えて流してしまえばいい”という点です． オレオレ証明書では，ルート証明書にたどり着けないため，ブラウザはオレオレ認証局の公開鍵をもっていない． そのため，サーバ証明書内の公開鍵を取得できない． だから，サーバ証明書送付時にオレオレ認証局の公開鍵を送付する必要がある． オレオレ認証局の公開鍵を用いて，サーバ証明書から公開鍵を抜き出す もしこのとき，オレオレ認証局の公開鍵が自作鍵に置き換えられたとしても，ただ単にサーバ証明書から公開鍵を抜き出すことができず，そこで通信が終了すれば”それで暗号化されて戻ってくる暗号文を復号できる”ことも無いように思えるのですが，いかがでしょうか． （つまり，高木氏の言う差し替えた自作鍵でサーバ証明書内の公開鍵が取得できるかどうか） これができなければ，確かに暗号化通信（というか通信そのもの）自体は破綻していますが，高木氏の懸念しているような「重要な情報の流出」にはつながらないように思えます． 乱文になってしまいまして申し訳ありません． もし，私自身に勘違いや解釈違い等ありましたら，ご指摘いただけると幸いです． よろしくお願いします．
- ベストアンサー
- ネットワーク
- メールのパスワードは複雑にしてもしょうがない？
ふつう、インターネットのメールは暗号化されていなくて、平文でサーバ間を流れていますよね？ だから、もし暇な人が悪いソフト（？）を使って盗聴していたら、全部内容を読まれてしまう。従って、クレジットカードの番号などは書いてはいけない。 ・・・昔、こう教わった気がします。 ところで、popサーバにログインするときのパスワードは暗号化されていないのでしょうか？ 例えば、Outlook Express で、popサーバからメールを取ってくるとき、Outlook Express が popサーバにパスワードを送ると思うのですが、これも暗号化されていないのでしょうか？ そうだとすれば、「記号・数字を混ぜてパスワードを分かりにくいものにしろ。辞書などで推測しにくいものにしろ」というのは気休めのような気がするのですが、どうでしょうか？
- ベストアンサー
- ネットワーク
- HTTPS通信の盗聴について
HTTPS通信の盗聴リスクについて教えてください。 たとえばログイン認証画面において、 HTTPSでWEBサーバーにIDとPASSWORDを送信したとします。 この通信内容を第三者が盗聴したとして、通信内容は 暗号化されているので解読は不可だと思いますが、 盗聴した内容をそのまま流用すれば第三者でもログイン可能 になる可能性はありますでしょうか？ それとも、HTTPS通信の内容をキャプチャした情報を再利用することは不可能なのでしょうか？
- 締切済み
- ネットワーク
お礼
回答して頂きありがとうございます。 お礼が遅くなり申し訳ありません。