译者：飞龙
协议：CC BY-NC-SA 4.0
Kerberos
**留意：**这些讲座条记略有修改自 2014 年 6.858 课程网站上发布的条记。
Kerberos 设置
- 分布式架构，从单一的分时系统演变而来。
- 许多提供服务的服务器：远程登录、邮件、打印、文件服务器。
- 许多工作站，一些是公共的，一些是私有的。
- 每个用户登录到自己的工作站，拥有根访问权限。
- 对手可能也有自己的工作站。
- 当时的更换方案：rlogin、rsh。
- 目标：允许用户通过向服务器进行身份验证来访问服务。
- 其他用户信息通过 Hesiod、LDAP 或其他目录分发。
- 广泛使用：Microsoft Active Directory 使用 Kerberos（v5）协议。
信任模型是什么？
- 全部用户、客户端、服务器都信任 Kerberos 服务器。
- 其他呆板之间没有先验信任。
- 网络是不受信任的。
- 用户信任本地呆板。
Kerberos 架构
- 中央 Kerberos 服务器，被全部各方信任（或至少在 MIT 被全部方信任）。
- 用户、服务器之间有一个他们与 Kerberos 共享的私钥。
- Kerberos 服务器跟踪每个人的私钥。
- Kerberos 使用密钥实现客户端、服务器之间的相互身份验证。
- 术语：用户、客户端、服务器。
- 客户端和服务器知道相互的名称。
- 客户端确信自己正在与服务器通信，反之亦然。
- Kerberos 不提供授权（用户可否访问某些资源）。
为什么我们需要这个可信的 Kerberos 服务器？
总体架构图
- +-----------------------+
- c, tgs | |
- [ User: Kc ] <--------> [ Kerberos ] |
- ^ \ | Database: |
- | \ | c: Kc |
- V \ s | s: Ks |
- [ Server: Ks ] \--------> [ TGS ] |
- | KDC |
- +-----------------------+
从论文中得到的根本 Kerberos 构造：
- 票证，T_{c,s} = { s, c, addr, timestamp, life, K_{c,s} }
- 验证器，A_c = { c, addr, timestamp }
Kerberos 协议机制：
- 对 Kerberos 数据库有两个接口：“Kerberos”和“TGS”协议。
- 相当相似；少许差别：
- 在 Kerberos 协议中，可以指定任何c、s；客户端必须知道K_c。
- 在 TGS 协议中，客户端的名称是隐式的（来自票证）。
- 客户端只需知道K_{c,tgs}来解密相应（而不是K_c）。
- 客户端呆板最初从哪里获取K_c？
- 为什么我们需要这两个协议？为什么不只使用“Kerberos”协议？
- 客户端呆板在获得 TGS 票证后可以忘记用户密码。
- 我们可以只存储K_c并忘记用户密码吗？等效于密码。
命名
- Kerberos 的关键之处：密钥与主体名称之间的映射。
- 每个主体名称由(名称、实例、范畴)组成
- 哪些实体有主体？
- 用户：名称是用户名，实例用于特殊权限（按照惯例）。
- 服务器：名称是服务名称，实例是服务器的主机名。
- TGS：名称是’krbtgt’，实例是范畴名称。
- 这些名称在哪里使用/名称在哪里紧张？
- 用户记着他们的用户名。
- 服务器根据主体名称执行访问控制。
- 客户端选择他们期望与之交流的主体。
- 何时可以重复使用名称？
- 对于用户名：确保没有 ACL 包含该名称，很困难。
- 对于服务器（假设不在任何 ACL 上）：确保用户忘记服务器名称。
- 必须更改密钥，以确保旧票据对新服务器无效。
获取初始票据：“Kerberos” 协议
- 客户端发送一对主体名称 (c, s)，其中 s 通常是 tgs。
- 服务器复兴 { K_{c,s}, { T_{c,s} }_{K_s} }_{K_c}
- Kerberos 服务器怎样验证客户端？
- 客户端怎样验证 Kerberos 服务器？
- 解密相应并检查票据是否有效。
- 只有 Kerberos 服务器会知道 K_c。
- 这种方式与将密码发送到服务器相比有何优劣之处？
- 为什么从 Kerberos/TGS 服务器的相应中两次包含密钥？
- 相应中的 K_{c,s} 给予客户端访问这个共享密钥的权限。
- 票据中的 K_{c,s} 应该让服务器确信密钥是合法的。
一般缺点： Kerberos 4 假设加密提供消息完备性。
- 有一些攻击可以让对手篡改密文。
- 没有明确的 MAC 意味着没有明确定义的方法来检测篡改。
- 一次性解决方案：kprop 协议包括校验和，难以匹配。
- 缺点使得对手相对容易“伪造”票据。
- 参考：http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2003-004-krb4.txt
一般缺点： 对手可以发动离线推测密码攻击。
- 典型密码的熵不高。
- 任何人都可以向 KDC 请求使用用户密码加密的票据。
- 然后尝试离线暴力破解用户密码：易于并行化。
- 更好的计划：要求客户端与服务器互动以进行每次登录尝试。
一般缺点： DES 硬编码到计划中，数据包格式。
- 当 DES 变得太弱时，难以切换到另一个加密系统。
- DES 密钥空间太小：密钥仅为 56 位，2⁵⁶ 并不算大。
- 现在破解 DES 很自制（$20–$200 通过 https://www.cloudcracker.com/）。
- 对手怎样利用这个缺点破解 Kerberos？
向服务器进行身份验证：“TGS” 协议
- 客户端发送 ( s, {T_{c,tgs}}_{K_tgs}, {A_c}_{K_{c,tgs}} )
- 服务器复兴 { K_{c,s}, { T_{c,s} }_{K_s} }_{K_{c,tgs}}
- 服务器怎样根据票据对客户端进行身份验证？
- 使用服务器的密钥解密票据。
- 使用 K_{c,s} 解密验证器。
- 只有 Kerberos 服务器可以天生票据（知道 K_s）。
- 只有客户端可以天生验证器（知道 K_{c,s}）。
- 为什么票据中包含 c？s？addr？life？
- 服务器可以从票据中提取客户端的主体名称。
- Addr 试图防止被盗票据在另一台呆板上被使用。
- 生命周期同样试图限定被盗票据的损害。
- 网络协议怎样使用 Kerberos？
- 使用K_{c,s}加密/认证全部消息。
- 邮件服务器命令、发送到打印机的文档、shell I/O 等。
- 比方，在邮件服务器协议中的“DELETE 5”。
- 谁天生认证器？
- 为什么客户端需要发送认证器，除了票据之外？
- 向服务器证明对手没有重放旧消息。
- 服务器必须在内存中保留近来的几个认证器，以检测重放。
- Kerberos 怎样使用时间？假如时钟错误会发生什么？
- 防止被盗票据永世使用。
- 限定重放缓存的巨细。
- 假如时钟错误，对手可以使用旧票据或重放消息。
- 客户端怎样认证服务器？为什么这很紧张？
- 连接到文件服务器：想知道您获取的是合法文件。
- 解决方案：服务器在接收到客户端的票据和认证器后可以发送{ timestamp + 1 }_{K_{c,s}}。
**一般缺点：**相同的密钥K_{c,s}用于许多事情
- 对手可以用K_{c,s}更换任何消息为其他消息。
- 比方：跨多个会话的消息。
- 认证器不证明K_{c,s}是新鲜的！
- 对手可以将新的认证器与旧消息拼接在一起。
- Kerberos v5 每次都使用新的会话密钥，在认证器中发送。
- 比方：差别方向的消息
- Kerberos v4 在数据包中包含了一个方向标志(c->s 或 s->c)
- Kerberos v5 使用单独的密钥：K_{c->s}, K_{s->c}
假如用户连接到错误的服务器（MITM /网络钓鱼攻击的类比）会发生什么？
- 假如服务器拦截数据包，相识用户连接到哪个服务。
- 假如用户意外输入 ssh malicious.server 会发生什么？
- 服务器相识用户的主体名称。
- 服务器没有获取用户的 TGS 票据或K_c。
- 无法冒充用户给其他人。
假如 KDC 宕机会发生什么？
- 无法登录。
- 无法获取新票据。
- 可以继承使用现有的票据。
认证到 Unix 系统。
- 访问本地文件、进程时不涉及 Kerberos 协议。
- 假如使用 Kerberos 登录，用户必须呈现合法的票据。
- 假如用户使用用户名/密码（本地或通过 SSH 使用密码）登录会发生什么？
- 用户知道自己提供的密码是否合法。
- 服务器毫无所知。
- 服务器可能受到攻击：
- 用户通过 SSH 连接，输入用户名和密码。
- 创建看起来合法的 Kerberos 相应，使用密码加密。
- 服务器无法判断此相应是否真正合法。
- 解决方案（假如服务器保持状态）：服务器需要自己的主体、密钥。
- 起首获取用户的 TGS，使用用户的用户名和密码。
- 然后使用 TGS 获取服务器主体的票据。
- 假如用户伪造了 Kerberos 服务器，第二个票据将不匹配。
在应用步伐中使用 Kerberos。
- 论文建议使用特殊函数封装消息，有 3 个安全级别。
- 对应用步伐需要适度更改。
- 对于灵活性、性能很好。
- 倒霉于接纳。
- 开发职员很难理解微妙的安全包管。
- 或许更好的抽象：安全通道（SSL/TLS）。
更改密码服务（管理界面）
- Kerberos 协议怎样确保客户端知道密码？为什么？
- 票证中的特殊标志指示使用哪个接口获取它。
- 更改密码服务仅担当使用K_c获得的票证。
- 确保客户端知道旧密码，不但仅是拥有票证。
- 客户端怎样更改用户的密码？
复制
- 一个主服务器（支持密码更改），零个或多个从服务器。
- 全部服务器都可以发出票证，只有主服务器可以更改密钥。
- 为什么要这样分割？
- 主服务器定期更新从服务器（在撰写本文时，约莫每小时一次）。
- 更近期的实现具有增量传播：较低的延迟（但不是 0）。
- 这个有多可扩展？
- 对称加密（DES，AES）很快–在当前硬件上为 O（100MB / sec）。
- 票证很小，O（100 字节），因此可以支持每秒 1M 张票证。
- 通过添加从服务器轻松扩展。
- 潜伏问题：密码更改需要一段时间才能传播。
- 对手在用户更改密码后仍然可以一段时间使用盗取的密码。
- 要相识怎样精确进行复制，请参加 6.824。
Kerberos 数据库的安全性
- 主服务器和从服务器在这种计划中非常敏感。
- 受损的主/从服务器意味着全部密码/密钥都必须更改。
- 必须物理安全，Kerberos 服务器软件中没有错误，在服务器呆板上的任何其他网络服务中也没有错误等。
- 我们能做得更好吗？SSL CA 基础设施略好一些，但并不多。
- 当我们评论浏览器安全/HTTPS 时，将更详细地研究它。
- 大多数集中式身份验证系统都遭受这些问题。…并且环球唯一的自由形式名称需要一些受信任的映射机构。
为什么 Kerberos 没有使用公钥加密？
- 当时太慢了：VAX 系统，10MHz 时钟。
- 政府出口限定。
- 专利。
网络攻击。
- Kerberos 服务器上的离线密码推测攻击。
- Kerberos v5 防止客户端请求任何主体的票证。
- 必须在请求中包含{ timestamp }_{K_c}，证明知道 K_c。
- 当时仍然容易受到网络嗅探器的密码推测攻击。
- 有更好的更换方案：SRP，PAKE。
- 对手可以使用盗取的票证做什么？
- 对手可以使用盗取的K_c做什么？
- 对手可以使用盗取的K_s做什么？
- 记着：在 Kerberos 中，两方共享每个密钥（并依赖于它）！
- 假如K_c被泄露后密码更改后会发生什么？
- 可以解密全部后续互换，从初始票证开始
- 乃至可以解密密码更改请求，获取新密码！
- 假如对手稍后弄清您的旧密码怎么办？
- 假如对手保存了旧数据包，可以解密全部内容。
- 可以类似地获取当前密码。
前向保密（制止密码更改问题）。
- 抽象问题：在两方之间创建共享秘密。
- Kerberos 方法：某人选择秘密，加密并发送。
- 缺点：假如加密密钥被盗取，可以稍后获取秘密。
- Diffie-Hellman 密钥互换协议：
- 两方选择自己的秘密部分。
- 互发消息。
- 消息不必保密，只需经过身份验证（无篡改）。
- 两方使用相互的消息重建共享密钥。
- 对手无法通过观察网络消息重建密钥。
- Diffie-Hellman 的细节：
- 素数 p，天生器 g mod p。
- Alice 和 Bob 各自选择一个随机的、秘密的指数（a 和 b）。
- Alice 和 Bob 向相互发送（g^a mod p）和（g^b mod p）。
- 每个参与方计算（g^(ab) mod p）=（gab mod p）=（gba mod p）。
- 使用（g^(ab) mod p）作为秘密密钥。
- 假设离散对数（从（g^a mod p）中恢复 a）很困难。
Kerberos 中的跨域。
- 范畴之间共享密钥。
- Kerberos v4 仅支持成对的跨域（无过境）。
Kerberos 不能解决什么问题？
- 客户端、服务器或 KDC 呆板可能会受到威胁。
- 访问控制或组（由服务实现）。
- 微软“扩展”了 Kerberos 以支持组。
- 署理问题：Kerberos 中仍然没有很好的解决方案，但 ssh-agent 很好。
- 工作站安全性（可以木马登录，并且实际上确实发生过）。
- 基于智能卡的方法并没有起飞。
- 谷歌身份验证器使用的两步验证（基于时间的 OTP）。
- 共享桌面系统并不那么普遍：每个人都有自己的手机、条记本电脑，…
后续步骤。
- Kerberos v5 修复了 v4 中的许多问题（一些被提及），被广泛使用（MS AD）。
- OpenID 是一个类似的协议，用于 Web 应用步伐的身份验证。
SSL/TLS 和 HTTPS
**留意：**这些讲座条记略有修改自 2014 年 6.858 课程网站上发布的条记。
这节课涉及两个相关主题：
- 怎样在比 Kerberos 更大规模上加密掩护网络通信？
- 怎样将网络流量的加密掩护整合到 Web 安全模型中？
对称与非对称加密
**回首：**两种加密方案。
- E是加密，D是解密
- 对称密钥加密意味着相同密钥用于加密和解密
- 密文 = E_k(明文)
- 明文 = D_k(密文)
- 非对称密钥（公钥）加密：加密和解密密钥差别
- 密文 = E_PK(明文)
- 明文 = D_SK(密文)
- PK和SK分别称为公钥和私钥（秘密密钥）
- 公钥加密比对称加密慢几个数量级
- 加密提供数据保密性，但我们通常也盼望完备性。
- *消息认证码（MAC）*使用对称密钥可以提供完备性。
- 可以使用公钥加密进行签名和验证，几乎相反：
- 使用秘密密钥天生签名（计算D_SK）
- 使用公钥检查签名（计算E_PK）
Kerberos
- 中央 KDC 知道全部主体及其密钥。
- 当A想要与B交流时，A要求 KDC 发放一张票。
- 票据包含一个由 KDC 天生的A与B通话的会话密钥。
为什么 Kerberos 不敷？
- 比方，为什么 Web 不基于 Kerberos？
- 可能没有一个单一的 KDC 被信任天生会话密钥。
- 不是每个人都可能在这个单一 KDC 上有帐户。
- 假如用户每次访问网站都联系 KDC，KDC 可能无法扩展。
- 不幸的是，KDC 知道每个用户连接到哪个服务。
*备选方案：*使用公钥加密
- 假设A知道B的公钥。
- 不想一直使用公钥加密（速度慢）。
- 用于在A和B之间创建安全连接的草案协议：
- A天生一个随机对称会话密钥S。
- A为PK_B加密S，发送给B。
- 现在我们有A和B之间共享的秘密密钥S，可以加密和
- 使用对称加密验证消息，类似于 Kerberos。
这个草案协议的好处：
- A的数据只被B看到。
- 只有B（具有SK_B）才能解密S。
- 只有B才能解密使用S加密的数据。
- 不需要类似 KDC 的中央机构来分发会话密钥。
这个草案有什么问题？
- 对手可以记录并稍后重放A的流量；B不会留意到。
- 解决方案：让B发送一个随机值（nonce）。
- 将 nonce 合并到最终主密钥S' = f(S, nonce)中。
- 通常，S被称为预主密钥，S'被称为主密钥。
- 创建S'的过程称为“握手”。
- 对手可以冒充A，发送另一个对B的对称密钥。
- 假如B在乎A是谁，有许多可能的解决方案。
- 比方，B还选择并使用PK_A加密的对A发送对称密钥。
- 然后A和B都使用两个密钥组合的哈希。
- 这大抵是 TLS 客户端证书的工作原理。
- 对手稍后可以获取SK_B，解密对称密钥和全部消息。
- 解决方案：使用类似 Diffie-Hellman 的密钥互换协议，
- 提供前向保密，如前次讲座中讨论的。
难题： 假如两台计算机都不知道对方的公钥怎么办？
- 常见方法：使用可信第三方天生证书。
- 证书是元组（名称，公钥），由证书颁发机构签名。
- 含义：证书颁发机构声称名称的公钥是公钥。
- B除了发送证书外，还向A发送一个公钥。
- 假如A信任证书颁发机构，继承如上操纵。
为什么证书可能比 Kerberos 更好？
- 客户端每次连接到新服务器时无需与 KDC 通信。
- 服务器可以向客户端呈现证书；客户端可以验证签名。
- KDC 不参与天生会话密钥。
- 可以支持没有长期密钥/证书的“匿名”客户端。
掩护 Web 浏览器的筹划：HTTPS
- 新协议：https 而不是 http（比方，www.paypal.com/）。
- 需要掩护几样东西：
- (A) 数据在网络上传输。
- (B) 用户浏览器中的代码/数据。
- © 用户看到的 UI。
- (A) 怎样确保数据在网络上不被窃听或篡改？
- 使用 TLS（一种使用证书的加密协议）。
- TLS 加密和认证网络流量。
- 协商密码（和其他功能：压缩，扩展）。
- 协商是明文进行的。
- 包括对全部握手消息进行 MAC 认证。
- (B) 怎样掩护用户浏览器中的数据和代码？
- 目标： 将浏览器安全机制与 TLS 提供的内容连接起来。
- 记着浏览器有两个主要的安全机制：
- 同源策略。
- Cookie 策略（略有差别）。
- 与 HTTPS/TLS 的同源策略。
- TLS 证书名称必须与 URL 中的主机名匹配。
- 在我们的示例中，证书名称必须是 www.paypal.com。
- 也允许一级通配符（*.paypal.com）。
- 浏览器信任多个证书颁发机构。
- 来源（来自同源策略）包括协议。
- http://www.paypal.com/ 与 https://www.paypal.com/ 差别。
- 在这里，我们关心数据的完备性（比方 JavaScript 代码）。
- 结果： 非 HTTPS 页面无法篡改 HTTPS 页面。
- 缘故原由： 非 HTTPS 页面可能已被对手修改。
- 使用 HTTPS/TLS 的 Cookie。
- 服务器证书帮助客户端区分服务器。
- Cookie（用户凭证的常见形式）有一个“安全”标志。
- 安全的 Cookie 只能随 HTTPS 请求发送。
- 非安全的 Cookie 可以随 HTTP 和 HTTPS 请求发送。
- 假如对手篡改 DNS 记录会发生什么？
- 好消息：安全性不依赖于 DNS。
- 我们已经假设对手可以篡改网络数据包。
- 错误的服务器将不知道与证书匹配的精确私钥。
- © 最后，用户可以直接输入根据。怎样确保安全？
- 浏览器中的锁图标告诉用户他们正在与 HTTPS 站点交互。
- 浏览器应该向用户指示站点证书中的名称。
- 用户应验证他们打算提供根据的站点名称。
这个筹划怎么会堕落？
- 正如你所料，上述每一步都可能堕落。
- 不是细致的列表，但涉及 ForceHTTPS 想要解决的问题。
1 (A) 密码学
SSL/TLS 的密码部分曾受到一些攻击。
- Rizzo 和 Duong 的攻击可以让对手通过在单个连接上发出许多精心选择的请求来学习一些明文。参考
- 同一人使用压缩进行近来的攻击，在 iSEC 讲座中提到。参考
- 近来，更多的填充预言攻击。参考
- 一些服务器/CA 使用弱加密，比方使用 MD5 的证书。
- 一些客户端选择弱加密（比方，Android 上的 SSL/TLS）。参考
- 但是，密码学很少是系统中最薄弱的部分。
2 (B) 服务器认证
对手可能可以或许为他人的名字获得证书。
- 从前需要在公司仰面纸上传真请求（但怎样检查？）
- 现在通常需要在 root@domain.com 或类似位置接收秘密令牌
- 安全性取决于最不安全证书颁发机构的政策
- 大多数浏览器中有数百个受信任的证书颁发机构
- 2011 年发生了几起 CA 被破坏的变乱（gmail、facebook 等的证书）。参考
- 服务器可能被入侵，相应的私钥被盗。
怎样处理受损的证书（比方，无效证书或被盗私钥）？
- 证书有到期日期。
- 每次请求都要与 CA 检查证书状态很难扩展。
- 一些 CA 发布的证书吊销列表（CRL），但其中的证书相对较少
- 客户端必须定期下载 CRL。
- 假如许多证书被吊销，可能会很慢。
- 假如很少或零个证书被吊销，则不是问题，但并不太有用。
- OCSP：在线证书状态协议。
- 查询证书是否有效。
- 一个问题：OCSP 协议不要求签署“稍后再试”消息。参考
- 用于推测证书是否正常的各种开导式方法。
- CertPatrol，EFF 的 SSL Observatory 等。
- 不像“证书是否更改那么容易”。网站偶然会测试新的 CA。
- 问题：在线吊销检查是软失败。
- 主动网络攻击者可以使检查不可用。
- 浏览器不喜欢在侧通道上壅闭。
- 性能、单点故障、强制门户等问题。[ 参考：https://www.imperialviolet.org/2011/03/18/revocation.html ]
- 实际上，浏览器在重大违规变乱后会推送黑名单更新。[ 参考：https://www.imperialviolet.org/2012/02/05/crlsets.html ]
用户忽略证书不匹配错误。
- 尽管证书很容易获得，但许多网站配置错误。
- 有些人不想处理获得证书的（非零）本钱。
- 其他人忘记更新它们（证书有到期日期）。
- 最闭幕果：浏览器允许用户覆盖不匹配的证书。
- 问题在于：人现在成为决定证书是否有效的过程的一部分。
- 开发职员很难确切知道浏览器将担当哪些证书。
- 根据经验，Chrome 体现的约 60% 的绕过按钮被点击通过。（尽管这些数据可能已经过时…）
用户担当无效证书的风险是什么？
- 可能是良性的（过期证书，服务器操纵员忘记续订）。
- 可能是中心人攻击，连接到对手的服务器。
- 为什么这是欠好的？
- 用户的浏览器将用户的 cookie 发送给对手。
- 用户可能会将敏感数据输入对手的网站。
- 用户可能会以为页面上的数据来自精确的网站。
3 (B) 混合 HTTP 和 HTTPS 内容
- 网页的来源由页面本身的 URL 确定。
- 页面可以有许多嵌入元素：
- Javascript 通过 <SCRIPT> 标签
- CSS 样式表通过 <STYLE> 标签
- Flash 代码通过 <EMBED> 标签
- 图像通过 <IMG> 标签
- 假如对手可以或许篡改这些元素，可能控制页面。
- 特别是，Javascript 和 Flash 代码可以控制页面。
- CSS：控制较少，但仍然可滥用，尤其是使用复杂的属性选择器。
- 开发职员可能不会包含来自攻击者网站的 Javascript。
- 但是，假如 URL 不是 HTTPS，对手可以篡改 HTTP 相应。
- 另一种方法：明确验证嵌入元素。
- 比方，可以包含正在加载的 Javascript 代码的哈希值。
- 可能会在不久的将来在浏览器中部署。参考
4 (B) 掩护 cookie
- Web 应用步伐开发职员可能会犯错误，忘记了 Secure 标志。
- 用户访问 http://bank.com/ 而不是 https://bank.com/，泄漏 cookie。
- 假设用户只访问 https://bank.com/。
- 为什么这仍然是一个问题？
- 对手可以导致另一个 HTTP 网站重定向到 http://bank.com/。
- 即使用户从未访问任何 HTTP 网站，应用步伐代码可能存在错误。
- 一些网站通过 HTTPS 提供登录表单，并通过 HTTP 提供其他内容。
- 在同时使用 HTTP 和 HTTPS 时要警惕。
- 比方，Google 的登录服务在请求时创建新的 cookie。
- 登录服务有自己的（安全的）cookie。
- 可以通过加载登录的 HTTPS URL 请求登录到 Google 网站。
- 从前还可以通过不安全的 cookie 登录。
- ForceHTTPS 通过将 HTTP URL 重定向到 HTTPS 来解决问题。参考
- cookie 完备性问题。
- 在 http://bank.com 上设置的非 Secure cookie 仍然发送到 https://bank.com。
- 无法确定是谁设置了 cookie。
5（C） 用户直接输入根据
- 钓鱼攻击。
- 用户不检查锁图标。
- 用户不仔细检查域名，不知道要查找什么。
- 比方，拼写错误的域名（paypa1.com），unicode
- Web 开发职员将登录表单放在 HTTP 页面上（目标登录脚本是 HTTPS）。
- 对手可以修改登录表单以指向另一个 URL。
- 登录表单没有受到篡改的掩护，用户无法辨别。
ForceHTTPS
ForceHTTPS（本文）怎样解决这些问题？
- 服务器可以在用户的浏览器中为自己的主机名设置标志。
- 将 SSL/TLS 证书配置错误酿成致命错误。
- 将 HTTP 请求重定向到 HTTPS。
- 禁止非 HTTPS 嵌入（+ 为它们执行 ForceHTTPS）。
ForceHTTPS 解决了哪些问题？
- 主要是 2、3，某种水平上是 4（见上面的列表）
- 用户担当无效证书。
- 开发职员错误：嵌入不安全的内容。
- 开发职员错误：忘记将 cookie 标记为 Secure。
- 对手通过 HTTP 注入 cookie。
这真的有必要吗？我们只能使用 HTTPS，设置 Secure cookie 等吗？
- 用户仍然可以点击错误，因此对于＃2 仍然有帮助。
- 对于＃3 来说并不是必要的，假设 Web 开发职员永世不会犯错误。
- 对于＃4 仍然有帮助。
- 将 cookie 标记为 Secure 可以确保保密性，但不能包管完备性。
- 主动攻击者可以在 http://bank.com 上提供卖弄设置，并设置 cookie。
- 用于 https://bank.com。 （https://bank.com 无法区分）
为什么不为全部人打开 ForceHTTPS？
- HTTPS 站点可能不存在。
- 假如是这样，可能不是同一个站点（https://web.mit.edu 是
- 认证，但 http://web.mit.edu 不是）。
- HTTPS 页面可能期望用户点击通过（自签名证书）。
实验 ForceHTTPS
- ForceHTTPS 位存储在 cookie 中。
- 有趣的问题：
- 状态耗尽（ForceHTTPS cookie 被驱逐）。
- 拒绝服务（强制整个域；通过 JS 强制；通过 HTTP 强制）。
- 为什么 ForceHTTPS 只允许特定主机，而不是整个域？
- 为什么 ForceHTTPS 要求通过标头设置 cookie，而不是通过 JS？
- 为什么 ForceHTTPS 要求通过 HTTPS 设置 cookie，而不是 HTTP？
- 引导（怎样获取 ForceHTTPS 位；怎样制止隐私泄漏）。
- 可能的解决方案 1：DNSSEC。
- 可能的解决方案 2：在 URL 名称中嵌入 ForceHTTPS 位（假如可能）。
- 假如有一种方法可以从服务器全部者那里获取一些经过身份验证的位（DNSSEC、URL 名称等），我们是否应该直接获取公钥？
- 困难：用户网络不可靠。浏览器不愿意在侧通道请求上阻止握手。
ForceHTTPS 的当前状态
- 一些 ForceHTTPS 的想法已被采纳为标准。
- HTTP Strict-Transport-Security 头部类似于 ForceHTTPS cookie。参考：RFC6797，参考：HTTP Strict Transport Security
- 使用标题而不是魔术 Cookie：
- Strict-Transport-Security：max-age=7884000；includeSubDomains
- 将 HTTP 链接转换为 HTTPS 链接。
- 禁止用户覆盖 SSL/TLS 错误（比方，错误的证书）。
- 可选择应用于全部子域。
- 这有什么用？非安全和伪造的 cookie 可能会泄漏或设置在子域上。
- 可选择为用户提供手动启用的界面。
- 在 Chrome、Firefox 和 Opera 中实验。
- 引导步伐在很大水平上尚未解决。
- Chrome 有一个硬编码的预加载列表。
- IE9，Firefox 23 和 Chrome 现在默认阻止混合脚本。
- 参考：竣事混合脚本漏洞，
- 参考：Firefox 中启用混合内容阻止，
- 参考：掩护消耗者免受恶意混合内容
在这个范畴的另一个近来的实验：HTTPS-Everywhere。
- 专注于 ForceHTTPS 的“高级用户”方面。
- 允许用户强制某些域名使用 HTTPS。
- Tor 和 EFF 之间的合作。
- 适用于 Firefox 和 Chrome 的附加组件。
- 附带用于重写流行网站 URL 的规则。
SSL/TLS 中解决问题的其他方法
- 更好的工具/更好的开发职员以制止编程错误。
- 将全部敏感 cookie 标记为 Secure（#4）。
- 制止任何不安全的嵌入（#3）。
- 不幸的是，似乎容易堕落。
- 不帮助最终用户（需要开发者参与）。
- EV 证书。
- 尝试解决问题 5：用户不知道在证书中寻找什么。
- 除了 URL，还嵌入公司名称（比方，“PayPal, Inc.”）
- 通常体现为 URL 栏旁边的绿色框。
- 为什么这样更安全？
- 什么情况下实际上会提高安全性？
- 假如用户开始期望 EV 证书，可能间接有助于解决问题 2。
- 黑名单弱加密。
- 浏览器开始拒绝证书上的 MD5 签名（iOS 5，Chrome 18，Firefox 16）
- 以及 Chrome 18、OS X 10.7.4、Windows XP+近来更新后的 RSA 密钥< 1024位。
- 乃至被 Chrome 淘汰的 SHA-1。参考：渐渐淘汰 SHA1
- OCSP 装订。
- OCSP 相应由 CA 签名。
- 服务器在握手中发送 OCSP 相应，而不是在线查询（#2）。
- 实际上是一个短暂的证书。
- 问题：
- 密钥固定。
- 仅担当由每个站点白名单的 CA 签名的证书。
- 消除对最不安全 CA 的依赖（#2）。
- 目前在 Chrome 中有一个硬编码的站点列表。
- 2011 年 Diginotar 妥协是因为密钥固定。
- 筹划添加站点广告固定的机制。
- 参考：IETF 关于 websec 关键固定的草案
- 参考：tack.io
- 与 ForceHTTPS 中的引导困难相同。
其他参考资料
- www.imperialviolet.org/2012/07/19/hope9talk.html
RSA 的侧信道攻击
留意： 这些讲义略有修改自 6.858 课程网站 上发布的讲义，时间为 2014 年。
侧信道攻击
- 历史上，担心电磁信号泄露。NSA TEMPEST。
- 广泛地，系统可能需要担心许多意外的方式
- 信息可能会被泄露。
示例设置： 服务器（比方，Apache）有一个 RSA 私钥。
- 服务器使用 RSA 私钥（比方，解密来自客户端的消息）。
- 服务器的计算信息泄露给客户端。
已经研究了许多信息泄漏：
- 解密需要多长时间。
- 解密怎样影响共享资源（缓存、TLB、分支预测器）。
- CPU 本身的辐射（射频、音频、功耗等）。
侧信道攻击不肯定与加密相关。
- 比方，操纵时间与密码中哪个字符不精确有关。
- 或时间与你和某个用户在 Facebook 上有多少共同好友有关。
- 或加载页面在浏览器中需要多长时间（取决于是否被缓存）。
- 或基于点阵打印机的声音恢复打印文本。参考
- 但对密码或密钥的攻击通常是最具破坏性的。
对手可以分析信息泄漏，用它来重建私钥。
- 目前，本文形貌的系统上的侧信道攻击是罕见的。
- 比方，Apache web 服务器运行在某个连接到互联网的呆板上。
- 通常存在其他一些漏洞，更容易利用。
- 慢慢地成为一个更大的关注点：新的侧信道（虚拟机）、更好的攻击。
- 侧信道攻击更常用于攻击受信任/嵌入式硬件。
- 比方，芯片在智能卡上运行加密操纵。
- 通常这些具有较小的攻击面，没有太多其他方式可以进入。
- 如论文所述，一些密码协处理器计划用于制止此类攻击。
“远程时间攻击是实际的” 论文的贡献是什么？参考
- 时间攻击已知已久。
- 本文：可能通过网络攻击标准的 Apache web 服务器。
- 使用了许多关于时间攻击的先前工作的观察/技能。
- 要理解这是怎样工作的，起首让我们看一些 RSA 的内部…
RSA：高级筹划
- 选择两个随机素数，p 和 q。
- 今天一个公道的密钥长度，即 |n| 或 |d|，是 2048 位。
- 欧拉函数 phi(n)：与 n 互质的 Z_n^* 元素的数量。
- 定理 [此处无证明]：a^(phi(n)) = 1 mod n，对全部的 a 和 n。
- 那么，怎样加密和解密？
- 选择两个指数 d 和 e，使得 m^(e*d) = m (mod n)，这
- 加密将是 c = m^e (mod n)；解密将是 m = c^d (mod n)。
- 怎样获得这样的 e 和 d？
- 对于 n=pq，phi(n) = (p-1)(q-1)。
- 假如我们知道phi(n)，很容易计算d=1/e。扩展欧几里得算法
- 在实践中，选择小的e（比方，65537），使加密更快。
- 公钥是(n, e)。
- 私钥原则上是(n, d)。
- 留意：p和q必须保密！
- 否则，对手可以像我们上面做的那样从e计算d。
- 知道p和q对快速解密也很有帮助。
- 因此，在实践中，私钥也包括(p, q)。
RSA 在“安全”使用上有些棘手–假如直接使用 RSA，请警惕！
- 密文是可乘的。
- E(a)*E(b) = a^e * b^e = (ab)^e。
- 可以让对手利用加密，天生新的加密。
- RSA 是确定性的。
- 加密相同的明文每次都会天生相同的密文。
- 对手可以知道何时重新加密相同的内容。
- 通常通过在加密前对消息进行“填充”来解决。OAEP
- 取明文消息位，加上明文前后的填充位。
- 加密组合位（总位数必须小于|n|位）。
- 填充包括随机性，以及固定位模式。
- 有助于检测篡改（比方，密文乘法）。
怎样实现 RSA？
- **关键问题：**快速模指数运算。
- 两个 1024 位数相乘很慢。
- 计算 1024 位数的模很慢（1024 位除法）。
优化 1：赛里斯剩余定理（CRT）。
- 回想一下 CRT 的原理：
- 假如x==a1 (mod p)和x==a2 (mod q)，其中p和q是互质的，
- 那么就有一个唯一解x==a (mod pq)。
- 假设我们想要计算m = c^d (mod pq)。
- 可以计算m1 = c^d (mod p)，以及m2 = c^d (mod q)。
- 然后使用 CRT 从m1、m2计算m = c^d (mod n)；这是唯一且快速的。
- 计算m1（或m2）比直接计算m快约 4 倍（~二次）。
- 使用 CRT 从m1和m2计算m的速度与忽略不计。
- 因此，约莫加速 2 倍。
优化 2：重复平方和滑动窗口。
- 计算c^d的朴素方法：将c乘以自身，d次。
- 更好的方法，称为重复平方：
- c^(2x) = (c^x)²
- c^(2x+1) = (c^x)² * c
- 要计算c^d，起首计算c^(floor(d/2))，然后使用上述方法计算c^d。
- 递归应用，直到计算到c⁰ = 1。
- 平方次数：|d|（表示d所需的位数）。
- 乘法次数：d中的 1 位数。
- 更好的方法（偶然），称为滑动窗口：
- c^(2x) = (c^x)²
- c^(32x+1) = (c^x)³² * c
- c^(32x+3) = (c^x)³² * c³
- …
- c^(32x+z) = (c^x)³² * c^z，通常情况下（其中z<=31）。
- 可以预先计算全部必要的c^z幂的表，存储在内存中。
- 选择 2 的幂常数（比方，32）取决于使用情况。
- 留意：仅预先计算c的奇数次幂（对于偶数使用第一条规则）。
- OpenSSL 使用 32（具有 16 个预先计算的条目标表）。
优化 3：蒙哥马利表示。
- 每次（平方或乘法后）都进行mod p减少是昂贵的。
- 典型实现：进行长除法，找到余数。
- 难以制止减少：否则，值会呈指数增长。
- 理念（由彼得·蒙哥马利提出）：在另一种表示中进行计算。
- 将基数（比方c）提前转换为差别的表示。
- 在这种表示中执行模运算（会更自制）。
- 完成后将数字移回原始表示。
- 抱负情况下，减少的节流应超过移位的本钱。
- 蒙哥马利表示：将全部内容乘以某个因子 R。
- a mod q <-> aR mod q
- b mod q <-> bR mod q
- c = a*b mod q <-> cR mod q = (aR * bR)/R mod q
- 每个在蒙哥马利空间中的乘法（或平方）需要除以R。
- 蒙哥马利表示中模乘法为何更自制？
- 选择R使得除以R更容易：R = 2^|q|（1024 位密钥为2⁵¹²）。
- 因为我们除以R，通常不需要进行mod q。
- |aR| = |q|
- |bR| = |q|
- |aR * bR| = 2|q|
- |aR * bR / R| = |q|
- 怎样自制地除以R？
- 观察： 因为我们关心值mod q，所以q的倍数并不紧张。
- 本领： 向被除以R的数字添加q的倍数，使低位为 0。
- 比方，假设R=2⁴ (10000)，q=7 (111)，将x=26 (11010)除以 R。
- x+2q = (二进制) * 101000
- x+2q+8q = (二进制) 1100000
- 现在，可以轻松地除以R：结果是二进制 110（或 6）。
- 通常，总是可能的：
- q的最低位为 1（q是质数），因此可以"击倒"任何位。
- 要"击倒"比特k，添加2^k * q
- 要击倒低位l，添加q*(l*(-q^-1) mod R)
- 然后，除以R意味着简单地抛弃低零位。
- 一个仍未解决的问题： 结果将会< R，但可能会> q。
- 假如结果恰好大于q，需要减去q。
- 这被称为"额外减少"。
- 计算x^d mod q时，Pr[额外减少] = (x mod q) / 2R。
- 这里，假设x已经处于蒙哥马利形式。
- 直觉： 随着我们乘以更大的数字，将更频繁地溢出。
优化 4：高效乘法。
- 怎样将 512 位数字相乘？
- 表示：将其分解为 32 位值（或任何硬件支持的值）。
- Naive 方法：逐对乘以全部 32 位组件。
- 就像你在纸上逐位相乘数字一样。
- 假如两个数字分别具有n和m个组件，则需要O(nm)时间。
- 假如两个数字接近，则为O(n²)。
- 卡拉兹巴乘法： 假设两个数字具有相同数量的组件。
- O(n^log_3(2)) = O(n¹.585)时间。
- 将两个数字（x和y）分成两个组件（x1，x0和y1，y0）。
- x = x1 * B + x0
- y = y1 * B + y0
- 比方，将 64 位数字分成 32 位组件时，B=2³²。
- Naive: x*y = x1y1 * B² + x0y1 * B + x1y0 * B + x0y0
- 更快：x*y = x1y1 * (B²+B) - (x1-x0)(y1-y0) * B + x0y0 * (B+1)
- … = x1y1 * B² + ( -(x1-x0)(y1-y0) + x1y1 + x0y0 ) * B + x0y0
- 只需三次乘法，以及频频加法。
- 递归应用此算法以继承分割为更多的一半。
- 有意义地更快（没有隐藏的大常数）
- 对于 1024 位密钥，“n” 这里是 16 (512/32)。
- n² = 256
- n¹.585 = 81
- 乘法算法需要决定何时使用 Karatsuba 而不是 Naive。
- 两种情况很紧张：两个大数 和 一个大数 + 一个小数。
- OpenSSL：假如组件数量相等，则使用 Karatsuba，否则使用 Naive。
- 在一些中心情况下，Karatsuba 也可能胜出，但 OpenSSL 忽略了它，
SSL 怎样使用 RSA？
- 服务器的 SSL 证书包含公钥。
- 服务器必须使用私钥来证明其身份。
- 客户端使用服务器的公钥加密后向服务器发送随机位。
- 服务器解密客户端的消息，使用这些位天生会话密钥。
- 实际上，服务器还验证消息填充。
- 然而，仍然可以测量直到服务器以某种方式相应的时间。
服务器上 解密流水线 的图示：
- * CRT * To Montgomery * Modular exp
- --> * c_0 = c mod q --> * c'_0 = c_0*R mod q --> * m'_0 = (c'_0)^d mod q
- /
- / * Use sliding window for bits
- / * of the exponent d
- c * Karatsuba if c'_0 and q have
- * same number of 32-bit parts
- \
- \ * Extra reductions proportional
- \ * to ((c'_0)^z mod q) / 2R;
- --> ... * z comes from sliding window
- 然后，计算 m_0 = m'_0/R mod q。
- 然后，使用 CRT 结合 m_0 和 m_1 得到 m。
- 然后验证 m 中的填充。
- 最后，以某种方式使用有效载荷（SSL 等）。
为 Brumley 论文中形貌的攻击设置
- 受害者 Apache HTTPS 网络服务器使用 OpenSSL，在内存中有私钥。
- 连接到斯坦福校园网络。
- 对手控制校园网络上的某些客户端呆板。
- 对手向服务器发送特制的消息中的密文。
- 服务器解密密文，找到垃圾填充，返回错误。
- 客户端测量相应时间以获取错误消息。
- 利用相应时间推测 q 的位。
- 总体相应时间约莫为 5 毫秒。
- 什么导致时间变化？
- 一旦推测足够多的 q 位，就可以因式分解 n=p*q，从 e 计算 d。
- 约莫 1M 次查询似乎足以获取 1024 位密钥的 512 位 p 和 q。
- 只需推测 p 和 q 的前 256 位，然后使用另一种算法。
Brumley 论文中的攻击
- 查看 远程定时攻击是可行的 论文，详细内容请参考末端的 参考文献 部分。
- 让 q = q_0 q_1 .. q_N，其中 N = |q|（比如，对于 1024 位密钥，假设为 512 位）。
- 假设我们知道 q 的高阶位 j 个数字（从 q_0 到 q_j）。
- 构造两个近似值的 q，推测 q_{j+1} 是 0 或 1：
- g = q_0 q_1 .. q_j 0 0 0 .. 0
- g_hi = q_0 q_1 .. q_j 1 0 0 .. 0
- 让服务器执行模幂运算 (g^d) 来推测。
- 我们知道 g 肯定小于 q。
- 假如 g 和 g_hi 都小于 q，花费的时间不应该有太大变化。
- 假如 g_hi 大于 q，花费的时间可能会明显变化。
- g_hi mod q 很小。
- 较少时间：Montgomery 中减少额外的减少。
- 更多时间：从卡拉茨巴切换到普通乘法。
- 知道所花费的时间可以告诉我们 0 还是 1 是精确的推测。
- 怎样让服务器对我们的推测执行模指数运算？
- 将我们的推测发送给服务器，就似乎它是随机性的加密。
- 一个问题：服务器将把我们的消息转换为蒙哥马利形式。
- 由于蒙哥马利的R是已知的，将(g/R mod n)作为消息发送给服务器。
- 怎样确定时间差应该是正数还是负数？
- 论文似乎暗示这并不紧张：只需寻找大的差别。
- 图 3a 体现了每个比特推测的测量时间差别。
- 卡拉茨巴与普通乘法发生在 32 位界限处。
- 前 32 位：额外的约简占主导地位。
- 接下来的位：卡拉茨巴与普通乘法的支配。
- 在某个时刻，额外的约简再次占主导地位。
- 假如两种效应的时间差抵消会发生什么？
- 图 3，关键 3。
- 更大的邻域会稍微改变平衡，展现非零间隙。
- 论文怎样获得准确的测量结果？
- 客户机使用处理器的时间戳计数器（在 x86 上为rdtsc）。
- 进行多次测量，取中位数值。
- 不清晰为什么要中位数；最小值似乎才是真正的计算时间。
- 一个问题：由于滑动窗口，对g的乘法相对较少。
- 解决方案：通过获取与g接近的值进行更多的乘法运算（对g_hi同样适用）。
- 详细来说，探测g的“邻域”（g, g+1, .., g+400）。
- 为什么要探测g的 400 个值的邻域，而不是测量g 400 次？
- 考虑我们试图处理的噪音类型。
- (1) 与计算无关的噪音（比方停止，网络延迟）。
- 当我们多次测量相同的事物时，这种情况可能会消散。
- 参见论文中的图 2a。
- (2) 与计算相关的“噪音”。
- 比方，通过滑动窗口将g³和g_hi³相乘需要差别的时间。
- 重复的测量将返回相同的数值。
- 不会帮助确定是通过g还是g_hi进行更多的约简。
- 参见论文中的图 2b。
- 邻域值平均出第二种噪音。
- 由于邻域值相邻，仍具有大抵相同数量的约简。
怎样制止这些攻击？
- 解密时间的定时攻击：RSA 盲化。
- 选择随机的r。
- 将密文乘以r^e mod n：c' = c*r^e mod n。
- 由于 RSA 的乘法性质，c'是m*r的加密。
- 解密密文c'以获取消息m'。
- 将明文除以r：m = m'/r。
- 根据布鲁姆利的论文，OpenSSL 的 CPU 开销约为 10%。
- 使全部代码路径在执行时间方面可预测。
- 困难，编译器将努力消除不必要的操纵。
- 阻止了高效的特殊情况算法。
- 难以预测执行时间：指令不是固定时间的。
- 我们可否剥夺对精确时钟的访问？
- 对于我们控制的呆板上的单线程攻击者是可以的。
- 可以向合法计算添加噪音，但攻击者可能会进行平均。
- 可以对合法计算进行量化，但会有肯定的性能本钱。
- 但通过"睡眠"量化，吞吐量仍然可能泄漏信息。
我们应该对这些攻击感到多么担心？
- 开发利用步伐相对棘手（但这是一个一次性问题）。
- 可能会留意到服务器上的攻击（许多连接请求）。
- 尽管在繁忙的 Web 服务器集群上可能不那么容易？
- 对手必须在网络方面靠近。
- 对于对手来说并不是一个大问题。
- 可以对更多查询进行平均，共同定位附近（Amazon EC2），
- 对手可能需要知道 OpenSSL 的版本、优化标志等。
- 依赖这样的防御措施是个好主意吗？
- 这会带来多大的障碍？
- 假如对手发动攻击，结果相当严重（密钥泄露）。
其他类型的时序攻击
- 用于推测密码的页面错误时序 [Tenex 系统]
- 假设内核提供了一个系统调用来检查用户的密码。
- 对手对齐密码，使第一个字节位于页面末端，
- 以某种方式安排第二页被互换到磁盘。
- 测量推测密码时返回错误所需的时间。
- 假如花费了很长时间，内核必须从磁盘中读取第二页。
- 或者，假如取消映射，假如崩溃，那么内核会尝试读取第二页。
- 意味着第一个字符是精确的！
- 可以在256*N次尝试中猜出一个N字符的密码，而不是256^N次。
- 缓存分析攻击： 处理器的缓存由全部进程共享。
- 比方：访问滑动窗口的一个倍数会将其带入缓存。
- 在缓存中肯定会驱逐其他内容。
- 恶意进程可能会用大数组填充缓存，观察被驱逐的内容。
- 根据被驱逐的偏移量推测指数(d)的部分。
- 缓存攻击在"移动代码"中可能会有问题。
- 在您的桌面或手机上运行的 NaCl 模块、Javascript、Flash 等。
- 网络流量时序/分析攻击。
- 即使数据被加密，其密文巨细仍然与明文巨细相近。
- 近来的论文表明可以通过巨细、时序推断出许多关于 SSL/VPN 流量的信息。
- 比方，Fidelity 允许客户通过 SSL 网站管理股票。
- 网站为每支股票体现某种饼图图像。
- 用户的浏览器请责备部用户的股票图像。
- 对手可以罗列全部股票饼图图像，知道巨细。
- 可以根据数据传输的巨细推断用户拥有的股票。
- 类似于本学期早些时间客座讲座中提到的 CRIME 攻击。
参考资料
- 远程时序攻击是实际的
- 为了好玩和利润而缺失缓存
- AES 的高效缓存攻击及对策
- 离开我的条记本电脑：针对个人电脑的物理侧信道密钥提取攻击
- 跨虚拟机侧信道及其用于提取私钥
- Ed25519：高速高安全性签名
用户认证
留意： 这些讲座条记略有修改，来自 2014 年 6.858 课程网站上发布的内容。
焦点挑战： 人类用户怎样向步伐证明其身份？
- 是否有任何完全主导密码的解决方案？
- 乍一看，密码似乎很糟糕。
- 低熵-->容易让攻击者猜到它们。
- 用于密码的备用安全问题也具有低熵。
- 用户经常为多个站点使用相同的密码。
- 正现在天课堂上的论文所述，“密码继承在全部其他终端用户认证方法上占主导地位，这对安全研究职员来说是一个重大尴尬。”
- 但是…是否实际上有一种认证方案完全主导密码？
- 今天讲座的筹划：
- 查看当前密码方案的工作原理。
- 讨论认证方案的抱负属性。
- 查看其他认证方案与密码的比较。
密码
密码是用户和服务器之间共享的秘密。
- 天真的实现： 服务器有一个将用户名映射到明文密码的表。
- 问题： 假如攻击者入侵服务器，可以恢复全部用户/密码对。
- 改进方案： 服务器存储此表：user_name --> hash(user_password)
- 用户客户端向服务器提供明文密码，服务器对明文进行哈希并进行表查找。
- 上风： 哈希函数难以反转，因此攻击者难以执行暴力攻击。然而…
- 问题： 攻击者不必对全部可能的密码启动低效的暴力搜索 – 实际用作密码的字符串集相当小！
- 偏斜分布：前5000个密码值覆盖20%的用户。
- 雅虎密码研究：经验法则密码包含10-20 bits的熵。
- 哈希函数优化性能；这有助于攻击者！
- 例子： 一台条记本电脑可以以每秒约2M SHA1 ops/sec的速度计算 SHA1。即使密码具有20 bits的熵，也可以每秒破解一个帐户。
- 服务器可以使用计算本钱昂贵的密钥派生函数（比方，PBKDF2 或 BCrypt）。
- 这些函数具有可调整的本钱，因此它们可以任意缓慢。
- 比方：可以使哈希本钱为 1 秒 – 比 SHA1 慢O(1M)倍。
- 内部通常使用慢哈希进行重复哈希。
- 问题： 对手可以构建"彩虹表"。
- 密码到哈希映射表。
- 计算本钱高昂，但允许攻击者之后有效地反转哈希。
- 为了最大化本钱/效益权衡，攻击者只需为常见密码字典构建一个彩虹表。
- 大抵：1 秒昂贵的哈希|-> 1M 秒 = 10 天来哈希常见密码。之后，可以非常快速地破解任何密码数据库中的常见密码。
- 更好的解决方案： 服务器可以使用密码盐。
- 在密码哈希中输入一些额外的随机性：H(salt, pw)。
- 盐值从哪里来？它以明文形式存储在服务器上。
- Q： 假如对手也能破解盐，为什么这样做更好？
- A： 攻击者无法使用单个彩虹表来检查哈希匹配 – 相同密码使用差别盐将具有差别的哈希值！
- 最佳实践：
- 选择一个长的随机盐。
- 每次用户更改密码时选择一个新的盐。
客户端应该怎样将密码传输到服务器？
- 欠好的主意： 明文发送密码。
- 稍微好一点： 通过加密连接发送密码。
- 缺点： 连接可能被假冒服务器的攻击者拦截（加密并不肯定意味着服务器已经向客户端进行了身份验证！）。中心人攻击者然后可以使用盗取的密码冒充用户。
- Q： 假如客户端发送密码的哈希而不是原始密码呢？
- A： 并不会为我们提供额外的权力，因为哈希仍然可以被攻击者重放。
- 故事寓意： 加密和哈希并不会主动增加安全性 – 你需要考虑你想要实现的安全性质，并详细的加密和哈希可以实现这些目标的方式。
- 更好的主意： 挑战/相应协议。
例子：
- Client Server
- Hi, I'm Alice.
- ---------------->
- Challenge C
- <----------------
- H(C || password)
- ----------------->
- - Server checks whether the
- response is H(C || password).
- 忽略中心人（MITM）攻击，服务器现在确信用户是 Alice。
- 假如服务器是攻击者并且之前不知道密码，那么攻击者仍然不知道密码。
- Q： 我们怎样防止服务器基于H()值进行暴力推测密码？
- A1： 昂贵的哈希+盐。
- A2： 允许客户端也选择一些随机性：防范彩虹表。
- 为了制止在服务器上存储真实密码，使用类似SRP的协议。
- 高级思想： 给定安全参数g，客户端计算v = g^(hash(salt, password))并将v和salt发送到服务器。客户端和服务器可以利用对g和v的共享知识创建临时密钥（该协议利用了攻击者难以执行模N下的离散对数的究竟；RSA 也利用了这一观察结果）。
- 实验挑战/相应通常意味着改变客户端和服务器。
为了防止暴力破解攻击，我们可以实验反锤击防御。
- 例子： 限定密码推测次数；在太多错误推测后实验超时期。
- 限定推测速率非常紧张，因为密码的熵很低！
- 许多网站对密码施加要求（比方长度，使用标点等特殊字符）。
- 实际上，紧张的是熵！格式要求很少转化为更高的熵。
- 一个称职的字典攻击者可以模拟密码约束并天生彩虹表；即使有约束，人们仍会选择符合先验字符分布的密码。
- Telepathwords: telepathwords.research.microsoft.com/
- 当您输入潜伏的密码字母时，尝试使用开导式推测下一个字母！
- 常见密码（比方，通过密码数据库泄漏）
- 来自网站的流行短语
- 用户在选择字符时常见的私见（比方，使用相邻键来输入相邻的密码字符）
- Kerberos v4 和 v5 在没有预身份验证的情况下容易受到离线推测的影响：www.gnu.org/software/shishi/wu99realworld.pdf
- 任何人都可以向 KDC 请求使用用户密码加密的票证，即 KDC 不会验证请求（尽管相应将使用K_c加密）。
- 攻击者可以尝试暴力破解推测用户的密码–这很容易并行化。由于票据授予票据具有已知格式，攻击者可以确定解密何时乐成。
- 在 Kerberos v5 中，票证请求者必须在请求中包含{ timestamp }_{K_c}，以证明对K_c的相识。
密码恢复非常紧张，但经常被忽视。
- 人们经常关注密码的熵，但假如恢复问题可以用来重置密码，密码认证方案的强度为min(password_entropy, recovery_question_entropy)。
- 恢复问题通常很容易被猜到。在一个闻名的例子中，有人通过推测萨拉·佩林的安全问题的答案获得了对她的雅虎地址的访问权限。
- 固有低熵（“你最喜欢的颜色是什么？” “你最好朋友的名字是什么？”）
- 通过交际媒体资料泄露的答案（“你最喜欢的电影是什么？”）
- 主动天生的问题通常很容易回答（“5 + 5 即是多少？”）
代替密码的寻求
在今天的阅读中，作者提出了一堆可以用来评估认证方案的因素（目标是确定密码是否像它们看起来那样糟糕）。作者考虑了三个高级指标：可用性、部署性和安全性。
- **可用性：**用户与认证方案交互的难易水平怎样？
- 易学性：
- “不相识方案的用户可以轻松地弄清晰并学会它。”
- 这是密码方案如此受欢迎的一个关键缘故原由！
- 不经常出现的错误：
- “用户必须执行的登录使命通常在由合法和诚实的用户执行时乐成。”
- 这是用户选择易于推测密码的紧张缘故原由。
- 用户可扩展性：
- “使用方案登录数百个帐户不会增加用户的负担。”
- …解释了为什么人们经常重复使用密码或为根本密码创建一个简单的每个站点唯一化方案。
- 轻松从认证令牌丢失中恢复：
- 无需携带
- 可部署性： 将身份验证方法整合到实际系统中有多容易？
- 与服务器兼容：
- “在验证者端，该方案与基于文本的密码兼容。提供者不必更改其现有的身份验证设置以支持该方案。”
- 与浏览器兼容：
- “用户不必更改他们的客户端以支持该方案。假如方案要求安装插件或任何需要管理员权限的软件，则无法提供这种好处。”
- 易访问：
- “可以或许使用密码的用户不会因残疾或其他身材（非认知）状态而无法使用该方案。”
- 可部署性非常困难：很难让用户或服务器大规模更新！
- 密码在这一种别中体现良好，默认情况下，因为作者将“可部署性”定义为系统与当前密码基础设施整合水平。然而，密码在下一个种别中体现不佳……
- 安全性： 身份验证方案可以防范哪些攻击？
- 对物理观察具有弹性：
- “在观察用户进行一次或多次身份验证后，攻击者无法冒充用户。假如方案只能通过重复观察 10-20 次以上才能被破解，我们授予准弹性对物理观察的方案。攻击包括肩窥、拍摄键盘、录制按键声音或热成像键盘。”
- 密码未通过此测试，比方，可以通过拍摄键盘或录制按键声音来捕捉密码。
- 对有针对性的冒充具有弹性：
- “通过利用个人细节（出生日期、亲属姓名等）的知识，熟人（或熟练的调查员）无法冒充特定用户。个人知识问题是在这一点上失败的典型方案。”
- 作者表示密码是“准抗性”的，因为他们找不到任何研究表明您的朋友或熟人可以轻松猜出您的密码。
- 对受限定的推测具有弹性：
- “一个攻击者的推测速率受到验证者的限定，不能乐成推测出大部分用户的秘密……缺乏这种好处意味着处罚那些经常让用户选择的秘密从一个小而众所周知的子集中选择的方案。”
- 密码失败是因为熵值低 + 分布倾斜。
- 对不受限定的推测具有弹性：
- “只受可用计算资源限定的推测速率的攻击者无法乐成推测出大部分用户的秘密。比方，假如一个可以或许尝试每个账户最多 2⁴⁰ 乃至 2⁶⁴ 次推测的攻击者仍然只能到达不到 1%的账户，我们可能会授予这一好处。缺乏这一好处旨在处罚那些凭证空间不敷以抵御来自一个小而众所周知的子集的暴力搜索的方案。”
- 密码失败是因为它们具有低熵和偏斜分布。
- 对内部观察具有弹性：
- “攻击者无法通过拦截用户设备内的用户输入（比方，通过键盘记录恶意软件）或窃听证明者和验证者之间的明文通信来冒充用户（我们假设攻击者也可以击败 TLS，大概通过 CA）。这处罚了那些不具备重放抵抗性的方案，无论是因为它们发送静态相应还是因为它们的动态相应对策可以通过少数观察被破解。这一好处假定通用设备（如软件可更新的个人计算机和手机）可能包含恶意软件，但专门用于该方案的硬件设备可以做到无恶意软件。”
- 密码失败是因为它们是静态令牌：一旦你有了一个，你可以使用它直到它过期或被撤销。
- 对网络钓鱼具有弹性：
- “模拟有效验证器的攻击者（包括通过 DNS 利用）无法网络以后可以用来冒充用户向实际验证器进行身份验证的根据。这处罚了允许网络钓鱼者让受害者在类似网站上进行身份验证，然后将网络的根据用于真正网站的方案。”
- 密码失败：网络钓鱼攻击非常普遍！
- 无信任第三方：
- “该方案不依赖于一个可信任的第三方（除了证明者和验证者），后者在遭受攻击或变得不可信任时，可能会危及证明者的安全或隐私。”
- 这一属性提出了一个紧张观点：假如我们可以信任一个方当来存储密码、运行密码服务器等，许多身份验证问题将变得更容易。然而，单点故障是欠好的，因为攻击者可以将全部精力集中在那一点上！
- 对其他验证者泄露具有弹性：
- “验证者可能泄露的任何信息都不能帮助攻击者冒充用户向另一个验证者进行身份验证。这处罚了那些在一个提供者内部敲诈或对一个后端的乐成攻击危及用户在其他网站账户的方案。”
- 这一属性与无信任第三方有关。为了制止中央化故障点，我们盼望引入一些分布式身份验证的概念：然而，这是否意味着系统的强度仅取决于其最薄弱的环节？
- 回想一下 HTTPS，以及一个糟糕的证书颁发机构怎样说服浏览器担当任意站点的伪证书。安全性取决于最不安全的 CA 的强度！
- 作者表示，密码失败是因为人们经常在差别网站上重复使用密码。
生物特征识别
生物特征识别： 利用个人外貌或活动的独特方面。
- 密钥空间有多大？
- 指纹： ~13.3 位。
- 虹膜扫描： ~19.9 位。
- 语音识别： ~11.7 位。
- 因此，熵的位数大抵与密码相同。
生物特征识别与密码
- Usability metric Passwords Biometrics
- --- --- ---
- Easy-to-learn: Yes Yes
- Infrequent errors: Quasi-yes No
- Scalable for users: No Yes
- Easy recovery: Yes No
- Nothing to carry: Yes Yes
- Usability score: 3.5 vs 3
- Deployability metric Passwords Biometrics
- --- --- ---
- Server-compatible: Yes No
- Browser-compatible: Yes No
- Accessible: Yes Quasi-yes (entering biometrics is error-prone)
- Deployability score: 3 vs 0.5
- Security metric Passwords Biometrics
- --- --- ---
- Res-to-Phys-Obs: No Yes
- Res-to-Trgtd-Imp: Quasi-yes No (e.g., replaying voice recording, lifting fingerprints from surfaces)
- Res-to-Thrtld-Guess: No Yes
- Res-to-UnThrtld-Guess: No No (key space isn't much bigger than that of passwords)
- Res-to-Internal-Obv: No No (captured biometric data can be replayed)
- Res-to-Phishing: No No
- No-trusted-3rd-Party: Yes Yes
- Res-Other-Ver-Leaks: No No (same biometrics are used by all verifiers)
- Security score: 1.5 vs 3
有些目标似乎很难同时实现。
- Memorywise-Effortless + Nothing-to-Carry.
- Memorywise-Effortless + Resilient-to-Theft.
- // Either the user remembers something, or
- // it can be stolen (except for biometrics).
- Server-Compatible + Resilient-to-Internal-Observation.
- Server-Compatible + Resilient-to-Leaks-from-Other-Verifiers.
- // Server compatible means sending a password.
- // Passwords can be stolen on user machine,
- // replayed by one server to another.
- 需要用户使用两种或更多身份验证机制进行身份验证。
- 机制应涉及差别的模态！
- 您所知道的东西（比方，密码）
- 您拥有的东西（比方，手机，硬件令牌）
- 您是什么（比方，生物特征）
- 思路是攻击者必须盗取/破坏多个身份验证机制才能冒充用户（比方，攻击者可能推测密码，但无法访问用户的手机）。
- 比方：谷歌的双因素认证需要密码加上一个可以通过短信接收授权码的手机。
- 比方：AWS 的双因素认证需要密码和一个“MFA 设备”（运行身份验证应用步伐的智能手机，或专用安全令牌或安全卡）。Amazon MFA
- 多因素认证是个好主意，但实证研究表明，假如用户除了密码外还提供第二个身份验证因素，用户会选择更弱的密码！
家庭作业问题
家庭作业问题的潜伏答案是什么？哪些因素很紧张？
- 登录公共 Athena 呆板？
- 对内部观察具有弹性：在呆板上轻松安装恶意软件。
- 对物理观察具有弹性？+ MIT ID 可能是一个值得利用的好东西（将其用作智能卡）。
- 生物特征识别？不受信任的终端，可能不是一个很好的筹划。
- 从网吧访问 Facebook？
- 在这里不是一个好主意使用密码管理器。
- 数据的敏感水平有多高？
- 可能被用于认证到其他网站！（要么是“使用 Facebook 登录”，要么是通过回答个人安全问题来重置密码。）
- 从 ATM 取款？
- 安全性非常紧张。
- 可能是可信的终端：生物特征识别可能值得考虑。（然而，在实践中，银行可能不想信任终端。）
- 您可能还关心对个别生意业务进行身份验证！
- 防止对手使用被盗的凭证进行差别的、由攻击者选择的操纵。
- 比方：大概用户只需使用密码就能查看余额，但假如她想要取款，她就需要使用手机进行双因素认证。
结论
论文结论：没有一个认证方案明显优于密码！比方，根据作者的说法，CAP 读卡器在安全性方面得分完美！
- CAP 读卡器是由万事达卡计划用来掩护在线银行生意业务。
- 用法：
- 将您的信用卡插入看起来像手持计算器的 CAP 读卡器中。
- 输入 PIN 码（绕过键盘记录器！）。
- 读卡器与卡片的嵌入式处理器通信，输出一个 8 位数码，用户将其提供给网站。
分析：
- CAP reader
- Easy-to-learn: Yes
- Infrequent errors: Quasi-yes
- Scalable for users: No (users require card+PIN per verifier)
- Easy recovery: No
- Nothing to carry: No
- Score: 1.5
- CAP reader
- Server-compatible: No
- Browser-compatible: Yes
- Accessible: No (blind people can't read 8-digit code)
- Score: 1
- CAP reader
- Res-to-Phys-Obs: Yes\
- Res-to-Trgtd-Imp: Yes \__ One-time codes!
- Res-to-Thrtld-Guess: Yes /
- Res-to-UnThrtld-Guess: Yes/
- Res-to-Internal-Obv: Yes Dedicated device
- Res-to-Phishing: Yes One-time codes
- No-trusted-3rd-Party: Yes Each site is its own verifier
- Res-Other-Ver-Leaks: Yes One-time codes
- Score: 8
- 因此，密码=8，CAP 读卡器=10.5。然而，CAP 读卡器没有占领天下的缘故原由（请参阅低可用性和可部署性得分）。
- 在实践中，可部署性和可用性通常比安全性更紧张。
- 迁徙本钱（编码+调试工作，用户培训）让开发职员感到告急！
- 方案越不可用，用户就越会抱怨（并尝试选择更容易受攻击者攻击的认证令牌）。
- 一些情况可能会给差别的评估指标分配差别的权重。
- 例子：在军事基地上，基于硬件的令牌的安全性上风可能超过可用性和可部署性的问题。
私密浏览模式
留意： 这些讲座条记是从 2014 年 6.858 课程网站上发布的条记稍作修改而来。
私密浏览：目标、定义、威胁模型
隐私的目标是什么？
- 含糊的抱负：（某个）用户的活动与许多其他用户的活动不可区分。
- 今天我们将讨论网络浏览器隐私的问题。
- 由于网络应用步伐非常复杂且可能天生大量可追踪的状态，因此对于私密浏览的定义并不明确。
- 浏览器根据用户需求和其他浏览器供应商的做法更新其私密浏览实现。
- 由于用户依赖私密浏览模式，他们对其期望更高…并且更多的实现缺陷浮出水面！
浏览器所谓的“私密浏览”是什么意思？
- 论文将此形式化为两个独立的威胁模型+攻击：
- 一个本地攻击者在浏览会话竣事后拥有您的呆板，并盼望发现您访问过哪些网站。
- 一个网络攻击者入侵了您联系的网络服务器，并盼望将您跨私密和/或正常会话进行关联。
- 假如两个攻击者合作，他们更容易识别用户。
- 比方：本地攻击者要求服务器检查服务器访问日记中的本地 IP 地址。
- 因此，对这两种攻击单独进行安全防护具有实际代价。
威胁 1：本地攻击者
- 假设： 攻击者在会话竣事后控制用户的呆板，并盼望相识用户在私密浏览模式下访问了哪些网站。
- 安全目标： 攻击者不能相识这些网站！
- 非目标
- 不关心为将来的私密浏览会话实现隐私。
- 攻击者可能修改呆板上的软件（比方安装键盘记录器）并跟踪将来的浏览活动。
- 这也是为什么我们假设攻击者在私密浏览开始之前无法访问呆板。
- 隐藏使用私密浏览的究竟。
- 通常被称为“公道否认”。
- 论文指出这很难实现，但没有解释缘故原由。在背面的讲座中，我们将讨论一些潜伏缘故原由。
私密会话可以泄漏哪些持久的客户端状态？（持久性指的是“存储在本地磁盘上”。）
- JavaScript 可访问的状态：Cookies，DOM 存储
- 浏览器缓存
- 访问地址的历史记录
- 配置状态：新的客户端证书，更新的保存密码数据库，书签
- 下载的文件
- 新插件/浏览器扩展
…以及：
- 全部私密浏览实现都试图防止持久泄漏到 1、2 和 3. 但是，4、5 和 6 在私密会话竣事后通常仍然存在。
- 网络活动可能留下持久的证据–DNS 解析记录！
- 要解决这个问题，私密浏览模式需要在会话竣事时刷新 DNS 缓存。然而，这很棘手，因为刷新缓存通常需要在您的呆板上具有管理员权限（您盼望浏览用具有管理员权限吗？）并删除全部 DNS 状态，而不是特定用户天生的状态。
- 在私密浏览期间，内存中的对象也可能被分页到磁盘上！
演示：
- Open Firefox in Private Browsing Mode
- Visit http://pdos.csail.mit.edu/
- sudo gcore $(pgrep firefox)
- strings core.* | grep -i pdos
- // -e l: Look for string using the
- // character encoding 16-bit
- // little-endian.
- // -a: Scan all of the file.
- // -t: Print the offset within
- // the file.
- 例子：假如泄露了加密密钥或密码可能会有问题。参考链接
演示：
- cat memclear.c
- cat secret.txt
- make memclear
- ./memclear &
- sudo gcore $(pgrep memclear)
- strings core.* | grep secret
- 进程内存：堆，栈。
- 终端滚动回溯
- I/O 缓冲区，X 变乱队列，DNS 缓存，署理服务器，…
- 语言运行时会复制数据（比方，在 Python 中的不可变字符串）
- 文件，文件备份，SQLite 数据库
- 互换文件，休眠文件
- 内核内存：
- IO 缓冲区：键盘，鼠标输入
- 开释的内存页面
- 网络数据包缓冲区
- 管道缓冲区包含进程间发送的数据
- 随机数天生器输入（包括再次输入按键）。
攻击者怎样获取剩余数据的副本？
- 文件本身可能包含多个版本（比方，Word 曾支持此功能）。
- 假如步伐在开释内存或步伐关闭时不擦除内存，可能会泄漏信息：
- 比方：在旧版 Linux 内核中，当创建新目录时，最多可以泄漏 4 KB 的内核内存到磁盘。
- 比方：假如内核/VMM 不擦除内存页面，那么来自进程 X 的信息可能泄漏到使用 X 旧内存页面的进程 Y 中。
- 焦点转储
- 直接访问呆板
- 闪存 SSD 实现日记记录–它们不会立刻擦除旧数据！
- 盗取的磁盘，或者只是处理旧磁盘 [参考链接: http://news.cnet.com/2100-1040-980824.html]
我们怎样处理数据生命周期问题？
- 清空未使用的内存[会有一些性能降低]。
- 在难以清零的地方加密数据（比方，在 SSD 上）。
- 安全删除密钥意味着数据无法再解密！
- 比方：OpenBSD 互换使用加密，每次启动时天生新的加密密钥。
- 与磁盘 I/O 相比，加密的 CPU 本钱是适度的。
威胁 2：网络攻击者
- 假设：
- 攻击者控制用户访问的网站。
- 攻击者无法控制用户的呆板。
- 攻击者盼望检测用户访问网站的情况。
- 安全目标：
- 攻击者无法识别用户。
- 攻击者无法确定用户是否使用私密浏览模式。
防御网络攻击者非常困难！
- 识别用户意味着什么？
- 同一用户从差别私密浏览会话中访问链接。
- 用户从私密浏览和公共浏览会话中访问链接。
- 识别用户的简单方法：IP 地址。
- 公道概率上，来自相同 IP 地址的请求是同一用户。
- 下一讲，我们将讨论 Tor。Tor 掩护 TCP 连接源（即用户的 IP）的隐私。但是，Tor 并不能解决实现私密浏览的其他挑战。
- 即使用户使用 Tor，Web 服务器仍然可以通太过析她的浏览器运行时的独特特征来识别她！
浏览器指纹演示：
- - Open Chrome, go to http://panopticlick.eff.org/
- - Open the same web site in private
- browsing mode.
- 隐私的良好思考方式：用户的匿名集是什么？即，在哪个最大的用户集中，某个用户是无法区分的？
- Panopticlick 体现，对于大多数用户，此集合很小，因为用户倾向于具有唯一的本地设置，如字体、插件等。
- 网络攻击者怎样确定您是否在使用私密浏览模式？
- 论文形貌了基于链接颜色的历史嗅探攻击。
- 攻击者页面在 iframe 中加载 URL，然后创建到该 URL 的链接，并查看链接是否为紫色（私密会话不存储历史记录）。
- 由于浏览器不再向 JavaScript 公开链接颜色，此攻击不再有效！[请参阅几堂课前讨论的历史嗅探攻击讨论。]
- 但是，攻击者可能有其他方法来判断您是否在使用私密模式。
- 比方：公共模式的 Cookie 无法被私密模式页面看到。因此，假如您在公共模式下访问页面，然后在私密模式下访问，页面可以检测到缺少预期的 Cookie。
方法
我们怎样为私密浏览提供更强的包管？（暂时忽略 IP 地址隐私，或者假设用户使用 Tor。）
- 方法 1：虚拟机级隐私
- 筹划：
- 每个私密浏览会话在单独的虚拟机中运行。
- 确保在私密浏览竣事后删除虚拟机。
- 确保没有虚拟机状态最终出现在磁盘上[禁用分页？安全开释？]。
- 上风：
- 对本地攻击者和网络攻击者提供强有力的包管。
- 应用步伐无需更改，只需安全删除虚拟机。
- 缺点：
- 为私密浏览启动单独的虚拟机是繁重的。
- 使用不便：用户更难保存私密浏览中的文件，使用书签等。
- 可用性和隐私之间存在固有的权衡！
- 方法 2：操纵系统级隐私
- 筹划： 在操纵系统内核级别实现类似的包管。
- 上风超过虚拟机：更轻量级。
- **相对于虚拟机的缺点：**更难精确实现，因为操纵系统内核管理了大量状态。
是否有方法可以对使用这些方法的用户进行去匿名化？
- 大概虚拟机本身是独一无二的！因此，我们需要确保全部用户拥有类似的虚拟机。
- 大概 VMM 或主机计算机引入了一些独特性。
- 比方： TCP 指纹识别：TCP 协议允许实现设置一些参数（比方，初始数据包巨细，初始 TTL）。
- 像 nmap 这样的工具向远程服务器发送精心制作的数据包；可以高度可能性地推测远程操纵系统！
- 用户仍然是共享的！因此，攻击者可能会：
- 检测用户的击键时序。
- 检测用户的写作风格。这被称为笔迹学。参考
浏览器为什么要实现自己的私密浏览支持？
- 主要缘故原由是可部署性：用户不必在自定义虚拟机或操纵系统中运行其浏览器。
- 另一个缘故原由是可用性：私密模式中天生的某些类型的状态应该可以或许在会话竣事后连续存在。（比方：下载的文件）。
- 这是一个危险的筹划！浏览器是复杂的软件，因此很难找到架构中允许某些类型的状态（但不允许其他类型）持久存在的清晰界限。
我们怎样对这些类型的状态进行分类？论文指出我们应该考虑是谁发起了状态更改（第 2.1 节）。
- 由网站发起，无用户交互： cookies，历史记录，缓存。
- 由网站发起，需要用户交互： 客户端证书，保存的密码。
- 不清晰什么是最佳策略；浏览器倾向于持久存储此状态，可能是因为用户必须明确授权该操纵。
- 由用户发起： 书签，文件下载。
- 与上述相同：浏览器倾向于持久存储此状态，因为用户授权了该操纵
- …但请留意，存储此状态可能会泄露用户使用私密浏览模式的究竟！
- 比方： 在 Firefox 和 Chrome 中，书签存储在 SQLite 数据库中。在私密浏览模式下天生的书签将对last_visit_count等元数据有空值参考
- 与会话无关： 浏览器更新，证书吊销列表更新。
- 将其视为在公共模式和私密模式之间共享的单个全局状态。
浏览器实际上实现了什么？
- 每个浏览器当然都是差别的。
- 别的，某些状态在一个方向上“泄露”，但在另一个方向上不会！私密模式和公共模式状态之间没有严酷的分区。
问答：
- Q: 假如公共状态泄露到私密状态会发生什么？
- A: 网络攻击者更容易将私密会话与公共会话关联起来。
- 比方： 在公共模式下安装的客户端 SSL 证书可以识别私密模式中的用户。
- Q: 假如私密状态泄露到公共状态会发生什么？
- A: 这对于网络攻击者和本地攻击者都有帮助：观察公共会话的状态将会泄露关于私人会话的信息！
- Q: 用户在私密模式会话中时状态应该怎样处理？
- A: 大多数浏览器允许状态在私密模式会话中持久存在（见表 3）。
- "否"表示网络攻击者可能可以或许检测到私密模式浏览！
- Q: 为什么允许在私密浏览模式下使用 cookies？
- 问： 对用户来说，在隐私浏览模式下可以或许创建临时会话很方便—浏览器将在私密会话竣事时删除相关的 cookie。
- 问： 私密模式会话之间的状态应该怎样处理？
- 答： 抱负情况下，每个私密会话应该从零开始—假如状态在多个私密会话之间传递，这会增加用户被指纹识别的可能性！然而，由于某些类型的状态可以从私密到公共传递，某些类型的状态可以从公共到私密传递，因此某些类型的状态确实可以在私密模式会话之间连续存在。[比方：证书、下载的项目。]
- 因此，将每个私密模式会话视为与单个公共模式共享某些状态。
浏览器扩展
浏览器扩展和插件是特殊的。
- 它们是可以访问敏感状态的特权代码。
- 它们不受同源策略或其他浏览器安全检查的限定。
- 别的，它们通常是由浏览器供应商之外的人开发的！
- 因此，它们可能不相识私密模式的语义，或者可能错误地实现了预期的策略。
- 然而，插件可能在不久的将来会灭尽！HTML5 提供了新功能，为从前需要 Flash、小步伐、Silverlight 等的功能提供了本机支持。参考
- 多媒体：<video>，<audio>
- 图形：<canvas> WebGL
- 离线存储：DOM 存储
- 网络：Web sockets，CORS
当前的私密浏览模式
该论文是在 2010 年撰写的—私密浏览的当前状态怎样？
- 仍然很难精确实现私密浏览！
- 比方： 2014 年 1 月的 Firefox 漏洞修复：pdf.js 扩展允许公共 cookie 泄漏到私密模式的 HTTP 获取中。参考
- 比方： 2011 年的 Firefox 漏洞：假如您在隐私浏览模式下访问页面，然后关闭窗口，您可以转到 about:memory 并找到关于您所关闭的窗口的信息（比方，about:memory 将列出窗口的 URL）。参考
- 问题在于窗口对象是惰性垃圾回收的，因此关闭窗口不会强制窗口进行同步垃圾回收。
- 当潜伏解决方案比最初预期的更复杂时，该漏洞被“降级处理”；作为回应，一位开发者说：“这听起来很令人惆怅。这几乎可以破坏诸如 sessionstore 忘记关闭的私密窗口等功能的目标。”
- 现成的取证工具可以找到私密浏览器会话的证据。
- 比方: Magnet 的 Internet Evidence Finder [1]，[2]，可以找到 IE、Chrome 和 Firefox 的私密会话痕迹。
- 在私密会话期间，IE 将对象存储在文件系统中。这些对象在私密会话关闭时被删除，但存储空间并未被擦除，因此私人数据仍然存在于未分配的磁盘空间中。
- Chrome 和 Firefox 在私密浏览期间使用内存中的 SQLite 数据库，因此在文件系统中留下较少的痕迹。然而，像全部浏览器一样，它们在页面文件中留下痕迹。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
