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
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.
著作権（C）インターネット協会（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.
このメモは、既存のTCP接続を介してトランスポート層セキュリティ（TLS）を開始するためにHTTP / 1.1にアップグレードメカニズムを使用する方法について説明します。これは、無担保・有担保HTTPトラフィックが同じ既知のポートを共有することができます（：80ではなくHTTPSで：この場合には、HTTPを443で）。また、「仮想ホスティング」を可能にするので、単一の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上にHTTPを展開する歴史的実践は、[3]固有のURIスキームとTCPポート番号によって単独でHTTPの組み合わせを区別しています。いくつかのケースでは、付与された - - 「HTTPS」443パラレルよく知られているポート番号は、同様に要求されたポートでSSL経由のHTTPプロトコルを意味しながら、スキーム「HTTP」は、ポート80で単独の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会議で、アプリケーションエリアの取締役および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の現在の解釈に影響を与えません：URIを。しかし、そのようなインターネット印刷プロトコルとしてHTTPの上に構築された新しいアプリケーションプロトコルは、[7]、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.
アップグレードメカニズムは、「仮想ホスティング」問題を解決します。意図したWebサービスを明確にするために、ヘッダー：むしろ、単一のホストに複数のIPアドレスを割り当てるよりも、HTTP / 1.1サーバがホストを使用します。 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アドレスのみに頼って、意図したホスト名を指定していません。平文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".
クライアントまたはサーバはTLSで保護された接続は、所望または必要であることを示すために、HTTP / 1.1 [1]アップグレード機構（セクション14.42）を使用することができます。このメモは、トークンのアップグレード「1.0 / TLS」を定義して、新しい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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHOULD"、 "SHOULD NOT" およびRFC 2119に記載されるように解釈されるべきである。この文書に表示される "MAY" [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」を含むUpgradeヘッダフィールドを持つ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
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操作に応答することができる、OR（次のセクションで説明するように）セキュアな操作に切り替えます。
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".
[1]「アップグレードがHTTP / 1.1メッセージに存在しているときはいつでもアップグレードキーワードが接続ヘッダフィールド（セクション14.10）内に供給されなければならない」ことを指定したHTTP / 1.1に注意してください。
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).
無担保レスポンスが受け入れられない場合、クライアントはOPTIONSはTLS / 1.0（可能な場合）への切り替えを完了するために最初の要求送らなければなりません。
OPTIONS * HTTP/1.1
Host: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade
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で指定されるように、サーバがTLSハンドシェイクを開始する用意がある場合は[1]、それは中間「プロトコルの切り替え101」を送信しなければならないし、それがスイッチングされるプロトコルスタックのトークンを指定するアップグレードレスポンスヘッダを含める必要があります。
HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
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レスポンスを終了する空行の後にレスポンスのUpgradeヘッダフィールドによって定義されたものにプロトコルを切り替えます」。
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.
サーバーは、クライアント要求が必要なTLSバージョンのトークンを指定するUpgradeヘッダフィールドを含まなければならない「426アップグレードの必要」のステータスコードを使用して、TLSなしで完了することができないことを示してもよいです。
HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
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は、具体的には、認証を提供し、man-in-the-middle攻撃を防止するために、エンドツーエンド接続を必要とするので、このメモは、プロキシを横断トンネルを確立するために、CONNECTメソッドを指定します。
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.
オリジンサーバがプロキシからアップグレードヘッダを受信し、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ジェネリック構文[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メカニズムはCONNECTメソッドで正常に使用することができます。
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=
CONNECT server.example.com:80 HTTP / 1.1ホスト：server.example.com:80プロキシ認証：基本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.
他のパイプライン化された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.
CONNECT要求へのどんな成功した（の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.
これは、プロキシ自体は唯一の別のプロキシを介して、要求元のサーバに達することができる場合があります。この場合、最初のプロキシは権威へのトンネルを要求し、その次のプロキシの接続要求をしなければなりません。それは権威に設立され、直接またはトンネル接続を持っていない限り、プロキシはどんなの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.
自分自身のためにCONNECT要求を受信したオリジンサーバは、接続が確立されることを示すための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.
任意の時点でいずれかのピアの1つが切断された場合は、そのピアから来た未処理のデータは、他のものに渡され、それも他の接続後にプロキシによって終了します。優れたデータはそのピアに未配信がある場合、そのデータは破棄されます。
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に古いスタイルのリダイレクトに類推して、リダイレクト（の3xxコード）のいくつかの形式となっているべきであると思われるかもしれません：URIを。アップグレード理解していないユーザーエージェント：これを排除します。
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コードは、「アップグレードが必要」に割り当てられていたと仮定。それは、その後、適切に対応して「場所」ヘッダーを探し、そのヘッダフィールドにURLでリクエストを繰り返すしようと300としてそれを扱います認識していなかったユーザエージェント。それはTLS層を組み込むためにアップグレードすることを知らなかったので、それが最高の状態で、新たなURLで再び失敗するでしょう。
IANA shall create registries for two name spaces, as described in BCP 26 [10]:
BCP 26 [10]に記載されているようにIANAは、2つの名前空間のためのレジストリを作成しなければなりません。
o HTTP Status Codes o HTTP Upgrade Tokens
HTTPアップグレードトークン〇〇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] 2. Web分散オーサリングとバージョン[4] [定義420-424] 3. WebDAVの高度なコレクション[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アプリケーションエリア内の標準トラック文書の形で見直しの対象とすべきです。任意のそのような文書は、[1]「時代遅れ」またはHTTP / 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ヘッダフィールドにプロトコルを識別するために使用される製品トークンの名前空間を定義します。登録された各トークンは、一つまたは仕様のセットとし、連絡先情報に関連付けられなければなりません。
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
生成物=トークン[「/」製品バージョン]製品バージョン=トークン
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:
（Upgradeヘッダを削除する）中間者攻撃の可能性は、現在、混合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".
Upgradeヘッダを削除するoをHTTPSを変更するには、Webページを書き換えると似ています：http //へのリンク：//リンク。 Oリスクは、サーバが安全で最初の場所に安全でないチャネルの両方の上にこのような情報を、販売する意思がある場合にのみ存在します。クライアントはサーバがTLSに準拠しているという事実を知っている場合、O、それが唯一のオプションのような無操作方法でアップグレード要求を送信することによって、それを主張することができます。 HTTPSとO最後に、：仕様は警告し、「ユーザーは慎重に、それは彼らの期待を満たしているかどうかを判断するために、サーバーが提示した証明書を検討すべきです」。
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を起動しようとしないクライアントのために、サーバはTLSコンプライアンスを宣伝するために101または426以外のレスポンスにUpgradeヘッダを使用することができます。 TLSのコンプライアンスは、サーバーではなく、手で資源の機能考慮しなければならないので、一度それを送信するのに十分であること、およびクライアントがその事実をキャッシュさせてください。
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'.
セキュリティ特性は、接続に必要とされているかの選択は、クライアントとサーバーに残されています。これは、いずれかの当事者がこの決定を行う際に利用可能なあらゆる情報を使用することができます。例えば、ユーザーエージェントは、このページの「FORMなどのリソースへのアクセスルールを適用することができる、ユーザの好みの設定や「ではない、私のローカルネット上のすべてのPOST操作に必要な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秒で以降のトンネリングを必要とし、他のよく知られたまたは予約ポートにトンネリングするための追加のリスクがあります。ポート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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[2] Berners-Lee, T., Fielding, R. and L. Masinter, "URI Generic Syntax", RFC 2396, August 1998.
[2]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "URIジェネリック構文"、RFC 2396、1998年8月。
[3] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[3]レスコラ、E.、 "HTTPオーバーTLS"、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.、ホワイトヘッド、E.、フェッチ、A.、カーター、S.、およびD.ジェンセン、 "Web分散オーサリングとバージョン"、RFC 2518、1999年2月。
[5] Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections Protocol", Work In Progress.
[5]、らJ.ホワイトヘッド、E. J.を打った。 "WebDAVの高度なコレクションプロトコル"、進行中の作業。
[6] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999.
[6]ダークス、T.及びC.アレン、 "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]ヘリオット、R.、バトラー、S.、ムーア、P.とR.ターナー、 "インターネット印刷プロトコル/ 1.0：コード化とTransport"、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、アリWebプロキシサーバー、プレンティス・ホール、1997年ISBN：0136806120）
[9] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[9]ローズ、M.、 "ライティングI-DSおよびXMLを使用している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.
、BCP 26、RFC 2434、1998年10月[10] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[11]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Authors' Addresses
著者のアドレス
Rohit Khare 4K Associates / UC Irvine 3207 Palo Verde Irvine, CA 92612 US
ロフィット・クヘア4Kアソシエイツ/ UCアーバイン3207パロベルデアーバイン、CA 92612米国
Phone: +1 626 806 7574 EMail: rohit@4K-associates.com URI: http://www.4K-associates.com/
電話：+1 626 806 7574 Eメール：rohit@4K-associates.com URI：http://www.4K-associates.com/
Scott Lawrence Agranat Systems, Inc. 5 Clocktower Place Suite 400 Maynard, MA 01754 US
スコット・ローレンスAgranat Systems、Inc.の5クロックタワープレイススイート400メイナード、MA 01754米国
Phone: +1 978 461 0888 EMail: lawrence@agranat.com URI: http://www.agranat.com/
電話：+1 978 461 0888 Eメール：lawrence@agranat.com URI：http://www.agranat.com/
Appendix A. Acknowledgments
付録A.謝辞
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メソッドは、もともと題し進行中の作業で説明した、「トンネリングTCP Webプロキシサーバー経由でプロトコルをベースと」、[8]、Netscape Communications Corporationのアリ・ルオトナンこともできます。これは、広く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.
ESMTPのためのSTARTTLSコマンド拡張の彼の仕事のためのポール・ホフマンO。 OPTIONSとの相互作用：アップグレードの根拠と支援のためのロイフィールディングO。と比較する実践：既存のhttpsを標準化することで彼の仕事のためのエリックレスコラO。 Oマーシャルローズ、xml2rfcのドキュメントタイプの説明およびツールの[9]。 Oジム・ホワイトヘッド、可能なHTTPステータスコードの電流範囲をソートします。その作品は必須の拡張メカニズムのホップバイホップのアップグレードを指摘Oヘンリック・フリスティック・ニールセンは、まだトンネリングが必要です。トークンの登録ルールの改善のためのハラルドAlvestrand O。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。