Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 8164
Category: Experimental M. Thomson
ISSN: 2070-1721 Mozilla
May 2017
Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 8164
Category: Experimental M. Thomson
ISSN: 2070-1721 Mozilla
May 2017
Opportunistic Security for HTTP/2
HTTP/2的机会主义安全
Abstract
摘要
This document describes how "http" URIs can be accessed using Transport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks. This mechanism not a replacement for "https" URIs; it is vulnerable to active attacks.
本文档描述了如何使用传输层安全性（TLS）和http/2访问“http”URI，以减轻普遍的监视攻击。该机制不能替代“https”URI；它容易受到主动攻击。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8164.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8164.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Goals and Non-goals ........................................3
1.2. Notational Conventions .....................................3
2. Using HTTP URIs over TLS ........................................3
2.1. Alternative Server Opt-In ..................................4
2.2. Interaction with "https" URIs ..............................5
2.3. The "http-opportunistic" Well-Known URI ....................5
3. IANA Considerations .............................................6
4. Security Considerations .........................................7
4.1. Security Indicators ........................................7
4.2. Downgrade Attacks ..........................................7
4.3. Privacy Considerations .....................................7
4.4. Confusion regarding Request Scheme .........................7
4.5. Server Controls ............................................8
5. References ......................................................8
5.1. Normative References .......................................8
5.2. Informative References .....................................9
Acknowledgements ...................................................9
Authors' Addresses ................................................10
1. Introduction ....................................................2
1.1. Goals and Non-goals ........................................3
1.2. Notational Conventions .....................................3
2. Using HTTP URIs over TLS ........................................3
2.1. Alternative Server Opt-In ..................................4
2.2. Interaction with "https" URIs ..............................5
2.3. The "http-opportunistic" Well-Known URI ....................5
3. IANA Considerations .............................................6
4. Security Considerations .........................................7
4.1. Security Indicators ........................................7
4.2. Downgrade Attacks ..........................................7
4.3. Privacy Considerations .....................................7
4.4. Confusion regarding Request Scheme .........................7
4.5. Server Controls ............................................8
5. References ......................................................8
5.1. Normative References .......................................8
5.2. Informative References .....................................9
Acknowledgements ...................................................9
Authors' Addresses ................................................10
This document describes a use of HTTP Alternative Services [RFC7838] to decouple the URI scheme from the use and configuration of underlying encryption. It allows an "http" URI [RFC7230] to be accessed using HTTP/2 and Transport Layer Security (TLS) [RFC5246] with Opportunistic Security [RFC7435].
本文档描述了使用HTTP替代服务[RFC7838]将URI方案与底层加密的使用和配置分离。它允许使用http/2和传输层安全（TLS）[RFC5246]以及机会安全[RFC7435]访问“http”URI[RFC7230]。
This document describes a usage model whereby sites can serve "http" URIs over TLS, thereby avoiding the problem of serving Mixed Content (described in [W3C.CR-mixed-content-20160802]) while still providing protection against passive attacks.
本文档描述了一种使用模型，通过该模型，站点可以通过TLS为“http”URI提供服务，从而避免了服务混合内容（如[W3C.CR-Mixed-Content-20160802]所述）的问题，同时还提供了针对被动攻击的保护。
Opportunistic Security does not provide the same guarantees as using TLS with "https" URIs, because it is vulnerable to active attacks, and does not change the security context of the connection. Normally, users will not be able to tell that it is in use (i.e., there will be no "lock icon").
机会主义安全不提供与使用带有“https”URI的TLS相同的保证，因为它容易受到主动攻击，并且不会更改连接的安全上下文。通常情况下，用户无法判断它正在使用中（即，没有“锁定图标”）。
The immediate goal is to make the use of HTTP more robust in the face of pervasive passive monitoring [RFC7258].
当前的目标是使HTTP的使用在面对普遍的被动监视时更加健壮[RFC7258]。
A secondary (but significant) goal is to provide for ease of implementation, deployment, and operation. This mechanism is expected to have a minimal impact upon performance and require trivial administrative effort to configure.
第二个（但重要的）目标是提供易于实现、部署和操作的功能。该机制预计对性能的影响最小，并且需要简单的管理工作来配置。
Preventing active attacks (such as man-in-the-middle attacks) is a non-goal for this specification. Furthermore, this specification is not intended to replace or offer an alternative to "https", since "https" both prevents active attacks and invokes a more stringent security model in most clients.
防止主动攻击（如中间人攻击）不是本规范的目标。此外，本规范无意取代或提供“https”的替代方案，因为“https”既可以防止主动攻击，又可以在大多数客户端中调用更严格的安全模型。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
An origin server that supports the resolution of "http" URIs can indicate support for this specification by providing an alternative service advertisement [RFC7838] for a protocol identifier that uses TLS, such as "h2" [RFC7540]. Such a protocol MUST include an explicit indication of the scheme of the resource. This excludes HTTP/1.1; HTTP/1.1 clients are forbidden from including the absolute form of a URI in requests to origin servers (see Section 5.3.1 of [RFC7230]).
支持“http”URI解析的源服务器可以通过为使用TLS的协议标识符（如“h2”[RFC7540]）提供替代服务公告[RFC7838]来指示对此规范的支持。这样的协议必须包括资源方案的明确指示。这不包括HTTP/1.1；禁止HTTP/1.1客户端在对源服务器的请求中包含绝对形式的URI（请参见[RFC7230]第5.3.1节）。
A client that receives such an advertisement MAY make future requests intended for the associated origin [RFC6454] to the identified service (as specified by [RFC7838]), provided that the alternative service opts in as described in Section 2.1.
接收到此类广告的客户可以向标识的服务（按照[RFC7838]的规定）发出未来的相关来源[RFC6454]请求，前提是替代服务选择第2.1节中所述的服务。
A client that places the importance of protection against passive attacks over performance might choose to withhold requests until an encrypted connection is available. However, if such a connection cannot be successfully established, the client can resume its use of the cleartext connection.
将被动攻击防护置于性能之上的客户端可能会选择在加密连接可用之前保留请求。但是，如果无法成功建立这样的连接，客户端可以继续使用明文连接。
A client can also explicitly probe for an alternative service advertisement by sending a request that bears little or no sensitive information, such as one with the OPTIONS method. Likewise, clients with existing alternative services information could make such a request before they expire, in order minimize the delays that might be incurred.
客户机还可以通过发送几乎不包含敏感信息的请求（例如带有OPTIONS方法的请求），显式地探测替代服务广告。同样，拥有现有替代服务信息的客户机可以在过期之前发出这样的请求，以最大限度地减少可能发生的延迟。
Client certificates are not meaningful for URLs with the "http" scheme; therefore, clients creating new TLS connections to alternative services for the purposes of this specification MUST NOT present them. A server that also provides "https" resources on the same port can request a certificate during the TLS handshake, but it MUST NOT abort the handshake if the client does not provide one.
客户端证书对于使用“http”方案的URL没有意义；因此，出于本规范的目的，创建到替代服务的新TLS连接的客户端不得提供这些连接。在同一端口上也提供“https”资源的服务器可以在TLS握手期间请求证书，但如果客户端不提供证书，则不能中止握手。
For various reasons, it is possible that the server might become confused about whether requests' URLs have an "http" or "https" scheme (see Section 4.4). To ensure that the alternative service has opted into serving "http" URLs over TLS, clients are required to perform additional checks before directing "http" requests to it.
出于各种原因，服务器可能会对请求的URL是否具有“http”或“https”方案感到困惑（请参阅第4.4节）。为了确保替代服务选择通过TLS提供“http”URL，客户机需要在将“http”请求定向到它之前执行额外的检查。
Clients MUST NOT send "http" requests over a secured connection, unless the chosen alternative service presents a certificate that is valid for the origin as defined in [RFC2818]. Using an authenticated alternative service establishes "reasonable assurances" for the purposes of [RFC7838]. In addition to authenticating the server, the client MUST have obtained a valid "http-opportunistic" response for an origin (as per Section 2.3) using the authenticated connection. An exception to the latter restriction is made for requests for the "http-opportunistic" well-known URI.
客户端不得通过安全连接发送“http”请求，除非所选的替代服务提供的证书对[RFC2818]中定义的源站有效。出于[RFC7838]的目的，使用经验证的替代服务建立“合理保证”。除了对服务器进行身份验证外，客户端还必须使用经过身份验证的连接获得源站的有效“http机会主义”响应（根据第2.3节）。对于“http机会主义”众所周知的URI的请求，对后一个限制有一个例外。
For example, assuming the following request is made over a TLS connection that is successfully authenticated for those origins, the following request/response pair would allow requests for the origins "http://www.example.com" or "http://example.com" to be sent using a secured connection:
例如，假设以下请求是通过已成功验证这些源的TLS连接发出的，则以下请求/响应对将允许对这些源的请求“http://www.example.com“或”http://example.com“要使用安全连接发送：
HEADERS
+ END_STREAM
+ END_HEADERS
:method = GET
:scheme = http
:authority = example.com
:path = /.well-known/http-opportunistic
HEADERS
+ END_STREAM
+ END_HEADERS
:method = GET
:scheme = http
:authority = example.com
:path = /.well-known/http-opportunistic
HEADERS
:status = 200
content-type = application/json
DATA
+ END_STREAM
[ "http://www.example.com", "http://example.com" ]
HEADERS
:status = 200
content-type = application/json
DATA
+ END_STREAM
[ "http://www.example.com", "http://example.com" ]
This document describes multiple origins, but only for operational convenience. Only a request made to an origin (over an authenticated connection) can be used to acquire the "http-opportunistic" resource for that origin. Thus, in the example, the request to "http://example.com" cannot be assumed to also provide a representation of the "http-opportunistic" resource for "http://www.example.com".
本文件描述了多个来源，但仅为操作方便。只有向源站发出的请求（通过经过身份验证的连接）才能用于获取该源站的“http机会主义”资源。因此，在本例中，请求“http://example.com不能假定也为提供“http机会主义”资源的表示形式http://www.example.com".
Clients MUST NOT send "http" and "https" requests on the same connection. Similarly, clients MUST NOT send "http" requests for multiple origins on the same connection.
客户端不得在同一连接上发送“http”和“https”请求。同样，客户端不得在同一连接上发送多个源的“http”请求。
This specification defines the "http-opportunistic" well-known URI [RFC5785]. A client is said to have a valid "http-opportunistic" response for a given origin when:
本规范定义了众所周知的“http机会主义”URI[RFC5785]。在以下情况下，客户端被称为对给定源具有有效的“http机会主义”响应：
o The client has requested the well-known URI from the origin over an authenticated connection and a 200 (OK) response was provided,
o 客户端已通过经过身份验证的连接从源站请求已知URI，并提供了200（OK）响应，
o That response is fresh [RFC7234] (potentially through revalidation [RFC7232]),
o 该响应是新的[RFC7234]（可能通过重新验证[RFC7232]），
o That response has the media type "application/json",
o 该响应的媒体类型为“application/json”，
o That response's payload, when parsed as JSON [RFC7159], contains an array as the root, and
o 当解析为JSON[RFC7159]时，该响应的有效负载包含一个作为根的数组，并且
o The array contains a string that is a case-insensitive, character-for-character match for the origin in question, serialized into Unicode as per Section 6.1 of [RFC6454].
o 该数组包含一个字符串，该字符串不区分大小写，与所讨论的源代码逐字符匹配，并按照[RFC6454]第6.1节序列化为Unicode。
A client MAY treat an "http-opportunistic" resource as invalid if values it contains are not strings.
如果“http机会主义”资源包含的值不是字符串，则客户端可能会将其视为无效资源。
This document does not define semantics for "http-opportunistic" resources on an "https" origin, nor does it define semantics if the resource includes "https" origins.
本文档没有定义“https”源上的“http机会主义”资源的语义，如果资源包含“https”源，也没有定义语义。
Allowing clients to cache the "http-opportunistic" resource means that all alternative services need to be able to respond to requests for "http" resources. A client is permitted to use an alternative service without acquiring the "http-opportunistic" resource from that service.
允许客户端缓存“http机会主义”资源意味着所有替代服务都需要能够响应“http”资源的请求。允许客户端使用替代服务，而无需从该服务获取“http机会主义”资源。
A client MUST NOT use any cached copies of an "http-opportunistic" resource that was acquired (or revalidated) over an unauthenticated connection. To avoid potential errors, a client can request or revalidate the "http-opportunistic" resource before using any connection to an alternative service.
客户端不得使用通过未经身份验证的连接获取（或重新验证）的“http机会主义”资源的任何缓存副本。为了避免潜在的错误，客户端可以在使用任何到替代服务的连接之前请求或重新验证“http机会主义”资源。
Clients that use cached "http-opportunistic" responses MUST ensure that their cache is cleared of any responses that were acquired over an unauthenticated connection. Revalidating an unauthenticated response using an authenticated connection does not ensure the integrity of the response.
使用缓存的“http机会主义”响应的客户端必须确保清除其缓存中通过未经验证的连接获取的任何响应。使用经过身份验证的连接重新验证未经身份验证的响应并不能确保响应的完整性。
This specification registers the following well-known URI [RFC5785]:
本规范注册了以下众所周知的URI[RFC5785]：
o URI Suffix: http-opportunistic
o URI后缀：http机会主义
o Change Controller: IETF
o 更改控制器：IETF
o Specification Document(s): Section 2.3 of RFC 8164
o 规范文件：RFC 8164第2.3节
o Related Information:
o 有关资料：
User agents MUST NOT provide any special security indicators when an "http" resource is acquired using TLS. In particular, indicators that might suggest the same level of security as "https" MUST NOT be used (e.g., a "lock device").
当使用TLS获取“http”资源时，用户代理不得提供任何特殊的安全指示器。特别是，不得使用可能表明与“https”具有相同安全级别的指示器（例如，“锁定设备”）。
A downgrade attack against the negotiation for TLS is possible.
针对TLS协商的降级攻击是可能的。
For example, because the "Alt-Svc" header field [RFC7838] likely appears in an unauthenticated and unencrypted channel, it is subject to downgrade by network attackers. In its simplest form, an attacker that wants the connection to remain in the clear need only strip the "Alt-Svc" header field from responses.
例如，由于“Alt Svc”标题字段[RFC7838]可能出现在未经验证且未加密的通道中，因此网络攻击者会将其降级。在最简单的形式中，希望连接保持在清除状态的攻击者只需从响应中删除“Alt Svc”头字段。
Cached alternative services can be used to track clients over time, e.g., using a user-specific hostname. Clearing the cache reduces the ability of servers to track clients; therefore, clients MUST clear cached alternative service information when clearing other origin-based state (i.e., cookies).
缓存的替代服务可用于随时间跟踪客户端，例如，使用特定于用户的主机名。清除缓存会降低服务器跟踪客户端的能力；因此，在清除其他基于源的状态（即cookie）时，客户端必须清除缓存的备用服务信息。
HTTP implementations and applications sometimes use ambient signals to determine if a request is for an "https" resource; for example, they might look for TLS on the stack or a server port number of 443.
HTTP实现和应用程序有时使用环境信号来确定请求是否为“https”资源；例如，他们可能会在堆栈上查找TLS或服务器端口号443。
This might be due to expected limitations in the protocol (the most common HTTP/1.1 request form does not carry an explicit indication of the URI scheme, and the resource might have been developed assuming HTTP/1.1), or it may be because of how the server and application are implemented (often, they are two separate entities, with a variety of possible interfaces between them).
这可能是由于协议中的预期限制（最常见的HTTP/1.1请求表单没有明确的URI模式指示，并且资源可能是采用HTTP/1.1开发的），也可能是因为服务器和应用程序是如何实现的（通常，它们是两个独立的实体，它们之间有各种可能的接口）。
Any security decisions based upon this information could be misled by the deployment of this specification, because it violates the assumption that the use of TLS (or port 443) means that the client is accessing an HTTPS URI and operating in the security context implied by HTTPS.
基于此信息的任何安全决策都可能被此规范的部署所误导，因为它违反了使用TLS（或端口443）意味着客户端正在访问HTTPS URI并在HTTPS隐含的安全上下文中操作的假设。
Therefore, server implementers and administrators need to carefully examine the use of such signals before deploying this specification.
因此，服务器实现者和管理员需要在部署此规范之前仔细检查这些信号的使用情况。
This specification requires that a server send both an alternative service advertisement and host content in a well-known location to send HTTP requests over TLS. Servers SHOULD take suitable measures to ensure that the content of the well-known resource remains under their control. Likewise, because the "Alt-Svc" header field is used to describe policies across an entire origin, servers SHOULD NOT permit user content to set or modify the value of this header.
此规范要求服务器在已知位置发送备用服务广告和主机内容，以通过TLS发送HTTP请求。服务器应采取适当措施，确保已知资源的内容仍在其控制之下。同样，由于“Alt Svc”标头字段用于描述整个源站的策略，因此服务器不应允许用户内容设置或修改此标头的值。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <http://www.rfc-editor.org/info/rfc5785>.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，DOI 10.17487/RFC5785，2010年4月<http://www.rfc-editor.org/info/rfc5785>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.
[RFC6454]Barth，A.，“网络起源概念”，RFC 6454，DOI 10.17487/RFC6454，2011年12月<http://www.rfc-editor.org/info/rfc6454>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：有条件请求”，RFC 7232，DOI 10.17487/RFC72322014年6月<http://www.rfc-editor.org/info/rfc7232>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<http://www.rfc-editor.org/info/rfc7234>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本2（HTTP/2）”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<http://www.rfc-editor.org/info/rfc7540>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, <http://www.rfc-editor.org/info/rfc7838>.
[RFC7838]诺丁汉，M.，McManus，P.，和J.Reschke，“HTTP替代服务”，RFC 7838，DOI 10.17487/RFC7838，2016年4月<http://www.rfc-editor.org/info/rfc7838>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<http://www.rfc-editor.org/info/rfc7435>.
[W3C.CR-mixed-content-20160802] West, M., "Mixed Content", World Wide Web Consortium CR CR-mixed-content-20160802, August 2016, <https://www.w3.org/TR/2016/CR-mixed-content-20160802>.
[W3C.CR-mixed-content-20160802]West，M.，“混合内容”，万维网联盟CR-mixed-content-20160802，2016年8月<https://www.w3.org/TR/2016/CR-mixed-content-20160802>.
Acknowledgements
致谢
Mike Bishop contributed significant text to this document.
Mike Bishop为本文件提供了重要文本。
Thanks to Patrick McManus, Stefan Eissing, Eliot Lear, Stephen Farrell, Guy Podjarny, Stephen Ludin, Erik Nygren, Paul Hoffman, Adam Langley, Eric Rescorla, Julian Reschke, Kari Hurtta, and Richard Barnes for their feedback and suggestions.
感谢Patrick McManus、Stefan Eissing、Eliot Lear、Stephen Farrell、Guy Podjarny、Stephen Ludin、Erik Nygren、Paul Hoffman、Adam Langley、Eric Rescorla、Julian Reschke、Kari Hurta和Richard Barnes的反馈和建议。
Authors' Addresses
作者地址
Mark Nottingham
马克诺丁汉
Email: mnot@mnot.net
URI: https://www.mnot.net/
Email: mnot@mnot.net
URI: https://www.mnot.net/
Martin Thomson Mozilla
马丁·汤姆森·莫齐拉
Email: martin.thomson@gmail.com
Email: martin.thomson@gmail.com