[要約] RFC 2817は、HTTP/1.1内でTLSへのアップグレードを可能にするための仕様です。目的は、既存のHTTP接続を安全なTLS接続にアップグレードすることで、セキュリティを向上させることです。
Network Working Group R. Khare
Request for Comments: 2817 4K Associates / UC Irvine
Updates: 2616 S. Lawrence
Category: Standards Track Agranat Systems, Inc.
May 2000
Upgrading to TLS Within HTTP/1.1
HTTP/1.1内のTLSへのアップグレード
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP + TLS server can disambiguate traffic intended for several hostnames at a single IP address.
このメモは、http/1.1でアップグレードメカニズムを使用して、既存のTCP接続で輸送層セキュリティ（TLS）を開始する方法を説明しています。これにより、無担保および保護されたHTTPトラフィックが同じよく知られているポートを共有できます（この場合、HTTP：HTTPS：443で80）。また、「仮想ホスティング」を有効にするため、単一のHTTP TLSサーバーは、単一のIPアドレスで複数のホスト名を意図したトラフィックを乱用できます。
Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to-end tunnels across HTTP proxies. Finally, this memo establishes new IANA registries for public HTTP status codes, as well as public or private Upgrade product tokens.
HTTP/1.1 [1]はアップグレードをホップバイホップメカニズムとして定義するため、このメモは、HTTPプロキシ全体にエンドツーエンドのトンネルを確立するためのHTTP Connectメソッドも文書化しています。最後に、このメモは、パブリックHTTPステータスコードの新しいIANAレジストリと、パブリックまたはプライベートアップグレード製品トークンを確立します。
This memo does NOT affect the current definition of the 'https' URI scheme, which already defines a separate namespace (http://example.org/ and https://example.org/ are not equivalent).
このメモは、「https」URIスキームの現在の定義には影響しません。これは、既に個別の名前空間（http://example.org/およびhttps://example.org/を定義しています。
Table of Contents
目次
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . 4
3. Client Requested Upgrade to HTTP over TLS . . . . . . . . . . 4
3.1 Optional Upgrade . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Mandatory Upgrade . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . . 4
4. Server Requested Upgrade to HTTP over TLS . . . . . . . . . . 5
4.1 Optional Advertisement . . . . . . . . . . . . . . . . . . . . 5
4.2 Mandatory Advertisement . . . . . . . . . . . . . . . . . . . 5
5. Upgrade across Proxies . . . . . . . . . . . . . . . . . . . . 6
5.1 Implications of Hop By Hop Upgrade . . . . . . . . . . . . . . 6
5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . . 6
5.3 Establishing a Tunnel with CONNECT . . . . . . . . . . . . . . 7
6. Rationale for the use of a 4xx (client error) Status Code . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7.1 HTTP Status Code Registry . . . . . . . . . . . . . . . . . . 8
7.2 HTTP Upgrade Token Registry . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1 Implications for the https: URI Scheme . . . . . . . . . . . . 10
8.2 Security Considerations for CONNECT . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
The historical practice of deploying HTTP over SSL3 [3] has distinguished the combination from HTTP alone by a unique URI scheme and the TCP port number. The scheme 'http' meant the HTTP protocol alone on port 80, while 'https' meant the HTTP protocol over SSL on port 443. Parallel well-known port numbers have similarly been requested -- and in some cases, granted -- to distinguish between secured and unsecured use of other application protocols (e.g. snews, ftps). This approach effectively halves the number of available well known ports.
SSL3 [3]を介してHTTPを展開する歴史的実践は、一意のURIスキームとTCPポート番号によって、HTTPのみと組み合わせを区別しています。スキーム「HTTP」は、ポート80のHTTPプロトコルのみを意味し、「HTTPS」はポート443のSSL上のHTTPプロトコルを意味しました。他のアプリケーションプロトコルの保護されていない使用と無担保の使用の間（例：Snews、FTPS）。このアプローチは、利用可能なよく知られているポートの数を効果的に半分にします。
At the Washington DC IETF meeting in December 1997, the Applications Area Directors and the IESG reaffirmed that the practice of issuing parallel "secure" port numbers should be deprecated. The HTTP/1.1 Upgrade mechanism can apply Transport Layer Security [6] to an open HTTP connection.
1997年12月のワシントンDC IETF会議で、Applications Areas Erage DirectorsとIESGは、並行する「安全な」ポート番号を発行する慣行を非推奨する必要があることを再確認しました。HTTP/1.1アップグレードメカニズムは、輸送層のセキュリティ[6]をオープンHTTP接続に適用できます。
In the nearly two years since, there has been broad acceptance of the concept behind this proposal, but little interest in implementing alternatives to port 443 for generic Web browsing. In fact, nothing in this memo affects the current interpretation of https: URIs. However, new application protocols built atop HTTP, such as the Internet Printing Protocol [7], call for just such a mechanism in order to move ahead in the IETF standards process.
それからほぼ2年間で、この提案の背後にある概念に幅広く受け入れられてきましたが、ジェネリックWebブラウジングのためにポート443の代替案を実装することにはほとんど関心がありません。実際、このメモの何も、HTTPSの現在の解釈に影響を与えません：uris。ただし、インターネット印刷プロトコル[7]など、HTTPの上に構築された新しいアプリケーションプロトコルは、IETF標準プロセスを進めるために、まさにそのようなメカニズムを求めています。
The Upgrade mechanism also solves the "virtual hosting" problem. Rather than allocating multiple IP addresses to a single host, an HTTP/1.1 server will use the Host: header to disambiguate the intended web service. As HTTP/1.1 usage has grown more prevalent, more ISPs are offering name-based virtual hosting, thus delaying IP address space exhaustion.
アップグレードメカニズムは、「仮想ホスティング」問題も解決します。HTTP/1.1サーバーは、複数のIPアドレスを単一のホストに割り当てるのではなく、ホスト：ヘッダーを使用して意図したWebサービスを乱用します。HTTP/1.1の使用がより一般的になったため、より多くのISPが名前ベースの仮想ホスティングを提供しているため、IPアドレススペースの疲労が遅れています。
TLS (and SSL) have been hobbled by the same limitation as earlier versions of HTTP: the initial handshake does not specify the intended hostname, relying exclusively on the IP address. Using a cleartext HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the certificates based on the initial Host: header -- will allow ISPs to provide secure name-based virtual hosting as well.
TLS（およびSSL）は、HTTPの以前のバージョンと同じ制限に悩まされています。最初のハンドシェイクは、IPアドレスのみに依存する意図したホスト名を指定していません。ClearText HTTP/1.1アップグレードを使用：TLSハンドシェイクへのプリアンブル - 最初のホストに基づいて証明書を選択すると、ISPは安全な名前ベースの仮想ホスティングを提供できます。
TLS, a.k.a., SSL (Secure Sockets Layer), establishes a private end-to-end connection, optionally including strong mutual authentication, using a variety of cryptosystems. Initially, a handshake phase uses three subprotocols to set up a record layer, authenticate endpoints, set parameters, as well as report errors. Then, there is an ongoing layered record protocol that handles encryption, compression, and reassembly for the remainder of the connection. The latter is intended to be completely transparent. For example, there is no dependency between TLS's record markers and or certificates and HTTP/1.1's chunked encoding or authentication.
TLS、別名、SSL（セキュアソケット層）は、さまざまな暗号システムを使用して、オプションで強力な相互認証を含むプライベートエンドツーエンド接続を確立します。当初、握手フェーズでは、3つのサブプロトコルを使用して、レコードレイヤー、エンドポイントの認証、設定パラメーター、およびレポートエラーをセットアップします。次に、接続の残りのために暗号化、圧縮、および再組み立てを処理する継続的な層状レコードプロトコルがあります。後者は完全に透明であることを目的としています。たとえば、TLSのレコードマーカーとまたは証明書とHTTP/1.1のチャンクされたエンコードまたは認証の間に依存関係はありません。
Either the client or server can use the HTTP/1.1 [1] Upgrade mechanism (Section 14.42) to indicate that a TLS-secured connection is desired or necessary. This memo defines the "TLS/1.0" Upgrade token, and a new HTTP Status Code, "426 Upgrade Required".
クライアントまたはサーバーのいずれかがHTTP/1.1 [1]アップグレードメカニズム（セクション14.42）を使用して、TLSセセルスされた接続が望ましいか必要であることを示します。このメモは、「TLS/1.0」アップグレードトークンと、新しいHTTPステータスコード「426アップグレードが必要」を定義します。
Section 3 and Section 4 describe the operation of a directly connected client and server. Intermediate proxies must establish an end-to-end tunnel before applying those operations, as explained in Section 5.
セクション3とセクション4は、直接接続されたクライアントとサーバーの操作について説明します。中間プロキシは、セクション5で説明されているように、それらの操作を適用する前にエンドツーエンドトンネルを確立する必要があります。
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in RFC 2119 [11].
キーワード「必須」、「「必須」、「必須」、「は」、「ははは」、「そうではない」、「可能性はありません」このドキュメントに表示されることは、RFC 2119 [11]で説明されているように解釈されます。
When the client sends an HTTP/1.1 request with an Upgrade header field containing the token "TLS/1.0", it is requesting the server to complete the current HTTP/1.1 request after switching to TLS/1.0.
クライアントがトークン「TLS/1.0」を含むアップグレードヘッダーフィールドを使用してHTTP/1.1要求を送信すると、TLS/1.0に切り替えた後、現在のHTTP/1.1要求を完了するようサーバーに要求しています。
A client MAY offer to switch to secured operation during any clear HTTP request when an unsecured response would be acceptable:
クライアントは、無担保の応答が受け入れられる場合、明確なHTTP要求中に保護された操作に切り替えることを申し出ることができます。
GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1 Host: example.bank.com Upgrade: TLS/1.0 Connection: Upgrade
get http://example.bank.com/acct_stat.html?749394889300 http/1.1 host：emple.bank.comアップグレード：TLS/1.0接続：アップグレード
In this case, the server MAY respond to the clear HTTP operation normally, OR switch to secured operation (as detailed in the next section).
この場合、サーバーは正常にクリアなHTTP操作に応答するか、保護された操作に切り替えることができます（次のセクションで詳述されています）。
Note that HTTP/1.1 [1] specifies "the upgrade keyword MUST be supplied within a Connection header field (section 14.10) whenever Upgrade is present in an HTTP/1.1 message".
HTTP/1.1 [1]は、アップグレードがHTTP/1.1メッセージに存在する場合は、接続ヘッダーフィールド（セクション14.10）内で「アップグレードキーワードを提供する必要がある」と指定することに注意してください。
If an unsecured response would be unacceptable, a client MUST send an OPTIONS request first to complete the switch to TLS/1.0 (if possible).
無担保の応答が容認できない場合、クライアントは最初にオプションリクエストを送信して、TLS/1.0にスイッチを完了する必要があります（可能であれば）。
OPTIONS * HTTP/1.1 Host: example.bank.com Upgrade: TLS/1.0 Connection: Upgrade
オプション * http/1.1ホスト：example.bank.comアップグレード：TLS/1.0接続：アップグレード
As specified in HTTP/1.1 [1], if the server is prepared to initiate the TLS handshake, it MUST send the intermediate "101 Switching Protocol" and MUST include an Upgrade response header specifying the tokens of the protocol stack it is switching to:
HTTP/1.1 [1]で指定されているように、サーバーがTLSハンドシェイクを開始する準備ができている場合、中間体「101スイッチングプロトコル」を送信する必要があり、プロトコルスタックのトークンを指定するアップグレード応答ヘッダーを含める必要があります。
HTTP/1.1 101 Switching Protocols Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade
HTTP/1.1 101スイッチングプロトコルアップグレード：TLS/1.0、HTTP/1.1接続：アップグレード
Note that the protocol tokens listed in the Upgrade header of a 101 Switching Protocols response specify an ordered 'bottom-up' stack.
101スイッチングプロトコル応答のアップグレードヘッダーにリストされているプロトコルトークンは、順序付けられた「ボトムアップ」スタックを指定することに注意してください。
As specified in HTTP/1.1 [1], Section 10.1.2: "The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response".
HTTP/1.1 [1]で指定されているように、セクション10.1.2：「サーバーは、101の応答を終了する空の行の直後に、応答のアップグレードヘッダーフィールドによって定義されたものにプロトコルを切り替えます」。
Once the TLS handshake completes successfully, the server MUST continue with the response to the original request. Any TLS handshake failure MUST lead to disconnection, per the TLS error alert specification.
TLSハンドシェイクが正常に完了すると、サーバーは元のリクエストへの応答を継続する必要があります。TLSエラーアラート仕様に従って、TLSの握手の故障が切断される必要があります。
The Upgrade response header field advertises possible protocol upgrades a server MAY accept. In conjunction with the "426 Upgrade Required" status code, a server can advertise the exact protocol upgrade(s) that a client MUST accept to complete the request.
アップグレード応答ヘッダーフィールドは、サーバーが受け入れる可能性のあるプロトコルの可能なアップグレードを宣伝します。「426アップグレードが必要」ステータスコードと併せて、サーバーはクライアントがリクエストを完了するために受け入れる必要がある正確なプロトコルアップグレードを宣伝できます。
As specified in HTTP/1.1 [1], the server MAY include an Upgrade header in any response other than 101 or 426 to indicate a willingness to switch to any (combination) of the protocols listed.
HTTP/1.1 [1]で指定されているように、サーバーには、リストされているプロトコルの（組み合わせ）に切り替える意欲を示すために、101または426以外の応答にアップグレードヘッダーを含めることができます。
A server MAY indicate that a client request can not be completed without TLS using the "426 Upgrade Required" status code, which MUST include an an Upgrade header field specifying the token of the required TLS version.
サーバーは、「426アップグレード必須」ステータスコードを使用してTLSなしでクライアント要求を完了できないことを示している場合があります。これには、必要なTLSバージョンのトークンを指定するアップグレードヘッダーフィールドを含める必要があります。
HTTP/1.1 426 Upgrade Required Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade
http/1.1 426アップグレード必要なアップグレード：TLS/1.0、HTTP/1.1接続：アップグレード
The server SHOULD include a message body in the 426 response which indicates in human readable form the reason for the error and describes any alternative courses which may be available to the user.
サーバーには、エラーの理由を人間の読み取り可能な形式で示す426応答にメッセージ本文を含める必要があり、ユーザーが利用できる代替コースを説明します。
Note that even if a client is willing to use TLS, it must use the operations in Section 3 to proceed; the TLS handshake cannot begin immediately after the 426 response.
クライアントがTLSを使用する意思がある場合でも、セクション3の操作を使用して続行する必要があることに注意してください。TLSの握手は、426の応答後すぐに開始できません。
As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change.
ホップバイホップヘッダーとして、アップグレードはHTTPの各ペアの対応者の間でネゴシエートされます。ユーザーエージェントがアップグレードヘッダーでリクエストをプロキシに送信した場合、エンドツーエンドの変更ではなく、それ自体とプロキシの間のプロトコルの変更を要求しています。
Since TLS, in particular, requires end-to-end connectivity to provide authentication and prevent man-in-the-middle attacks, this memo specifies the CONNECT method to establish a tunnel across proxies.
特に、TLSは認証を提供し、中間攻撃を防ぐためにエンドツーエンドの接続を必要とするため、このメモは、プロキシ全体にトンネルを確立するための接続方法を指定します。
Once a tunnel is established, any of the operations in Section 3 can be used to establish a TLS connection.
トンネルが確立されると、セクション3の操作を使用してTLS接続を確立できます。
If an origin server receives an Upgrade header from a proxy and responds with a 101 Switching Protocols response, it is changing the protocol only on the connection between the proxy and itself. Similarly, a proxy might return a 101 response to its client to change the protocol on that connection independently of the protocols it is using to communicate toward the origin server.
Origin Serverがプロキシからアップグレードヘッダーを受信し、101のスイッチングプロトコル応答で応答する場合、プロキシとそれ自体の接続でのみプロトコルを変更しています。同様に、プロキシは、クライアントに対する101の応答を返して、その接続のプロトコルをオリジンサーバーに向けて通信するために使用しているプロトコルとは無関係に変更する場合があります。
These scenarios also complicate diagnosis of a 426 response. Since Upgrade is a hop-by-hop header, a proxy that does not recognize 426 might remove the accompanying Upgrade header and prevent the client from determining the required protocol switch. If a client receives a 426 status without an accompanying Upgrade header, it will need to request an end to end tunnel connection as described in Section 5.2 and repeat the request in order to obtain the required upgrade information.
これらのシナリオは、426の応答の診断も複雑にします。アップグレードはホップバイホップヘッダーであるため、426を認識しないプロキシは、付随するアップグレードヘッダーを削除し、クライアントが必要なプロトコルスイッチを決定するのを防ぐことができます。クライアントがアップグレードヘッダーを添付せずに426ステータスを受け取った場合、セクション5.2で説明されているようにエンドツーエンドトンネル接続を要求し、必要なアップグレード情報を取得するためにリクエストを繰り返す必要があります。
This hop-by-hop definition of Upgrade was a deliberate choice. It allows for incremental deployment on either side of proxies, and for optimized protocols between cascaded proxies without the knowledge of the parties that are not a part of the change.
アップグレードのこのホップバイホップの定義は、意図的な選択でした。プロキシの両側での増分展開、および変更の一部ではない当事者の知識なしに、カスケードプロキシ間の最適化されたプロトコルを可能にします。
A CONNECT method requests that a proxy establish a tunnel connection on its behalf. The Request-URI portion of the Request-Line is always an 'authority' as defined by URI Generic Syntax [2], which is to say the host name and port number destination of the requested connection separated by a colon:
Connectメソッドは、プロキシがその代わりにトンネル接続を確立することを要求します。リクエストラインのリクエスト-URI部分は、URI Generic構文[2]で定義されているように常に「権限」です。
CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80
connect server.example.com:80 http/1.1ホスト：server.example.com：80
Other HTTP mechanisms can be used normally with the CONNECT method -- except end-to-end protocol Upgrade requests, of course, since the tunnel must be established first.
他のHTTPメカニズムは、最初にトンネルを確立する必要があるため、エンドツーエンドのプロトコルアップグレードリクエストを除き、接続方法で正常に使用できます。
For example, proxy authentication might be used to establish the authority to create a tunnel:
たとえば、プロキシ認証を使用して、トンネルを作成する権限を確立することができます。
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
Like any other pipelined HTTP/1.1 request, data to be tunneled may be sent immediately after the blank line. The usual caveats also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding.
他のPipelined HTTP/1.1リクエストと同様に、トンネルに登録されるデータは、空白行の直後に送信される場合があります。通常の警告も適用されます。最終的な応答が負の場合はデータが破棄される場合があり、複数のTCPセグメントが未解決の場合、接続が応答なしでリセットされる場合があります。
Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested host and port, and has switched to tunneling the current connection to that server connection.
接続要求に対する（2xx）応答が成功したことは、プロキシが要求されたホストとポートへの接続を確立し、そのサーバー接続への現在の接続をトンネリングするように切り替えたことを示しています。
It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the first proxy SHOULD make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy MUST NOT respond with any 2xx status code unless it has either a direct or tunnel connection established to the authority.
プロキシ自体は、別のプロキシを介して要求されたOrigin Serverにのみ到達できる場合があります。この場合、最初のプロキシは、その次のプロキシの接続要求を行い、当局へのトンネルを要求する必要があります。プロキシは、当局に確立された直接またはトンネル接続のいずれかがない限り、2xxステータスコードで応答してはなりません。
An origin server which receives a CONNECT request for itself MAY respond with a 2xx status code to indicate that a connection is established.
それ自体の接続要求を受信するOrigin Serverは、2xxステータスコードで応答して、接続が確立されていることを示す場合があります。
If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that peer undelivered, that data will be discarded.
いずれかの時点で、いずれかのピアが切断された場合、そのピアから来た未解決のデータは他のピアに渡され、その後他の接続もプロキシによって終了します。そのピアに未配達の未解決のデータが登録されていない場合、そのデータは破棄されます。
Reliable, interoperable negotiation of Upgrade features requires an unambiguous failure signal. The 426 Upgrade Required status code allows a server to definitively state the precise protocol extensions a given resource must be served with.
アップグレード機能の信頼できる相互運用可能な交渉には、明確な障害信号が必要です。426アップグレードが必要なステータスコードにより、サーバーは、特定のリソースを提供する必要がある正確なプロトコル拡張を明確に述べることができます。
It might at first appear that the response should have been some form of redirection (a 3xx code), by analogy to an old-style redirection to an https: URI. User agents that do not understand Upgrade: preclude this.
最初は、HTTPS：URIへの古いスタイルのリダイレクトに類似して、何らかの形のリダイレクト（3xxコード）であるべきだったように思われるかもしれません。アップグレードを理解していないユーザーエージェント：これを排除します。
Suppose that a 3xx code had been assigned for "Upgrade Required"; a user agent that did not recognize it would treat it as 300. It would then properly look for a "Location" header in the response and attempt to repeat the request at the URL in that header field. Since it did not know to Upgrade to incorporate the TLS layer, it would at best fail again at the new URL.
「アップグレードが必要」に3xxコードが割り当てられていたとします。認識していないユーザーエージェントは、それを300として扱うでしょう。その後、応答で「ロケーション」ヘッダーを適切に探し、そのヘッダーフィールドのURLでリクエストを繰り返しようとします。TLSレイヤーを組み込むためにアップグレードすることを知らなかったため、新しいURLでせいぜい再び失敗します。
IANA shall create registries for two name spaces, as described in BCP 26 [10]:
IANAは、BCP 26 [10]に記載されているように、2つの名前スペースのレジストリを作成するものとします。
o HTTP Status Codes o HTTP Upgrade Tokens
o HTTPステータスコードo HTTPアップグレードトークン
The HTTP Status Code Registry defines the name space for the Status-Code token in the Status line of an HTTP response. The initial values for this name space are those specified by:
HTTPステータスコードレジストリは、HTTP応答のステータスラインでステータスコードトークンの名前空間を定義します。この名前空間の初期値は、次のように指定された値です。
1. Draft Standard for HTTP/1.1 [1] 2. Web Distributed Authoring and Versioning [4] [defines 420-424] 3. WebDAV Advanced Collections [5] (Work in Progress) [defines 425] 4. Section 6 [defines 426]
1. http/1.1 [1]のドラフト標準[1] 2. Web分散オーサリングとバージョン[4] [420-424を定義] 3. WebDav Advanced Collections [5]（進行中の作業）[定義425] 4.セクション6 [定義426]
Values to be added to this name space SHOULD be subject to review in the form of a standards track document within the IETF Applications Area. Any such document SHOULD be traceable through statuses of either 'Obsoletes' or 'Updates' to the Draft Standard for HTTP/1.1 [1].
この名前スペースに追加される値は、IETFアプリケーション領域内の標準トラックドキュメントの形式でレビューする必要があります。そのようなドキュメントは、HTTP/1.1 [1]のドラフト標準への「廃止」または「更新」のいずれかのステータスを通じて追跡可能でなければなりません。
The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade HTTP header field. Each registered token should be associated with one or a set of specifications, and with contact information.
HTTPアップグレードトークンレジストリは、アップグレードHTTPヘッダーフィールドのプロトコルを識別するために使用される製品トークンの名前スペースを定義します。登録された各トークンは、1つまたは一連の仕様、および連絡先情報に関連付けられる必要があります。
The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey the production for 'product':
HTTP/1.1 [1]のドラフト標準は、これらのトークンが「製品」の生産に従うことを指定しています。
product = token ["/" product-version] product-version = token
Product = token ["/" product-version] product-version = token
Registrations should be allowed on a First Come First Served basis as described in BCP 26 [10]. These specifications need not be IETF documents or be subject to IESG review, but should obey the following rules:
登録は、BCP 26 [10]に記載されているように、先着順で許可される必要があります。これらの仕様は、IETFドキュメントであるか、IESGレビューの対象である必要はありませんが、次のルールに従う必要があります。
1. A token, once registered, stays registered forever. 2. The registration MUST name a responsible party for the registration. 3. The registration MUST name a point of contact. 4. The registration MAY name the documentation required for the token. 5. The responsible party MAY change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request. 6. The responsible party for the first registration of a "product" token MUST approve later registrations of a "version" token together with that "product" token before they can be registered. 7. If absolutely required, the IESG MAY reassign the responsibility for a token. This will normally only be used in the case when a responsible party cannot be contacted.
1. 登録されると、トークンは永遠に登録されたままです。2.登録は、登録の責任者に名前を付ける必要があります。3.登録は、連絡先に名前を付ける必要があります。4.登録は、トークンに必要なドキュメントに名前を付けることができます。5.責任者は、いつでも登録を変更する場合があります。IANAは、そのようなすべての変更の記録を保持し、リクエストに応じてそれらを利用できるようにします。6.「製品」トークンの最初の登録の責任者は、登録する前に「バージョン」トークンと「製品」トークンの後の登録を承認する必要があります。7.絶対に必要な場合、IESGはトークンの責任を再割り当てする場合があります。これは通常、責任者に連絡できない場合にのみ使用されます。
This specification defines the protocol token "TLS/1.0" as the identifier for the protocol specified by The TLS Protocol [6].
この仕様では、TLSプロトコル[6]で指定されたプロトコルの識別子として、プロトコルトークン「TLS/1.0」を定義します。
It is NOT required that specifications for upgrade tokens be made publicly available, but the contact information for the registration SHOULD be.
アップグレードトークンの仕様を公開されることは必須ではありませんが、登録の連絡先情報は必要です。
The potential for a man-in-the-middle attack (deleting the Upgrade header) remains the same as current, mixed http/https practice:
中間の攻撃の可能性（アップグレードヘッダーの削除）は、現在の混合HTTP/HTTPSプラクティスと同じままです。
o Removing the Upgrade header is similar to rewriting web pages to change https:// links to http:// links. o The risk is only present if the server is willing to vend such information over both a secure and an insecure channel in the first place. o If the client knows for a fact that a server is TLS-compliant, it can insist on it by only sending an Upgrade request with a no-op method like OPTIONS. o Finally, as the https: specification warns, "users should carefully examine the certificate presented by the server to determine if it meets their expectations".
o アップグレードヘッダーの削除は、https：//リンクをhttp：// linksに変更するためにWebページを書き換えることに似ています。oリスクは、そもそもセキュアなチャネルと安全なチャネルの両方にそのような情報を送り込むことをいとわない場合にのみ存在します。oサーバーがTLSに準拠しているという事実をクライアントが知っている場合、オプションのようなNO-OPメソッドを使用してアップグレード要求を送信することで、それを主張できます。o最後に、HTTPS：仕様が警告するように、「ユーザーは、サーバーが提示した証明書を慎重に調べて、期待を満たしているかどうかを判断する必要があります」。
Furthermore, for clients that do not explicitly try to invoke TLS, servers can use the Upgrade header in any response other than 101 or 426 to advertise TLS compliance. Since TLS compliance should be considered a feature of the server and not the resource at hand, it should be sufficient to send it once, and let clients cache that fact.
さらに、明示的にTLSを呼び出そうとしないクライアントの場合、サーバーは101または426以外の応答でアップグレードヘッダーを使用して、TLSコンプライアンスを宣伝できます。TLSコンプライアンスは、手元のリソースではなくサーバーの機能と見なされる必要があるため、1回送信して、クライアントにその事実をキャッシュできるようにするだけで十分です。
While nothing in this memo affects the definition of the 'https' URI scheme, widespread adoption of this mechanism for HyperText content could use 'http' to identify both secure and non-secure resources.
このメモの何も「HTTPS」URIスキームの定義に影響しませんが、ハイパーテキストコンテンツのこのメカニズムの広範な採用は「HTTP」を使用して安全なリソースと非セキュアの両方のリソースを特定できます。
The choice of what security characteristics are required on the connection is left to the client and server. This allows either party to use any information available in making this determination. For example, user agents may rely on user preference settings or information about the security of the network such as 'TLS required on all POST operations not on my local net', or servers may apply resource access rules such as 'the FORM on this page must be served and submitted using TLS'.
接続に必要なセキュリティ特性の選択は、クライアントとサーバーに残されます。これにより、いずれかの当事者がこの決定を行う際に利用可能な情報を使用することができます。たとえば、ユーザーエージェントは、ユーザーの好みの設定や、「私のローカルネットではなくすべてのポスト操作に必要なTLS」などのネットワークのセキュリティに関する情報に依存している場合があります。TLSを使用して提供し、提出する必要があります。
A generic TCP tunnel is fraught with security risks. First, such authorization should be limited to a small number of known ports. The Upgrade: mechanism defined here only requires onward tunneling at port 80. Second, since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports. A putative HTTP client CONNECTing to port 25 could relay spam via SMTP, for example.
一般的なTCPトンネルには、セキュリティリスクが悩まれています。第一に、そのような承認は、少数の既知のポートに限定されるべきです。アップグレード：ここで定義されているメカニズムには、ポート80での前進のトンネルのみが必要です。2番目に、トンネルデータはプロキシに不透明であるため、他の有名または予約されたポートにトンネリングするための追加のリスクがあります。たとえば、ポート25に接続する推定HTTPクライアントは、SMTPを介してスパムをリレーできます。
References
参考文献
[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[1] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[2] Berners-Lee, T., Fielding, R. and L. Masinter, "URI Generic Syntax", RFC 2396, August 1998.
[2] Berners-Lee、T.、Fielding、R。and L. Masinter、「Uri Generic Syntax」、RFC 2396、1998年8月。
[3] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[3] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[4] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "Web Distributed Authoring and Versioning", RFC 2518, February 1999.
[4] Goland、Y.、Whitehead、E.、Faizi、A.、Carter、S。and D. Jensen、「Web分散オーサリングとバージョン」、RFC 2518、1999年2月。
[5] Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections Protocol", Work In Progress.
[5] Slein、J.、Whitehead、E.J.、et al。、「WebDav Advanced Collections Protocol」、Work in Progress。
[6] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999.
[6] Dierks、T。およびC. Allen、「TLSプロトコル」、RFC 2246、1999年1月。
[7] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[7] Herriot、R。、Butler、S.、Moore、P。and R. Turner、「インターネット印刷プロトコル/1.0：エンコーディングとトランスポート」、RFC 2565、1999年4月。
[8] Luotonen, A., "Tunneling TCP based protocols through Web proxy servers", Work In Progress. (Also available in: Luotonen, Ari. Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)
[8] Luotonen、A。、「Webプロキシサーバーを介したTCPベースのプロトコルのトンネル」、進行中の作業。（入手可能：Luotonen、Ari。Webプロキシサーバー、Prentice-Hall、1997 ISBN：0136806120。）
[9] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[9] Rose、M。、「XMLを使用したI-DSおよびRFCの執筆」、RFC 2629、1999年6月。
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[10] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[11] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Authors' Addresses
著者のアドレス
Rohit Khare 4K Associates / UC Irvine 3207 Palo Verde Irvine, CA 92612 US
Rohit Khare 4K Associates / UC Irvine 3207 Palo Verde Irvine、CA 92612 US
Phone: +1 626 806 7574
EMail: rohit@4K-associates.com
URI: http://www.4K-associates.com/
Scott Lawrence Agranat Systems, Inc. 5 Clocktower Place Suite 400 Maynard, MA 01754 US
Scott Lawrence Agranat Systems、Inc。5 ClockTower Place Suite 400 Maynard、MA 01754 US
Phone: +1 978 461 0888
EMail: lawrence@agranat.com
URI: http://www.agranat.com/
The CONNECT method was originally described in a Work in Progress titled, "Tunneling TCP based protocols through Web proxy servers", [8] by Ari Luotonen of Netscape Communications Corporation. It was widely implemented by HTTP proxies, but was never made a part of any IETF Standards Track document. The method name CONNECT was reserved, but not defined in [1].
Connectメソッドは、もともと「Web Proxyサーバーを介したTCPベースのプロトコルをトンネル化するTCPベースのプロトコル」、[8] Netscape Communications CorporationのAri Luotonenによる進行中の作業で説明されていました。HTTPプロキシによって広く実装されていましたが、IETF標準トラックドキュメントの一部には作成されませんでした。メソッド名Connectは予約されていましたが、[1]で定義されていません。
The definition provided here is derived directly from that earlier memo, with some editorial changes and conformance to the stylistic conventions since established in other HTTP specifications.
ここで提供される定義は、以前のメモから直接導き出されており、いくつかの編集上の変更と他のHTTP仕様で確立されて以来、文体的な慣習に適合しています。
Additional Thanks to:
追加の感謝：
o Paul Hoffman for his work on the STARTTLS command extension for ESMTP. o Roy Fielding for assistance with the rationale behind Upgrade: and its interaction with OPTIONS. o Eric Rescorla for his work on standardizing the existing https: practice to compare with. o Marshall Rose, for the xml2rfc document type description and tools [9]. o Jim Whitehead, for sorting out the current range of available HTTP status codes. o Henrik Frystyk Nielsen, whose work on the Mandatory extension mechanism pointed out a hop-by-hop Upgrade still requires tunneling. o Harald Alvestrand for improvements to the token registration rules.
o Paul Hoffmanは、ESMTPのStartTLSコマンド拡張機能に関する彼の作業について。oアップグレードの背後にある理論的根拠を支援するためのロイフィールディング：およびそのオプションとの相互作用。O Eric Rescorlaは、既存のHTTPSの標準化に関する彼の仕事について：比較する練習。o XML2RFCドキュメントタイプの説明とツール[9]のMarshall Rose。oジム・ホワイトヘッド、利用可能なHTTPステータスコードの現在の範囲を整理するため。O Henrik Frystyk Nielsenは、強制的な拡張メカニズムに関する研究が、ホップバイホップのアップグレードにはまだトンネリングが必要であると指摘しました。O Harald Alvestrandトークン登録規則の改善について。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。