Update HTTP/1.1 to TLS (upgrading to TLS within HTTP/1.1)

Status of this Memorandum

This document defines Internet standard protocols for the Internet community and solicit suggestions for improvement. About this
For the Protocol Status and standardization status, see Internet official protocol standard (Std 1 ). The publication of this memorandum is not subject
Any restrictions.

Copyright Notice
Copyright (c) the Internet Society (2000). All rights reserved.

Summary

This document describes how to use the HTTP/1.1 upgrade mechanism to initiate secure transmission over an existing TCP connection.
Layer (TLS ). This allows secure and insecure HTTP Communication to share the same well-known port (
In this example, HTTP is on port 80 rather than on port 443 like https ). This method also supports "virtual master"
Therefore, an HTTP + TLS server can distinguish messages sent to several hosts on the same IP address.
HTTP/1.1 [1] defines the upgrade as a hop-by-hop mechanism. This memorandum also describes
Establish an http connect Mechanism for end-to-end tunnels. Finally, this memorandum is a public HTTP status code and a public or
The private upgrade product symbol creates a new IANA registration.
This memorandum does not affect the definition of the current "HTTPS" URI scheme. This scheme has defined a separate
Namespace (http://example.org/and https://example.org/not equivalent ).







Directory
1. Motivation 2
2. Introduction 3
2.1. Related Terms 3
3. The customer requests to upgrade http3 over TLS
3.1. Optional upgrade 3
3.2. Force Update 4
3.3 server confirmation of upgrade request 4
4. The server requests to upgrade to http4 on top of TLS.
4.1 option notification 4
4.1 Forced notification 4
5. Upgrade through proxy 5
6. Principle of using a 4xx (customer error) Status Code 6
7 IANA considerations 6
7.1 HTTP status code registration 7
Security considerations 7
7.1 https: Meaning of the URI scheme 8
7.2 connect security considerations 8
Reference 8
Author address 9
Appendix A Thank you 10
Copyright 10
Thank you 11


1. Motivation
In the past, HTTP was configured on ssl3 [3] with a unique Uri and TCP port number.
HTTP is differentiated. The Scheme "HTTP" means an independent HTTP protocol on port 80, while "HTTPS" indicates
HTTP Protocol over SSL on port 443. Similarly, other application protocols (such as snews and ftps) are partitioned.
Two port numbers are required for safe and insecure use. This method makes available the well-known port
The number is halved.
At the December 1997 IETF Conference in Washington, DC, the application zone supervisor and iesg reiterated their disapproval of using parallel computing.
The "security" Port Number. The HTTP/1.1 upgrade mechanism allows you to set up the Transport Layer Security on an opened HTTP connection.
All [6].
This suggestion has been widely accepted in the last two years,
The browser is not very interested in port 443. In fact, this memorandum does not affect the current solution to https: URI.
Release. However, a new application protocol such as Internet Printing Protocol [7] established over HTTP requires such a machine.
Making IETF standardization a step forward.
The upgrade mechanism also solves the "virtual host" problem. The HTTP/1.1 server does not allocate multiple
HOST: header to differentiate Web Services. HTTP/1.1 is becoming increasingly popular.
Multiple ISPs provide name-based virtual hosts, so that the IP address space will not be exhausted immediately.
Like earlier versions of HTTP, TLS (and SSL) is subject to initialization handshake without specifying the desired host.
Only depends on the IP address. Use Plaintext HTTP/1.1 upgrade: As the prelude to TLS handshake-based
Initial HOST: select a certificate in the header, which allows the ISP to provide a name-based security VM.
2. Introduction
TLS, also known as SSL (Secure Socket Layer), establishes a private end-to-end connection. The options include using multiple cryptographic systems.
Strong Mutual authentication. At the beginning, a handshake uses three sub-protocols to set a record layer for authentication.
Endpoint, set parameters, and report errors. Then, encryption, compression, and re-connection are processed by a layered record protocol.
Remaining part. The latter is expected to be completely transparent. For example, in TLS record marking or authentication and HTTP/1.1
There is no association between codes or authentication.
Both the room and server can use the HTTP/1.1 [1] upgrade mechanism (section 14.42) to indicate TLS secure connection is necessary
. This memorandum defines the "TLS/1.0" upgrade mark and a new HTTP status code, "426-upgrade required ".
Sections 3 and 4 describe the operations of directly connected rooms and servers. As described in section 5
Before any operation, the intermediate proxy must establish an end-to-end Tunnel.
2.1. Related Terms
In this article, the keywords "must", "must not", "requirements", "should", "should", and "Can
For more information, see [rfc2119].
3. The client requests to upgrade HTTP to TLS
When the customer sends an HTTP/1.0 request with the upgrade header containing the mark "TLS/1.1", it indicates
The server completes the current HTTP/1.0 request after converting to TLS/1.1.
3.1. Optional upgrades
When an insecure response is acceptable, a client can request forwarding during any plaintext HTTP Request
To a safe operation process:

Get http://example.bank.com/acct_stat.html? 749394889300 HTTP/1.1
HOST: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade

In this example, the server can make a normal response to the HTTP request in plaintext or convert it to a safe operation.
(For details, see the next section ).
Note that in HTTP/1.1 [1], the parameter "whether or not the upgraded word appears in the HTTP/1.1 message
It must appear in a connection header domain (section 14.10 )".
3.2. Force update
If an insecure response cannot be received, the customer must first send an option request to complete TLS/1.0
Switch (if possible ).

Options * HTTP/1.1
HOST: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade

3.3 server confirmation of upgrade request
As defined in HTTP/1.1 [1], if the server is preparing to initialize the TLS handshake, it must send the intermediate "101 rpm
Protocol change "must include an upgrade response header that defines the protocol stack mark to be converted:

HTTP/1.1 101 switching protocols
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

Note that the Protocol mark listed in the 101 conversion protocol upgrade header defines a bottom-up stack.
As defined in HTTP/1.1 [1] and 10.1.2: "the server will establish
The protocol that converts the protocol to the upgraded header domain defined in the response.
Once the TLS handshake is successfully completed, the server must continue to respond to the original request. Any TLS handshake failure is required
The connection is interrupted through the TLS Error alert specification ,.
4. The server requests to upgrade HTTP to TLS
The upgrade Response Header declares the Protocol upgrade that a server may accept. And the status code of "426 update request"
The server can send a protocol upgrade request that the customer must accept to complete the request.
4.1 option notification
As defined in HTTP/1.1 [1], the server can include an upgrade in any response except 101 or 426.
The header indicates the conversion to any listed protocol (combination ).
4.1 Forced notification
The server can use "426 upgrade required" to indicate that the customer request cannot be completed without TLS. This response must contain
An upgrade header domain that defines the required TLS version mark.

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 to indicate the cause and description of the error in a readable form.
The route available to the user.
Note that, even if the customer is willing to use TLS, it must use the operations in Section 3rd.
The TLS handshake cannot start immediately.
5. Agent upgrade
As a skip-by-Skip header, each HTTP participant must negotiate and upgrade. If a user agent sends
A request with an upgrade header is sent to the agent. It requires changes between the agent and the agent, rather than between the client and the agent.
Because TLS specifically requires end-to-end connections to provide authentication and guard against man-in-the-middle attacks, this memorandum defines connect
Method is used to establish a cross-proxy tunnel.
Once a tunnel is established, the operations described in section 3rd can be used to establish a TLS connection.

5.1 meaning of skip-to-Skip upgrade
When an origin server receives an upgrade header from the proxy and responds with the 101 conversion protocol, it only changes itself and
Protocol for connection. Similarly, a proxy can return a 101 response to the customer to change the protocol on the connection.
The Protocol is independent of the protocol used to communicate with the source server.
This makes the diagnosis 426 response more complex. Because the upgrade is a skip-by-Skip header, one does not recognize
426 the response proxy may delete the accompanying upgrade header, so that the customer cannot decide how to convert the protocol. If the customer
The terminal receives a 426 status code that does not follow the upgrade header. It will request an end-to-end status code as described in section 5.2.
Tunnel connection and keep requesting to obtain the required upgrade information.
This end-to-end upgrade definition is a deliberate choice. This allows the agent to implement incremental operations on each end and
The optimization protocol between the associated proxies, without the need to know what is beyond the change.

5.2 use connect to request a tunnel

The Connect Method Request proxy establishes a connection channel. The request URI of the Request command line is always
A 'authority 'defined in syntax [2], which specifies the destination host name and port number for the request to connect.
Number separation:

Connect server.example.com: 80 HTTP/1.1.
HOST: server.example.com: 80

Other HTTP mechanisms can be used normally with the connect method-except for end-to-end protocol upgrade requests-
It is of course necessary to establish a tunnel first.
For example, proxy authentication can be used to establish a mechanism for creating a tunnel:

Connect server.example.com: 80 HTTP/1.1.
HOST: server.example.com: 80
Proxy-authorization: Basic agvsbg86d29ybgq =

Like any other HTTP/1.1 requests in an MPS queue, the data passed by the tunnel can be sent immediately after blank lines. Common police
Warning: if the final response is rejected, the data can be discarded. If more than one TCP data segment is not completed
The connection can be reset without any response.

5.3 create a tunnel using connect
Any successful response to the CONNECT Request (2XX) indicates that the proxy has been connected to the requested host and the corresponding port.
A connection is established and a tunnel has been switched to the connection with the same server.
The proxy itself may have to use another proxy to reach the requested source server. In this case, the first
The proxy should generate a connection request with the next proxy to request a channel with the same authority. The proxy must not
Response to 2XX Status Code, unless it already has a connection directly to authority or tunnel.
An origin server can use 2XX status code to respond to its own connection requests, indicating that the connection has been established.
If any party disconnects at any time, any data from this end will be transmitted to the other party, and then the other party
The connection is also terminated by the proxy. If any data sent to the first disconnected end is not transmitted, the data will be discarded.


6. Principle of using a 4xx (customer error) Status Code
Reliable. A clear failure signal is required for the features of the jointly negotiated upgrade. 426 upgrade request Status Code allow service
It explicitly declares that a protocol extension is required for a given resource.
At first it seems that the response should have a certain form of redirection (3xx code), similar to an https: URI
Targeting. However, the user agent who does not understand the upgrade mechanism cannot do so.
Imagine that a 3xx code has been granted the meaning of "need to upgrade"; a user agent that cannot identify it will
As 300. It may find a "location" header in the response and try to repeat the request for the URL in the header domain.
Because it does not know to upgrade to merge the TLS layer, it will eventually fail again on the new URL.

7. iana considerations
As described in BCP 26 [10], IANA registers for two namespaces:
HTTP status code
HTTP update mark

7.1 HTTP status code registration
The HTTP status code registration defines the status code mark in the HTTP response status line. The initial
The values are defined:
1. Draft HTTP/1.1 Standard
2. Web Distributed creation and version [4] [Definition 420-424]
3. Advanced collection of WebDAV [5] (being formulated) [Definition 425]
4. Section 6th [Definition 426]
The value to be added to the namespace should be submitted to the IETF application group in the standard record document format. Any such document should be accessible
The status word "obsolete" or "updated" in the HTTP/1.1 [1] draft allows tracing of the source.

7.2 HTTP update mark registration

The HTTP update mark registration defines the namespace for the product mark. This namespace is used to upgrade the HTTP header domain.
Resolution Protocol. Each registration mark should be associated with one or more standards and have associated information.
The HTTP/1.1 [1] draft standard defines the product-compliant mark:
Product = mark ["/" Product Version]
Product Version = mark

As described in BCP 26 [10], registration should be based on the first-come-first-served principle. These definitions do not need to be IETF text
Files Or iesg concerns, but the following principles should be observed:
1. Once a mark is registered, it will always be registered.
2. You must specify a group for registration.
3. You must specify a contact method for registration.
4. You must specify the document required by the mark for registration.
5. The responsible group can change the registration items at any time. Iana will record all of these changes and make it available to people who need them
.
6. The group responsible for the first registration of a product mark must agree with the product mark before they can register
Later registration of the "version" mark.
7. If necessary, the iesg can specify a new owner group for the mark. Normally, this is only unavailable in the responsible group.
This will happen only then.

This specification defines the Protocol mark "TLS/1.0" as the identifier of the protocol defined in TLS Protocol [6.
The definition of the upgrade mark is not required to be available to the public, but the registration contact information should be.

8. security considerations
The potential man-in-the-middle attack (delete the upgrade header) is the same as the current mix of HTTP/https:
. Removing the upgrade header is similar to rewriting the webpage to change https: // links to http: // links.
This risk is caused only when such information is disclosed through secure or insecure channels on the server.
If the customer knows that the server can process TLS, it will insist on sending upgrade requests without options.
. Finally, for example, https: the warning is defined. "The user should carefully check the certificate provided by the server to determine whether it meets his/her requirements.
Expectations.

In addition, for customers who do not explicitly activate TLS, the server can use the upgrade header except 101 or 426 in the response.
Advertise TLS capabilities. Since the TLS capability should be used as a server feature rather than a resource at hand, it should be sent once
It is enough to let the customer know this fact and use it as needed.

8.1 https: Meaning of the URI Scheme

This memorandum does not affect the meaning of 'https'. The popular hypertext content can be distinguished by 'http '.
Secure and insecure resources.
The security feature selection during connection is left to the customer and server. This allows each Party to make a decision using any available information.
Yes. For example, a user agent can rely on user settings related to network security, such
TLS is required for all post operations, or the server can apply a form such as 'This page must be submitted and processed
Use TLS and other resource access rules.

8.2 connect security considerations

A similar TCP channel is full of security risks. First, this authorization should be restricted to a small part of the end.
Port. The upgrade mechanism defined here is only required in the tunnel of port 80. Second, since the tunnel data is not transparent to the proxy
Note: there is an additional risk for other tunnels that are known and retained. For example, assume that an HTTP client connects to 25
Port, which can spread spam through SMTP.

Reference
[1] Fielding, R., Gettys, J., mogul, J., frystyk, H., masinter, L .,
Leaching, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1 ", RFC 2616, June 1999.

[2] Berners-Lee, T., Fielding, R. and L. masinter, "URI generic
Syntax ", RFC 2396, August 1998.

[3] rescorla, E., "HTTP over TLS", RFC 2818, May 2000.

[4] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jenkins,
"Web Distributed Authoring and Versioning", RFC 2518, February
1999.

[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.

[7] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet
Printing Protocol/1.0: encoding and transport ", RFC 2565, protocol l
1999.

[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 .)

[9] Rose, M., "writing I-Ds and rfcs using XML", RFC 2629, June
1999.

[10] narten, T. and H. alvestrand, "Guidelines for writing an IANA
Considerations section in rfcs ", BCP 26, RFC 2434, October 1998.

[11] bradner, S., "key words for use in rfcs To Indicate Requirement
Levels ", BCP 14, RFC 2119, March 1997.

Author address
Rohit Khare
4 K Associates/UC Irvine
3207 Palo Verde
Irvine, CA 92612
Us

Phone: + 1 626 806 7574
Email: rohit@4K-associates.com
Uri: The http://www.4K-associates.com/

Scott Lawrence
Agranat Systems, Inc.
5 clocktower place
Suite 400
Maynard, Ma 01754.
Us

Phone: + 1 978 461 0888
Email: lawrence@agranat.com
Uri: The http://www.agranat.com/

Appendix A Thank you
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].

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.

Additional thanks:

O Paul Hoffman for his work on the starttls command extension
ESMTP.
O Roy Fielding for compliance with the rationale behind upgrade:
And its interaction with options.
O Eric rescorla for his work on standardizing the existing https:
Practice to compare.
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
Machism pointed out a hop-by-hop upgrade still requires
Tunneling.
O Harald alvestrand for improvements to the token Registration
Rules.

Complete copyright notice
Copyright (c) the Internet Society (2000). All rights reserved.

This document and translations of it may be copied and furnished
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, cannot as needed for the purpose
Developing Internet standards in which case the procedures
Copyrights defined in the Internet standards process must be
Followed, or as required to translate it into ages other
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
"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
Merchantability or fitness for a particle purpose.

Thank you
Funding for the RFC editor function is currently provided by
Internet Society.
RFC2817-Upgrading to TLS within HTTP/1.1 upgrade to TLS in HTTP/1.1