为什么开放式 WiFi 不加密?

信息安全 加密 密码 验证 无线上网
2021-08-11 08:43:33

据我了解,不需要密码的 WiFi 网络通过未加密的空气发送流量。那些需要密码的人会唯一地加密每个连接,即使他们都使用相同的密码。

如果这是真的,我不明白为什么。要求访问密码和加密连接似乎是完全不同的问题。

他们真的是这样联系在一起的吗?如果是这样,我没有看到有什么原因吗?是否可以将某些路由器配置为允许无需密码的公共访问,同时加密用户连接以防止 Firesheep 式攻击?

更新

一些答案已经说过或暗示密码是启用加密的必要“共享机密”。但这不是必需的。这个问题在 1976 年被公开解决。

Diffie-Hellman 密钥交换方法允许事先不知道对方的两方在不安全的通信通道上共同建立共享密钥。http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

4个回答

这个问题(对大多数人来说)是矛盾的。根据定义,人们会认为“开放 WiFi”意味着“未加密的 WiFi。对我来说,您似乎在问“为什么早在 1997 年编写802.11标准的人会做出他们所做的决定?”

简短的回答——我们只能通过询问他们(或查看互联网上是否有任何讨论文件)来找出答案。

但是,我们可以讨论问题的 Firesheep 部分。“Firesheep”攻击是一种特定类型的攻击,攻击者复制了对站点用户进行身份验证的 cookie。

唯一的要求是攻击者可以获取 cookie - 因此如果攻击者拥有密钥,则使用带有单个预共享密钥的 WEP、WPA 或 WPA2 的 WiFi 网络很容易受到攻击。当然,许多小型企业使用单个密钥提供 WiFi 访问。

拥有“更好”的接入点是解决此问题的一种昂贵的方法,并且仍然会使用户容易受到上述攻击场景的影响(攻击者可以使用ARP 中毒以及针对仅 HTTP 站点的中间人攻击) .

因此,就解决方案而言,最好和最有用的是 HTTPS 的广泛实施(由 Firesheep 的创建者 Eric Butler推荐)

Firesheep 与 WiFi 加密无关。如果你和我都在加密的 WiFi 连接上,我仍然可以 Firesheep 你的数据。

Firesheep 所做的事情发生在路由器级别。它不会拦截空气中的波浪(嗯,不完全是)

基本上,它运行ARP 欺骗攻击。这种攻击也可以在 LAN 网络上运行;它涉及向路由器提供有关与给定IP相对应的MAC地址的谎言。当路由器希望将数据包分发到给定 IP 时,它需要找出谁拥有该 IP。如果它的缓存中没有这些数据,它会广播一条消息,询问这些详细信息。子网中的任何人都可以回复广播并说 IP 是他们的,即使不是。使用它,攻击者可以在通信通道中直接将自己置于路由器和受害者之间。

需要明确的是:这是 TCP/IP(驱动网络的协议)的问题。不带 WiFi。

其他答案已经解释了 Firesheep 式攻击(基本上是通过ARP 欺骗的MitM)与 WiFi 本身无关。这是一个链路层问题。

至于为什么开放的 WiFi 网络没有加密。好吧,他们只是没有。我真的不知道他们为什么决定不这样做,我只能推测。一个非常明显的原因是中间人攻击,因为任何人都可以冒充接入点 (AP) 并与受害者协商加密连接。如果 AP 所有者为其接入点获取可信证书,这会导致我们遇到PKI问题。但这违背了开放 Wifi 网络的全部目的,因为您必须验证 AP 的身份。

我们怎么知道“JFK Airport AP”真的是JFK机场的接入点?我们应该为称为“JFK AP”的接入点颁发证书吗?这会导致社会工程攻击吗?我是否必须创建自己的证书,然后让我的朋友在连接到我的网络时信任他们?现在,当然,有人可能会争辩说我们可以使用“首次使用时信任”模型,但这不适用于公园、机场或街道上的 WiFi 网络。

有一些建议可以解决这个问题,比如俄亥俄州立大学的学生提出的建议,他们称之为 Dummy Authentication

