Open WiFiが暗号化されていないのはなぜですか？
私が理解している限り、パスワードを必要としないWiFiネットワークは暗号化せずにトラフィックを空中に送ります。パスワードが必要なものは、すべて同じパスワードを使用している場合でも、各接続を一意に暗号化します。
これが本当なら理由がわかりません。アクセス用のパスワードの要求と接続の暗号化は、まったく別の問題のようです。
彼らは本当にこのようにリンクされていますか？もしそうなら、私が見ない理由がありますか？一部のルーターは、パスワードなしでパブリックアクセスを許可するように構成できますが、Firesheepスタイルの攻撃を防ぐためにユーザー接続を暗号化できますか？
更新
一部の回答では、パスワードは暗号化を可能にするために必要な「共有シークレット」であると述べています。しかし、それは必要ではありません。この問題は1976年に公に解決されました。
Diffie–Hellman鍵交換方式を使用すると、互いに事前の知識がない2つのパーティが、安全でない通信チャネルを介して共有秘密鍵を共同で確立できます。 （ http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange ）
（ほとんどの人にとっての）問題は、矛盾していることです。定義上、人々は「オープンWiFi」は「暗号化されていないWiFi」を意味すると考えます。私には、「1997年に 802.11 を書いた人々がなぜ標準的な方法で決定したのかと尋ねているようです。彼らがやった？"
短い答え-私たちは彼らに尋ねる（または、インターネット上に浮かんでいるディスカッションドキュメントがあるかどうかを確認する）ことによってのみ知ることができます。
ただし、質問のFiresheep部分については説明できます。 「Firesheep」攻撃は、サイトに対してユーザーを認証するCookieが攻撃者によってコピーされる特定のタイプの攻撃です。
唯一の要件は、攻撃者がCookieを取得できることです。したがって、 単一の事前共有キーを使用するWEP、WPA、またはWPA2を使用するWiFiネットワークは脆弱です 、攻撃者がキーを持っている場合。そしてもちろん、多くの中小企業が単一のキーを使用してWiFiアクセスを提供しています。
「より良い」アクセスポイントを用意することは、この問題を修正するためのコストのかかる方法であり、上記の攻撃シナリオ（攻撃者が ARPポイズニング に加えて man-in -the-middle HTTPのみのサイトに対する攻撃）。
したがって、ソリューションに関する限り、最善かつ最も有用なのは、HTTPSの広範な実装です（ 推奨 Firesheepの作成者、Eric Butlerによる）。
FiresheepはWiFi暗号化とは何の関係もありません。あなたと私が両方とも暗号化されたWiFi接続を使用している場合でも、データをFiresheepすることができます。
Firesheepの機能はルーターレベルで発生します。空気の波を遮りません（まあ、正確ではありません）
基本的に、それは ARPスプーフィング 攻撃を実行します。この種の攻撃は、LANネットワークでも実行できます。それは与えられたIPに対応するMACアドレスについてルーター嘘を供給することを含みます。ルーターが特定のIPにパケットを配信する場合、そのIPの所有者を見つける必要があります。キャッシュにこのデータがない場合は、これらの詳細を要求するメッセージをブロードキャストします。サブネットワーク上の誰もがブロードキャストに応答して、IPが自分のものではないと言ってもかまいません。これを使用すると、攻撃者はルーターと通信チャネルの犠牲者の間に真っ直ぐに座ることができます。
明確にするために：これは、TCP/IP（ネットワークを駆動するプロトコル）の問題です。 WiFiではありません。
他の回答では、Firesheepスタイルの攻撃（基本的には MitM trhough ARPスプーフィング ）はWiFi自体とは関係がないことをすでに説明しています。これは link-layer の問題です。
オープンWiFiネットワークに暗号化がない理由については。まあ、彼らはそうではありません。なぜ彼らがそうしないことにしたのか本当にわかりません。推測しかできません。非常に明白な理由の1つは、誰でもアクセスポイント（AP）になりすまし、被害者と暗号化された接続をネゴシエートできるため、MitM攻撃です。これにより、APの所有者がアクセスポイントの信頼できる証明書を取得した場合、 [〜＃〜] pki [〜＃〜] 問題が発生します。しかし、それでは、APのIDを確認する必要があるため、Open Wifiネットワークの目的全体が無効になります。
「JFK Airport AP」が本当にJFK空港のアクセスポイントであることをどのように知ることができますか？ 「JFK AP」というアクセスポイントの証明書を発行する必要がありますか？それはソーシャルエンジニアリング攻撃につながりますか？自分の証明書を作成して、友人が私のネットワークに接続するときに信頼するように頼む必要がありますか？もちろん、もちろん、最初に使用するときの信頼モデルを使用できると主張することもできますが、これは公園、空港、または通りのWiFiネットワークでは機能しません。
オハイオ州立大学の学生による提案 のような問題を解決するためのいくつかの提案があります、彼らはそれをダミー認証と呼びます
私たちのソリューションは、WPAおよび802.11i製品ですでに使用されているTKIPやAESなどの既存の対称キー暗号化アルゴリズムを利用して、ワイヤレスフレームをなりすましや盗聴から保護します。このセクションでは、最初に新しいダミー認証キー確立アルゴリズムを提案し、次に確立されたセッションキーを使用してワイヤレスフレームを保護します。
私は本当に好きです。少し考えれば、スニッフィングの問題およびAPのなりすましの問題（ARPスプーフィングなど）とCA発行の証明書の使用が解決されることがわかります。 。
各APには、pkおよびskのように示される公開鍵と秘密鍵のペア、たとえば、RSAキーがあると想定します。公開鍵は、CA署名付き証明書または自己署名付き証明書に含まれています。
もちろん、既存のすべてのWiFiアクセスポイントをアップグレードし、オペレーティングシステムにパッチを適用する必要があります。簡単なことではありません。
それらは同じ問題ではないということは正しいです。パスワード認証と対称暗号化は、互いに独立して実装できる完全に独立した概念です。ただし、パスワードは、暗号化の操作に必要なキーを生成するいくつかの方法の1つです。
コンピューターとAP間の暗号化接続は、対称暗号化を使用して実装されます。対称暗号化が機能するためには、両方の当事者（コンピューターとAP）が、ストリームを暗号化して後で復号化するためのキー（少量の機密データ）を共有する必要があります。
これを行う一般的な方法の1つは、事前共有キー（PSK）を使用することです。この場合、接続を試みる前に、両方の当事者がキーを認識します。これは、Wi-Fiパスフレーズを設定するときに行っていることです。ルーターにパスフレーズを入力すると、もう一度コンピューターにパスフレーズを入力すると、両方にこの情報が表示されます。キーの共有は、盗聴される可能性のあるネットワークではなく、キーボードを使用して手動で行われるため、通常ははるかに安全です。
（キーは技術的にはパスフレーズ自体ではなく、そこから導出されるいくつかのデータです。）
暗号化にはキーが必要です。これが、パスフレーズを要求される理由であり、パスフレーズがないと暗号化されない理由です。パスフレーズ以外にキーを生成する方法は他にもありますが、APでは見つかりません。
この状況を検討してください。パスフレーズがないと、キーが（強力なPRNGなどで）APによって生成される可能性があります。キーはどういうわけかコンピュータに伝達される必要があるでしょう。簡単な方法は、ワイヤレス接続自体を経由することです（APがコンピューターにデータを送信する他の手段がないと想定）。これを受信すると、接続の残りのトラフィックを暗号化できます。
問題は、キーが送信されている間は接続が暗号化されていないことです（暗号化されている場合、受信側はキーを読み取ることができません）。盗聴者は暗号化されていないキーを簡単に取得し、暗号化されていないかのように残りのセッションを監視できます。
理論家は、これが可能であるため、接続はすでに暗号化されていないのと同じくらい良好であり、CPUサイクルを無駄にしないほうがよいと言うでしょう。攻撃者が接続の開始に近づかない限り、その攻撃は効果的ではありませんが、これが当てはまらない場合（常に）を安全に想定することはできません。
非対称（公開鍵ベース）の暗号化と認証を使用して、この特定の問題を回避する方法があります。数学的な魔法を使うと、受信者以外の誰も（あなたさえも）は復号化できないデータを暗号化できますが、設定が複雑で、前回購入した時点では、APの組み込み機能ではない可能性があります。
更新：Diffie-Hellman
Diffie-Hellman鍵交換が使用されたとしても、信頼の問題はまだあります。
その理由を簡単に説明します。
- 当事者間の事前の信頼の確立なしでは、認証は意味がありません。
- 意味のある認証がなければ、DHは意味がありません。 （中間者攻撃に対して脆弱です。）
- 意味のあるDHがなければ、DH交換に基づく暗号化は意味がありません。
- 意味のある暗号化を使用しない通信は、（ほぼ）暗号化を使用しない通信と同等です。
- したがって、DHベースのデフォルトの暗号化スキームは、信頼が最初に確立されない限り、暗号化がない場合よりも実質的に安全ではありません。
- 第三者による信頼のメカニズム（PKIやWeb of Trustなど）がない場合、信頼の確立には、情報の直接的な交換（パラノイアレベルに応じて、直接、電話など）が必要です。
- 直接交換に役立つメカニズムは、少なくとも同じくらい簡単に、PSKを共有するために使用できます。
信頼を確立することは、直接の交換なしに見知らぬ人の間で解決するのが難しい問題であり、そのような直接の交換はPSKを共有するのにすでに十分です。
理論的には、直接交換を回避する1つの方法は、パブリックCAからAPのSSL証明書を購入することです。これは少し高価になる可能性があり、APの所有者は、見知らぬ人に安全なWi-Fiを提供するために追加料金を支払う可能性は低いと思います。代わりに自己署名証明書を使用することもできますが、これにはゲストが自己署名を盲目的に信頼してMITMに公開したままにするか、元の署名と照合して証明書を取得してインストールする必要があります。再び直接交換が必要です。
「パスワードなし」と「同じパスワード」について話しているとき、私はあなたが事前共有キーを参照していると思います。これは実際にはパスワードではありませんが、暗号化されたトラフィックのキー情報を安全に（少なくとも既知の値のない外部ソースから）生成して交換するために、ステーションとAPによって既知の値として使用されます。 WPA/WPA2-Personalは実際には認証せず、暗号化するだけです。
WPA/WPA2-Enterpriseは802.1Xを使用して認証を行い、認証が成功した場合は、キー情報を生成して交換します。
非常に基本的に、暗号化された通信をセットアップするには、暗号化を構築するための共通のポイントが両側に必要です。 Web（SSL/TLS）では、これは多くの場合、証明書を使用して行われますが、802.11デバイスはレイヤー2で動作するため、これらの方法の多くは使用できません。
802.11は2つのオプションを使用して、PSKまたは802.1X認証からの情報のいずれかのこの共通のポイントを提供します。
オープンWiFiが暗号化されていないのはなぜですか？
これは、 WPA-PSKがDiffie-Hellman/RSA鍵交換を使用しない と同じ理由です。
アドナンの最初のポイントは最も正確な答えです。
オープンWiFiネットワークに暗号化がない理由については。まあ、彼らはそうではありません。
技術的な理由はありません。それはおそらく財政的および/または官僚的な理由です。また、既存のインフラストラクチャを変更することは容易ではありません。
「JFK Airport AP」が本当にJFK空港のアクセスポイントであることをどのようにして知るのですか？
認証と暗号化には違いがあることに注意してください。説明されている問題は、Wi-Fi接続を暗号化しているかどうかに関係なく存在する認証の問題です。言い換えれば、RSAが認証を提供しないという事実は、RSAがオープンWi-Fiネットワークに実装されていない理由の問題とはまったく関係ありません。また、認証の問題は、次の例で説明する非常に単純な方法を使用して解決できます。
将来的には、暗号化対応のWi-FiルーターはDiffie-Hellman/RSAを使用します。ルータには、公開鍵、またはおそらく公開鍵の単純なハッシュを表示する小さなLEDディスプレイがあります。アクセスポイントは「MyHouse」と呼ばれています。
私の電話を「MyHouse」に接続したいのですが、まったく同じ名前の別のAPがあります。ルーターのモニターを見て、文字列を私の電話に表示されている文字列と比較するだけで、簡単にできます。認証が行われます。空港や公共の場所では、大画面または低コストのステッカーに公開キー/ハッシュを表示することにより、同様の手法を採用できます。
注意：LEDは一例であり、他の多くの方法が利用できます。
一部のルーターは、パスワードなしでパブリックアクセスを許可するように構成されていても、Firesheepスタイルの攻撃を防ぐためにユーザー接続を暗号化できますか？
はい、構成できますが、ルーターレベルではありません。そして、接続する側はいくつかの追加の手順を実行する必要があります。
解決策1. HTTPS Webプロキシ
HideMyAss のように、HTTPS暗号化されたWebプロキシを使用してWebを閲覧するのは、すぐに使用できる非常にシンプルな手法です。この方法では、公開キー暗号化を使用していますが、TCPレイヤーの上で行われています。
解決策2. LAN VPNサーバーまたはSSHトンネルサーバー
外部ネットワークに依存せずにローカルネットワークで同様のアプローチを使用できます。ローカルVPNサーバー/ SSHトンネルサーバーを使用します。データは次のように流れます。
ネットワークデバイス（たとえば、私の電話）> AP>ネットワークデバイス（VPN/SSHトンネルサーバー）> AP>インターネット（＃flow1）
VPN/SSHトンネルはAPの拡張として機能します。これらを精神的にカプセル化すると、次のようになります。
ネットワークデバイス（マイ電話）>暗号化されたAP>宛先。 （＃flow2）
ソリューション2.重要な注意事項！
LANソリューションを使用している場合は、VPN/SSHトンネルとAPの間で有線接続を使用する必要があります。私の回答の最後を参照してください。
これを実際に実装したい場合は、 RaspberryPi などの低電力の小さなコンピュータをSSHトンネルサーバーとして使用することができます。試してみたところ、顕著な遅延はありません。
ソリューション3.通常のVPN/SSHトンネルサーバー
LAN上にないVPNを使用すると、次のようになります。
ネットワークデバイス（マイ電話）> AP> VPN>宛先。 （＃flow3）
3つのケースすべてで、データはTLS/SSL/VPN/SSHで暗号化されているものを使用して完全に暗号化されます。
LAN VPN/SSHソリューションを使用している場合、サーバーは有線である必要があります、それ以外の場合、VPN/SSHサーバーによってクライアントから宛先は暗号化されずにAPに送信されます。
LANソリューションの詳細
LAN VPN/SSHトンネルサーバーソリューションを備えたオープンWiFiでワイヤレス接続を使用する場合、これがトラフィックの流れです。これは「flow1」の拡張で、データが暗号化されているかどうかがフローに追加されます。
ネットワークデバイス>暗号化データ> AP>暗号化データ> VPN/SSHサーバー>un -暗号化されたデータ> AP>インターネット
このため、VPN/SSHサーバーとAPの間に有線ケーブルを使用する必要があります。これにより、暗号化されていないデータが空中に送信されることはありません。
その答えはWIFIルーターの「ステートレス」に関係しているのではないかと思います。着信パケットと発信パケットは均一に扱われます。ある種の暗号化が接続ごとにネゴシエートされた場合、ルーターは各通信パートナーの状態を維持する必要があります。これは「レイヤー」モデルを壊します。パケットは均一に扱われ、上位層は暗号化や継続性などを扱います。