PDF证书透明度
公开、可验证、仅追加的日志
Ben Laurie，谷歌
2011 年 8 月 28 日，一个错误签发的 google.com 通配符 HTTPS 证书被用于对伊朗的多名用户进行中间人攻击。该证书由一家荷兰 CA（证书颁发机构）DigiNotar（迪吉诺塔），VASCO Data Security International（VASCO 数据安全国际公司）的子公司颁发。后来的分析表明，DigiNotar 至少在一个多月前就已意识到其系统遭到入侵——至少从 7 月 19 日起。分析还显示，至少签发了 531 个欺诈性证书。最终数量可能永远无法得知，因为 DigiNotar 没有所有错误签发的证书记录。2011 年 9 月 20 日，DigiNotar 宣告破产。
此次泄露造成的损害不仅限于伊朗。当 DigiNotar 根证书最终被吊销时，距离最初发现已过去两周，其中包含一个荷兰政府用于提供互联网服务的根证书。此次吊销阻止了荷兰进行汽车买卖、电子清关以及在国际市场上购买电力等诸多活动。当然，每个持有 DigiNotar 颁发证书的 Web 服务器都不得不紧急获取新证书。
这并非 CA 首次被攻破，也非最后一次。Comodo Group（为 Google、Yahoo!、Skype 和其他公司错误签发证书）1、TürkTrust（未经授权的 google.com 证书）2 以及 ANSSI（据称通过中间机构为本地网络监控签发证书）都曾报告过泄露或内部错误签发事件。未来肯定还会发生更多此类事件。
将这些泄露归咎于 CA 的糟糕安全措施很容易，但事实是，软件工程和系统设计的最新技术无法使任何人绝对安全地免受攻击。虽然 CA 肯定要承担部分责任（尤其是那些知道发生了什么却保持沉默，希望蒙混过关的 CA！），但目前还没有人知道如何构建一个完全万无一失的系统。那么，我们该如何改进现状呢？
CA 的替代方案
也许退一步思考我们真正想要解决的问题会更有启发：最终，我们希望确保 Web 用户实际上是在与他们认为的对象对话，并且没有人可以拦截对话。这实际上是一个不可能实现的目标——计算机如何知道用户在想什么——但现在让我们将问题简化为一个稍微不同的问题：如何确保 Web 用户正在与正在使用的 URL 对应的域名所有者对话。诚然，这是一个相当薄弱的策略，但它至少在某些情况下有效。大多数人都知道大型网站（如 Google、PayPal 和 eBay）的正确 URL。同样，如果用户从诚实的来源点击正确的链接（实际上，大多数链接都是如此），他们就会受到保护。
计算机世界多年来依赖的解决方案是在系统中引入受信任的第三方（CA），他们为域名和私钥之间的绑定提供担保。问题在于，我们已经认可了数百个所谓的受信任的第三方，他们中的任何一个都可以为任何域名提供担保。他们时不时地会犯错，有时错得离谱。
有哪些替代方案？它们有哪些约束条件？让我们先谈谈约束条件。
约束条件
约束条件肯定会因系统的性质而异。这里关注的是 Google Chrome 浏览器的 Web 视角。以下是在为 Chrome 设计安全系统时需要考虑的一些约束条件
• 迁移路径。 必须存在某种从当前状态迁移到目标状态的可行方法。例如，需要全世界在变革日做出改变的解决方案是行不通的。
• 普遍适用。 没有人是特殊的。每个人都必须能够参与。换句话说，解决方案必须可扩展。
• （几乎）没有增加延迟。 Chrome 非常重视页面加载时间，因此不能让页面加载速度明显变慢。一个推论是不能有同步带外通信：页面加载前所需的一切都必须与页面本身在同一通道中到达。经验表明，如果我们必须咨询另一个来源，它会失败，而且速度会很慢。（有关该经验的讨论，请参阅 https://www.imperialviolet.org/2014/04/19/revchecking.html。）
• 不要让情况变得更糟。例如，通过引入另一组受信任的第三方来“修复”一组受信任的第三方，这似乎不是进步。
• 不要将决定推给最终用户。 我们已经知道用户不理解证书警告。期望他们理解更复杂的方案是不太可能的。
鉴于 CA 和受信任的第三方系统在确保互联网安全方面的缺点，已经出现了一些替代方案。在 Google，我们只找到了一种（剧透警告），证书透明度，它可以克服所有约束条件，并为安全问题提供合理的解决方案。在考虑为什么会这样之前，让我们先看看其他一些替代方案。
证书绑定
一种替代方案是让网站声明哪些证书（或 CA）对它们是正确的，浏览器拒绝任何不在该列表中的证书。目前，某些网站的证书 pin 已内置到 Chrome 中，但存在允许任何人声明证书 pin 的提案（例如，https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ 和 http://datatracker.ietf.org/doc/draft-perrin-tls-tack/）。
证书绑定由于一些微妙的原因而失败。当出现问题时会发生什么？显然，证书 pin 不能简单地被新的证书 pin 替换，否则就失去了意义。因此，证书 pin 会在一些预设时间后过期。如果您在证书 pin 过期之前丢失了密钥，那么您的网站将无法工作，直到它过期为止。较短的过期时间对干预者的保护作用很小，但较长的证书 pin 时间可能意味着在发生灾难时会出现严重的停机时间。
目前，如果发生这种情况，补救措施是联系 Chrome 并请求更改您的证书 pin，但这并非可扩展、包容性的解决方案。此外，至少在证书 pin 内置到 Chrome 中时，证书绑定会引入一个新的受信任的第三方（即 Google）。
公证人
另一种流行的替代方案是使用公证人。最著名的公证人是 Perspectives 项目（http://perspectives-project.org/）和 Convergence（http://convergence.io/）。Google 也曾运行过一个公证人项目，名为 SSL 证书目录4，但在开始研究证书透明度后决定不再继续支持它。其思想是定期扫描互联网，理想情况下从多个角度进行扫描，将所有证书插入公证人日志中，该日志稍后可以被询问：“您以前见过此证书吗？”如果答案是“否”或“不太常见”，那么该证书可能会受到一些怀疑。
这个想法有很多问题。最大的问题是，“否”的答案可能仅仅表明该网站刚刚更换了证书。网站每次续订证书时都应该无法访问吗？这似乎很笨拙。其次，公证人方法涉及带外检查，这违反了部署规则之一。第三，一个胆大的攻击者可能会广泛部署伪造证书，这将使公证人认为一切正常。最后，它引入了一个新的受信任的第三方。
DNSSEC
另一种替代方案是基于 DNSSEC（域名系统安全扩展）的信任。为此目的存在两种机制：DANE（基于 DNS 的命名实体认证；https://tools.ietf.org/html/rfc6698）和 CAA（证书颁发机构授权；https://tools.ietf.org/html/rfc6844）。严格来说，CAA 使 DNSSEC 成为可选但强烈推荐的。DANE 和 CAA 都以显而易见的方式将特定证书或 CA 与主机关联起来，方法是为主机名设置适当的 DNS 记录。区别在于记录的使用方式：DANE 记录由客户端在连接到服务器时检查；CAA 记录由 CA 在颁发证书时检查。如果 CA 未包含在新证书的 CAA 记录中，则应拒绝颁发。
这两个提案都存在 DNSSEC 固有的问题，但 CAA 还存在一个更深层次的问题，即未能真正解决部分问题——即被颠覆或恶意 CA 的错误签发。显然，他们根本不会费心查阅 CAA 记录。
但更重要的是，DNSSEC 与现有的 PKI（公钥基础设施）一样，将受信任的第三方引入等式，他们可能履行也可能不履行其职责。在这种情况下，受信任的第三方是 DNS 注册管理机构和注册商。可悲的是，他们的安全记录远不如 CA 那样令人印象深刻。
有些人认为，DNSSEC 对这些受信任的第三方的颠覆具有内在保护，因为 DNS 的公共性质使任何干预都立即可见。这个理论的问题在于，DNS 是一个分布式系统——我的视图不是你的视图，并且没有任何东西确保我们的两个视图是一致的。因此，攻击者相对容易呈现一个分裂的世界，向他们的受害者展示一组 DNS 记录，向那些寻求检查 DNS 完整性的人展示另一组 DNS 记录。
另一个问题仅仅是 DNSSEC 至今尚未广泛部署，因此我们将一个改进措施建立在另一个改进措施之上，而我们已经为此等待了十多年（实际上，早在八年前，我就忙于修复 DNSSEC 中的“最后”一个问题 [请参阅 RFC 5155 http://tools.ietf.org/html/rfc5155]）。
最后，实验表明，由于路由器接管 DNS 且不支持 DNSSEC，由于强制门户等原因，以及由于阻止 53 端口上的 TCP（DNS 通常通过 UDP 提供服务，但较大的记录需要回退到 TCP）以及其他原因，至少有百分之四的客户端根本无法获取 DNSSEC 记录。
但请注意，DANE 在 SMTP 的上下文中将非常有用。SMTP 服务器已经完全受制于 DNS，目前仅使用机会性 TLS（传输层安全协议）。DANE 肯定会是一个改进。
基于比特币的解决方案
我已经广泛撰写了关于比特币的问题（例如，它是有史以来最不环保的发明，如果它真正去中心化，但事实并非如此，那么它的所有历史都可能被足够强大的对手摧毁）。然而，人们继续在比特币的神坛上非理性地崇拜，这种崇拜延伸到 DNS 和密钥——例如，DNSChain（https://github.com/okTurtles/dnschain）。
除了成为一个极其昂贵的解决方案（就永久浪费能源而言），它还引入了新的受信任的第三方（那些在区块链中建立“共识”的人），并且没有验证机制。
证书透明度
所有这些替代方案的缺点使我们在 Google 寻求一种不同的方法，称为证书透明度。证书透明度背后的核心思想是公开、可验证、仅追加的日志。创建一个所有已签发证书的日志，该日志不需要被信任，因为它在密码学上是可验证的（并且事实证明这是可能的，稍后将更详细地解释），这允许客户端检查证书是否在日志中，服务器可以监控日志中是否有错误签发的证书。如果客户端拒绝连接到其证书未记录在日志中的网站，那么这是一个完整的解决方案。在不被检测到的情况下错误签发证书将变得不可能。
这种机制使我们能够满足前面列出的所有约束条件。存在迁移路径：证书继续像往常一样被签发和吊销，随着时间的推移，越来越多的客户端检查日志包含，越来越多的服务器监控日志。即使在所有客户端都检查之前，部分客户端的检查也会对剩余客户端产生群体免疫力。
每个人都可以参与。将证书添加到日志中并不难，而且由于日志本身不对证书的正确性做出判断，因此对错误证书的吊销没有任何改变，仍然由 CA 完成。
延迟不会增加，因为日志包含证明是紧凑的，并且包含在 TLS 握手中。
没有引入受信任的第三方。虽然日志确实是第三方，但它不受信任；任何人都可以检查其正确运行，如果它行为不端，可以证明它确实如此。
最后，证书透明度不会将决定推给用户。证书要么被记录，要么没有被记录。如果被记录，则相应的服务器运营商（或其他相关方）可以看到它，并在其无效时采取适当的措施。如果未被记录，则浏览器 simplemente 拒绝建立连接。
工作原理
如何构建可验证、仅追加的日志？事实证明，这在本质上相对简单，尽管存在一些设计权衡和一些有趣的问题需要克服。一种显而易见的方法是让日志的客户端简单地通过定期下载整个日志来验证它是否满足仅追加属性。客户端还可以将其日志副本与其他客户端的副本进行比较，以验证它们是否都看到相同的日志。然后每个人都会知道该日志确实是公开且仅追加的。
然而，这非常浪费带宽和存储空间。更好的方法是使用 Merkle 树，如图 1 所示。Merkle 树的叶子节点是日志中的条目。树中的每个分支都是分支下方节点的密码学哈希（这遵循了树向下生长的略微奇怪的约定；根节点在顶部，叶子节点在底部）。显然，从密码学哈希的属性来看，每个节点都是其下方所有节点的摘要：任何节点都不能被修改而不改变哈希值。因此，树的根节点是所有叶子节点的摘要。这意味着客户端现在可以通过简单地比较哈希值来有效地验证他们是否看到了相同的树。
然而，这并不是我们对日志的全部要求。我们希望验证声称在日志中的内容实际上在日志中，并且日志具有仅追加属性（或者换句话说，昨天的整个日志包含在今天的日志中）。幸运的是，Merkle 树是实现此目的的有效方法。要证明特定的叶子节点在日志中，只需要该叶子节点的哈希值和向上遍历树的相邻哈希列表。可以从此列表重新计算根节点，并且由于哈希是密码学哈希，这意味着叶子节点必须存在于树中（否则，将不可能生成一个哈希列表，该列表与叶子节点哈希结合以生成根节点哈希）。同样，昨天的根节点可以通过表示添加到树中的新条目的哈希列表链接到今天的根节点。
一个完整的系统还需要一个要素。如果日志行为不端，那么我们需要能够证明它确实如此。幸运的是，这又相当容易。日志只需要对事物进行签名。实际上，原则上，日志可以只签名一件事：树的根节点。这也是对树中包含的所有内容的签名。
这导致了第一个权衡。日志应该既高可用又一致。为了使 TLS 客户端确保证书实际上在日志中，每个证书都必须包含某种包含证明。（从技术上讲，证明可以来自与服务器对话中的任何位置，但由于推出新的服务器软件将需要多年时间，因此目前可以普遍部署的唯一选择是将证明直接包含在证书中。）
我们最初的想法是包含 Merkle 证明——即签名树头——以及从证书条目到签名头的哈希值。然而，这与可用性/一致性权衡发生了尖锐的冲突：为了使日志高度可用，您需要运行多个地理分布的实例。这意味着同步实例的过程可能需要一些时间，并且它们必须同步以实现仅追加属性。因此，在 CA 可以颁发证书之前，它必须首先将其提交到日志，并等待直到日志同步了其所有实例（以便为新证书分配日志中的位置）并返回新版本日志的 Merkle 证明。尽管这在大多数情况下可能非常快，但在面对网络和服务器中断时，可能需要相当长的时间——数小时甚至可能数天。
CA 发现其签发流程中的这种延迟是不可接受的。实际上，在权衡频谱上，甚至存在更慢的点——例如，日志可以返回包含证明和日志监控器不仅看到了新证书，而且有时间在新证书被错误签发时采取行动的证明。
幸运的是，在频谱上也有更快的点。最终实施的版本让日志服务器返回新证书的签名时间戳，称为 SCT（签名证书时间戳）。此签名时间戳是未来包含在日志中的承诺。每个日志都有一个 MMD（最大合并延迟）参数，该参数说明在颁发签名时间戳后，允许等待多长时间才进行包含。
从表面上看，这似乎允许日志立即响应，因为它需要做的只是生成签名，这个过程在现代硬件上只需不到一毫秒的时间。但这并不完全正确。由于 SCT 是包含证书的承诺，因此日志绝对不能在颁发 SCT 后丢失证书。因此，日志必须在其传入证书的存储中具有一定的冗余；证书可能应该存储在多个数据中心中。这确实允许放宽一致性要求。日志可以将传入证书存储在其冗余实例的某个子集中，并在决定新证书的顺序并生成新版本的日志之前解决任何不一致问题。这种冗余比一致性冗余快得多。
下一个权衡是 MMD。显然，那些监控日志的人希望 MMD 尽可能短，因为串通故意错误签发的日志可能会尽可能长时间地延迟记录。请注意，如果日志不串通或失去对其密钥的控制，则 CA（或 CA 的攻击者）无法影响日志集成新证书所花费的时间。另一方面，日志运营商需要 MMD 足够长，以允许日志建立一致的状态，甚至在面对软件错误时也是如此。我们仍在确定可接受的 MMD 是多少，但显然它必须至少为数小时，甚至可能长达几天。
第三个权衡是每个证书应记录在多少个日志中。支持使用更多日志有两个原因。首先，如果一个日志变坏，客户端将停止信任它。如果证书的所有 SCT 都来自坏日志，则该证书将不再有效。其次，证书中需要的 SCT 越多，攻击者就越难避免检测，因为攻击者必须同时控制 CA（或 CA 的密钥）和所有需要的日志（或它们的密钥）。
我们目前的想法是，每个证书应至少记录在两个日志中，并且随着证书生命周期的延长，日志数量会增加——对于生命周期超过 39 个月的证书，需要五个日志。减少日志数量的原因很简单：TLS 握手的大小增加；创建证书所需的时间增加（但请注意，在日志数量超过所需 SCT 数量的情况下，并行向所有日志发送请求并取前 n 个响应通常应该很快）；以及冗余日志记录导致的单个日志的大小和带宽需求增加。
最后，第四个权衡：应该允许什么进入日志？一个有吸引力的回答是“任何东西”，但只有当日志的大小可管理时，日志才有用。必须有人监视它们，如果它们变得如此之大以至于没有人可以切实可行地做到这一点，那么日志可能就不存在了。直接的答案是只允许可以链接到客户端识别的 CA 的证书。记录不满足此标准的证书可以说毫无意义，因为浏览器无论如何都不会接受它们。（如果自签名证书的有用性可以通过这种日志得到某种程度的加强，那将是很好的，但垃圾邮件问题，加上缺乏任何有效吊销自签名证书的方法，证明没有人找到这样做的方法；但是，请参阅本文末尾关于其他类型日志的讨论。）此外，即使浏览器接受它们，目前也没有可扩展的方法来吊销它们。
生态系统
只有当有人监视日志时，日志才有用，因此了解此生态系统中的参与者以及他们具体做什么非常重要。
首先，证书必须以某种方式进入日志。尽管这最初很可能主要由 CA 完成，但证书透明度标准也允许在 TLS 扩展中呈现 SCT。此选项需要修改后的服务器软件，但 Apache HTTPD 服务器已实验性地支持它。鉴于支持 TLS 扩展的软件，站点运营商可以自行进行日志记录，并且由于他们可以在他们认为合适的时候更新 SCT——这对于烘焙到证书中的 SCT 来说是不可能的——他们也可以使用更少的 SCT，并降低证书可能不被接受的风险。
其次，客户端必须检查他们看到的证书是否真的在日志中。由于不允许带外通信的要求，这意味着在呈现证书时信任日志，但稍后通过要求包含证明来验证其诚实性。
第三，相关方（站点运营商、CA 和研究人员等）需要监控日志，以确保 CA 没有做任何不当的事情——例如，为他们不应该使用的站点签发证书，或签发具有不应设置的扩展或标志的证书，或签发不符合标准的证书。监控还可以确保日志没有违反仅追加属性或违反其 MMD，或其他此类不当行为。
最后，每个与日志交互的人都应该相互核对他们是否都看到了相同的日志——即，日志没有向不同的人呈现不同的视图。这将使日志能够说服客户端它在一个视图中记录了证书，同时向他们声称用于的网站显示没有这些证书的视图。
流言
所有这些任务都很简单，除了最后一个。监控日志、获取一致性和包含证明等等可以通过直接查询日志来完成，但检查一致的视图更加困难。为了做到这一点，各种日志客户端将进行流言。从长远来看，这可能会通过各种协议发生——XMPP、SMTP、点对点连接等——但我们的第一个建议是在 TLS 上搭载流言。每当客户端连接到服务器时，它都会向服务器发送一些条目，服务器可以验证或仅缓存这些条目；作为回报，服务器会从其缓存中发回一些条目。这有效地建立了客户端之间的点对点网络。
由于此交换是搭载在为其他目的建立的连接上（大概是为了获取 Web 页面），因此应仅发送少量条目，以节省带宽并避免过度延迟。当专门为流言建立连接时（例如，直接连接到日志服务器或使用某些与其他客户端的点对点协议），则无需担心这一点，客户端和服务器可以选择发送大量条目——也许是他们知道的一切。
他们发送哪些条目？这是一个有待辩论（和模拟）的问题，但我们可以合理地确定最低要求是 STH（签名树头）。每个客户端都应该能够让自己确信它看到的日志与其他每个客户端看到的日志相同。日志由 STH 摘要，因此传播它们显然是客户端希望做的最起码的事情。
STH 对于传播具有一些不错的属性。首先，它们是签名的，因此恶意行为者无法将垃圾信息注入协议中。每个参与者都可以轻松拒绝并非源自日志的消息。其次，给定来自同一日志的两个 STH，可以证明它们之间的一致性，从而丢弃较旧的 STH。这意味着缓存的大小为 O（日志数）。
更多的传播是否可取？传播最近 STH 的 STH 一致性证明可能会很有用，从而减轻日志的负载。服务器可能还希望传播他们自己的 SCT 包含证明以及相应的 STH。
在撰写本文时，究竟传播什么以及何时传播是一个悬而未决的问题。正在通过模拟进行探索。
透明度的其他用途
证书透明度最初激发了我们在可验证日志方面所做的工作，但还有其他有用的应用
• 二进制透明度。 这允许您创建互联网上可下载应用程序的日志。与证书透明度一样，二进制透明度不能阻止二进制文件是恶意的，但它确实让用户确信他们获得的二进制文件对全世界可见以供分析，从而使目标恶意软件的部署更加困难。
• DNSSEC 透明度。DNSSEC 是基于 CA 的身份验证世界的有吸引力的替代方案，但它有其自身的潜在弱点列表——特别是域名注册管理机构和注册商。DNSSEC 中持有的密钥的透明度将确保可以监控这些密钥的正确运行。
• 吊销透明度。一旦识别出错误证书，就应该将其吊销。现有机制也允许在此过程中存在不诚实行为——例如，出于恶意目的选择性地将吊销状态设置为未吊销。
• ID 到密钥的映射。这可能包括，例如，电子邮件到 PGP（良好隐私密码法），或即时通讯 ID 到 OTR（离线）（请参阅 https://otr.cypherpunks.ca/）。
• 受信任的时间戳。存在数字公证人的协议，但它们目前需要信任公证人。记录所有时间戳的公证人将不需要被信任。
其他构造
在考虑撤销透明度时，我的同事 Emilia Käsper 和我发明了一个新的构造：稀疏 Merkle 树（http://www.links.org/files/RevocationTransparency.pdf）。这个想法是，如果你想要拥有一个可验证的映射，你可以将映射中的元素存储为非常大的 Merkle 树的叶子——例如，一个有 2256 个叶子的树（即 256 层深）。虽然这样的树通常不可能计算，但观察结果是大多数叶子是空的，这意味着大多数上一层将具有相同的值——两个空叶子的哈希值；对于更上一层也是如此，依此类推。这意味着，事实上，有可能计算树的根并进行包含证明等等，只要树是稀疏的。这种结构可以用作可验证日志的辅助手段，以提供高效、可验证的映射。
状态
证书透明度正在 Google 积极开发中。我们有两个日志在生产环境中运行，第三个计划在年底前完成。其他机构（例如，ISOC、Akamai 和各种 CA）也计划运行公共日志。我们拥有所有关键组件的开源实现。Chrome 支持证书透明度，并将于 2015 年 1 月起对 EV（扩展验证）证书强制执行。超过 94% 的 CA（按证书颁发量计算）已同意在其 EV 证书中包含 SCT。
一旦我们看到该系统在 EV 证书方面运行良好，我们计划为所有证书推广证书透明度。我们还打算探索可验证日志和映射的其他一些用途。
参考文献
1. Comodo Group. 2011 年 3 月 31 日更新； https://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html。
2. Langley, A. 2013。增强数字证书安全性。Google Online Security Blog； http://googleonlinesecurity.blogspot.de/2013/01/enhancing-digital-certificate-security.html。
3. Langley, A. 2013。进一步提高数字证书安全性。Google Online Security Blog； http://googleonlinesecurity.blogspot.co.uk/2013/12/further-improving-digital-certificate.html。
4. Laurie, B. 2011。提高 SSL 证书安全性。Google Online Security Blog； http://googleonlinesecurity.blogspot.co.uk/2011/04/improving-ssl-certificate-security.html。
喜欢它，讨厌它？请告诉我们
Ben Laurie 是一位软件工程师、协议设计师和密码学家。他是 Apache 软件基金会的创始董事、OpenSSL 的核心团队成员、Shmoo Group 的成员、开放权利组织的董事、The Bunker Secure Hosting 的安全总监、FreeBMD 的受托人和创始成员、剑桥大学计算机实验室的访问学者，以及 FreeBSD 的提交者。Laurie 在伦敦的 Google 工作，参与各种项目，目前专注于证书透明度。
© 2014 1542-7730/14/0800 $10.00
最初发表于 Queue 杂志第 12 卷第 8 期—
在 数字图书馆 中评论这篇文章
更多相关文章
Paul Vixie - 要么静态，要么回家
当前和历史上计算机与网络安全中的大多数问题都可以归结为一个简单的观察：让其他人控制我们的设备对我们不利。在另一个时间，我将解释我所说的“其他人”和“不利”是什么意思。就本文而言，我将完全专注于我所说的控制是什么意思。我们失去对设备控制的一种方式是外部分布式拒绝服务 (DDoS) 攻击，这种攻击用不需要的流量填充网络，不给真实（“需要的”）流量留下空间。其他形式的 DDoS 类似：例如，低轨道离子炮 (LOIC) 的攻击可能不会完全填满网络，但它可以使 Web 服务器忙于应答无用的攻击请求，以至于服务器无法应答任何有用的客户请求。
Axel Arnbak、Hadi Asghari、Michel Van Eeten、Nico Van Eijk - HTTPS 市场中的安全崩溃
HTTPS（超文本传输协议安全）已发展成为安全 Web 浏览的事实标准。通过基于证书的身份验证协议，Web 服务和 Internet 用户首先使用 TLS/SSL 证书相互验证身份（“握手”），端到端加密 Web 通信，并在浏览器中显示挂锁，以指示通信是安全的。近年来，HTTPS 已成为保护在线社会、政治和经济活动的重要技术。
Sharon Goldberg - 为什么保护互联网路由需要这么长时间？
BGP（边界网关协议）是将互联网粘合在一起的粘合剂，它使不同组织运营的大型网络之间能够进行数据通信。BGP 通过为组织之间的流量设置路由来使互联网通信全球化——例如，从波士顿大学的网络，通过更大的 ISP（互联网服务提供商），如 Level3、巴基斯坦电信和中国电信，然后到住宅网络，如 Comcast 或企业网络，如美国银行。
Christoph Kern - 保护错综复杂的网络
脚本注入漏洞是 Web 应用程序开发的一个祸根：原因和补救方法看似简单，但在大规模 Web 开发中却出奇地难以预防。
© 保留所有权利。