我们的解决方案利用现有的对称密钥加密算法,例如 TKIP 和 AES,已经在 WPA 和 802.11i 产品中使用,以保护无线帧免受欺骗和窃听。为了使用现有的加密算法,显然需要加密密钥。在本节中,我们首先提出一种新的虚拟认证密钥建立算法。然后我们使用已建立的会话密钥来保护无线帧。

我真的很喜欢。如果您稍微考虑一下,您会发现它可以通过使用 CA 颁发的证书来解决嗅探问题和AP 模拟问题(如 ARP 欺骗)。

我们假设每个 AP 都有一个公私密钥对,表示为pksk,例如 RSA 密钥。公钥包含在 CA 签名证书或自签名证书中。

当然,这需要升级所有现有的 WiFi 接入点并修补操作系统。不是一件容易的事。

您说得对,它们不是同一个问题:密码身份验证和对称加密是完全独立的概念,可以相互独立地实现。但是,密码是生成操作加密所需的密钥的几种方法之一。

您的计算机和 AP 之间的加密连接是使用对称加密实现的。为了使对称加密起作用,双方(计算机和 AP)都必须共享一个密钥(少量机密数据),用于加密流并随后对其进行解密。

这样做的一种常见方法是使用预共享密钥 (PSK),其中双方在尝试建立连接之前都知道密钥。这就是您在设置 Wi-Fi 密码时所做的事情:当您在路由器上输入密码时,然后在计算机上再次输入密码时,它们现在都拥有此信息。密钥的共享不是通过可能被窃听的网络进行,而是通过键盘手动进行,这通常更安全。

(从技术上讲,关键不是密码本身,而是从中派生的一些数据。)

加密需要密钥。这就是为什么要求您输入密码,以及为什么没有密码您无法获得加密的原因。除了密码短语之外,还有其他方法可以生成密钥,但您不会在 AP 上找到它们。

考虑这种情况:如果没有密码,AP 可能会生成密钥(例如使用强 PRNG)。密钥需要以某种方式传递给计算机。直接的方法是通过无线连接本身(假设 AP 没有其他方法可以将数据发送到计算机)。收到此信息后,可以对连接上的剩余流量进行加密。

问题是在发送密钥时连接没有加密(如果是,接收方将无法读取密钥)。窃听者可以轻松检索未加密的密钥并监控会话的其余部分,就好像它没有加密一样。

理论家会说,既然这是可能的,那么你的连接已经和未加密的一样好,你最好不要浪费 CPU 周期来加扰它。我说,除非攻击者在连接开始时就在附近,否则这种攻击不会有效,但您不能安全地假设情况并非如此(所有时间)。

有一些方法可以使用非对称(基于公钥)加密和身份验证来解决这个特定问题,其中通过一些数学魔法,您可以加密除接收者(甚至您!)之外的任何人都无法解密的数据,但它可以是设置起来很复杂,而且,截至我上次购买的时候,它不太可能是您的 AP 的内置功能。

更新:Diffie-Hellman

即使使用 Diffie-Hellman 密钥交换,仍然存在信任问题。

以下是原因的简要说明:

  • 如果没有事先在各方之间建立信任,认证是没有意义的。
  • 如果没有有意义的身份验证,DH 就没有意义。(它容易受到中间人攻击。)
  • 没有有意义的 DH,基于 DH 交换的加密就没有意义。
  • 没有有意义加密的通信(大致)等同于没有任何加密的通信。
  • 因此,除非首先建立信任,否则基于 DH 的默认加密方案并不比不加密更安全。
  • 如果没有第三方的信任机制(例如 PKI 或信任网络),建立信任需要直接交换信息(亲自、通过电话等,具体取决于偏执程度)。
  • 任何用于直接交换的有用机制都可以(至少同样容易地)用于共享 PSK。

建立信任是陌生人之间没有直接交换很难解决的问题,而这样的直接交换已经足以共享一个 PSK。

理论上,避免直接交换的一种方法是从公共 CA 为您的 AP 购买 SSL 证书。这可能会有点贵,而且我认为 AP 所有者不太可能支付额外费用来为陌生人提供安全的 Wi-Fi。可以使用自签名证书代替,但这将要求客人要么盲目信任自签名,这使其对 MITM 开放,要么在检查其签名与原始证书后获取并安装证书——这将一次再次需要直接交换。