idnits 2.17.1 draft-luotonen-web-proxy-tunneling-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([SSL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9385 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'TLS' is defined on line 374, but no explicit reference was found in the text == Unused Reference: 'SSL3' is defined on line 384, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-tls-protocol-05 ** Downref: Normative reference to an Historic draft: draft-ietf-tls-protocol (ref. 'TLS') -- Unexpected draft version: The latest known version of draft-hickman-netscape-ssl is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. 'SSL' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSL3' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Ari Luotonen 3 Expires: February 1999 Netscape Communications Corporation 4 August 1998 6 Tunneling TCP based protocols through Web proxy servers 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Currently, this draft is stable and only waiting for its referenced 27 documents to become RFC's, so this draft can become an RFC as well. 29 Abstract 31 This document specifies a generic tunneling mechanism for TCP based 32 protocols through Web proxy servers. This tunneling mechanism was 33 initially introduced for the SSL protocol [SSL] to allow secure Web 34 traffic to pass through firewalls, but its utility is not limited to 35 SSL. Earlier drafts of this specification were titled "Tunneling SSL 36 through Web Proxy Servers" . 37 Implementations of this tunneling feature are commonly referred to as 38 "SSL tunneling", although, again, it can be used for tunneling any 39 TCP based protocol. 41 A wide variety of existing client and proxy server implementations 42 conform to this specification. The purpose of this specification is 43 to describe the current practice, to propose some good practices for 44 implementing this specification, and to document the security 45 considerations that are involved with this protocol. 47 TCP PROTOCOL TUNNELING IN WEB PROXY SERVERS INTERNET-DRAFT August 1998 49 Table of Contents 51 1. Overview ................................................. 2 52 2. General Considerations ................................... 3 53 3. Functional Specification ................................. 3 54 3.1. Request ................................................ 3 55 3.2. Proxy Response ......................................... 4 56 3.2.1. Response Content-Type Field .......................... 5 57 3.3. Data Pipelining ........................................ 6 58 4. Extensibility ............................................ 7 59 5. Multiple Proxy Servers ................................... 7 60 6. Security Considerations .................................. 8 61 7. References ............................................... 8 62 8. Author's Address ......................................... 9 64 1. Overview 66 The wide success of the SSL (Secure Sockets Layer) protocol made it 67 vital for Web proxy servers to be able to tunnel requests performed 68 over SSL. The easiest, and perhaps the most elegant, way to 69 accomplish this is to extend the HTTP/1.x protocol [HTTP/1.0, 70 HTTP/1.1] in such a way that it will be able to intiate a tunnel 71 through the proxy server. 73 This document specifies the HTTP/1.x extension to implement the 74 generic TCP protocol tunneling on Web proxy servers. This extension 75 may be used between clients and proxy servers, and between two 76 proxies (in the case of daisy-chained proxies -- proxies that contact 77 other proxies to perform requests). This document focuses on the 78 differences and additions to HTTP/1.x; refer to the HTTP/1.x 79 specifications for a full specification of HTTP/1.x. 81 Note that the HTTPS protocol, which is just HTTP on top of SSL, could 82 alternatively be proxied in the same way that other protocols are 83 handled by the proxies: to have the proxy (instead of the client) 84 initiate the secure session with the remote HTTPS server, and then 85 perform the HTTPS transaction on the client's part. The response 86 will be received and decrypted by the proxy, and sent to the client 87 over (insecure) HTTP. This is the way FTP and Gopher get handled by 88 proxies. However, this approach has several disadvantages and 89 complications: 91 * The connection between the client and the proxy is normal HTTP, 92 and hence, not secure. This may, however, often be acceptable if 93 the clients are in a trusted subnetwork (behind a firewall). 95 * The proxy will need to have full SSL implementation incorporated 97 TCP PROTOCOL TUNNELING IN WEB PROXY SERVERS INTERNET-DRAFT August 1998 99 into it -- something this tunneling mechanism does not require. 101 * The client will not be able to perform SSL client authentication 102 (authentication based on X509 certificates) to the remote server, 103 as the proxy will be the authenticated party. Future versions of 104 SSL may, however, provide such delegated authentication. 106 This specification defines a tunneling mechanism for Web proxy 107 servers. This mechanism is compatible with HTTP/1.x protocol, which 108 is currently being used by Web proxies. 110 Note that this mechanism, if used for SSL tunneling, does not require 111 an implementation of SSL in the proxy. The SSL session is 112 established between the client generating the request, and the 113 destination (secure) Web server; the proxy server in between is 114 merely tunneling the encrypted data, and does not take any other part 115 in the secure transaction. 117 2. General Considerations with Respect to SSL Tunneling 119 When tunneling SSL, the proxy must not have access to the data being 120 transferred in either direction, for the sake of security. The proxy 121 merely knows the source and destination addresses, and possibly, if 122 the proxy supports user authentication, the name of the requesting 123 user. 125 In other words, there is a handshake between the client and the proxy 126 to establish the connection between the client and the remote server 127 through the proxy. In order to make this extension be backward 128 compatible, the handshake must be in the same format as HTTP/1.x 129 requests, so that proxies without support for this feature can still 130 cleanly determine the request as impossible for them to service, and 131 give proper error responses (rather than e.g. get hung on the 132 connection). 134 3. Functional Specification 136 3.1. Request 138 The client connects to the proxy server, and uses the CONNECT method 139 to specify the hostname and the port number to connect to. The 140 hostname and port number are separated by a colon, and both of them 141 must be specified. 143 TCP PROTOCOL TUNNELING IN WEB PROXY SERVERS INTERNET-DRAFT August 1998 145 The host:port part is followed by a space and a string specifying the 146 HTTP version number, e.g. HTTP/1.0, and the line terminator (CR LF 147 pair. Note that some applications may use just a LF on its own, and 148 it is recommended that applications be tolerant of this behavior. 149 When this document refers to CR LF pair, in all cases should a LF on 150 its own be treated the same as a CR LF pair). 152 After that there is a series of zero or more of HTTP request header 153 lines, followed by an empty line. Each of those header lines is also 154 terminated by the CR LF pair. The empty line is simply another CR LF 155 pair. 157 After the empty line, if the handshake to establish the connection 158 was successful, the tunnelled (SSL or other) data transfer can begin. 159 Before the tunneling begins, the proxy will respond, as described in 160 the next section (Section 3.2). 162 Example of an SSL tunneling request to host home.netscape.com, to 163 HTTPS port (443): 165 CONNECT home.netscape.com:443 HTTP/1.0 166 User-agent: Mozilla/4.0 168 ...data to be tunnelled to the server... 170 Note that the "...data to be tunnelled to the server..." is not a 171 part of the request. It is shown here only to make the point that 172 once the tunnel is established, the same connection is used for 173 transferring the data that is to be tunnelled. 175 The advantage of extending the HTTP/1.x protocol in this manner (a 176 new method) is that this protocol is freely extensible just like 177 HTTP/1.x is. For example, the proxy authentication may be used just 178 like with any other request to the proxy: 180 CONNECT home.netscape.com:443 HTTP/1.0 181 User-agent: Mozilla/4.0 182 Proxy-authorization: basic dGVzdDp0ZXN0 184 ...data to be tunnelled to the server... 186 3.2. Proxy Response 188 After the empty line in the request, the client will wait for a 189 response from the proxy. The proxy will evaluate the request, make 190 sure that it is valid, and that the user is authorized to request 191 such a connection. If everything is in order, the proxy will make a 193 TCP PROTOCOL TUNNELING IN WEB PROXY SERVERS INTERNET-DRAFT August 1998 195 connection to the destination server, and, if successful, send a "200 196 Connection established" response to the client. Again, the response 197 follows the HTTP/1.x protocol, so the response line starts with the 198 protocol version specifier, and the response line is followed by zero 199 or more response headers, followed by an empty line. The line 200 separator is CR LF pair. 202 Example of a response: 204 HTTP/1.0 200 Connection established 205 Proxy-agent: Netscape-Proxy/1.1 207 ...data tunnelled from the server... 209 After the empty line, the proxy will start passing data from the 210 client connection to the remote server connection, and vice versa. 211 At any time, there may be data coming from either connection, and 212 that data must be forwarded to the other connection immediately. 214 Note that since the tunnelled protocol is opaque to the proxy server, 215 the proxy cannot make any assumptions about which connection the 216 first, or any subsequent, packets will arrive. In other words, the 217 proxy server must be prepared to accept packets from either of the 218 connections at any time. Otherwise, a deadlock may occur. 220 If at any point either one of the peers gets disconnected, any 221 outstanding data that came from that peer will be passed to the other 222 one, and after that also the other connection will be terminated by 223 the proxy. If there is outstanding data to that peer undelivered, 224 that data will be discarded. 226 An example of a tunneling request/response in an interleaved 227 multicolumn format: 229 CLIENT -> SERVER SERVER -> CLIENT 230 -------------------------------------- ----------------------------------- 231 CONNECT home.netscape.com:443 HTTP/1.0 232 User-agent: Mozilla/4.0 233 <<< empty line >>> 234 HTTP/1.0 200 Connection established 235 Proxy-agent: Netscape-Proxy/1.1 236 <<< empty line >>> 237 <<< data tunneling to both directions begins >>> 239 3.2.1. Response Content-Type Field 240 TCP PROTOCOL TUNNELING IN WEB PROXY SERVERS INTERNET-DRAFT August 1998 242 The proxy response does not necessarily have a Content-Type field, 243 which is otherwise mandatory in HTTP/1.x responses. Currently there 244 is no content media type assigned to a tunnel. Future versions of 245 this specification may introduce a standard media type, for example 246 "application/tunnel". For forward compatibility, a Content-type 247 field should be allowed, but for backward compatibitity, one should 248 not be required by clients. 250 3.3. Data Pipelining 252 It is legal for the client to send some data intended for the server 253 before the "200 Connection established" (or any other success or 254 error code) is received. This allows for reduced latency and 255 increased efficiency when any handshake data intended for the remote 256 server can be sent in the same TCP packet as the proxy request. This 257 allows the proxy to immediately forward the data once the connection 258 to the remote server is established, without waiting for two round- 259 trip times to the client (sending 200 to client; waiting for the next 260 packet from client). 262 This means that the proxy server cannot assume that reading from the 263 client socket descriptor would only return the proxy request. 264 Rather, there may be any amount of opaque data following the proxy 265 request that must be forwarded to the server once the connection is 266 established. However, if the connection to the remote server fails, 267 or if it is disallowed by the proxy server, the data intended to the 268 remote server will be discarded by the proxy. 270 At the same time this means that a client pipelining data intended 271 for the remote server immediately after sending the proxy request (or 272 in the same packet), must be prepared to re-issue the request and 273 re-compose any data that it had already sent, in case the proxy fails 274 the request, or challenges the client for authentication credentials. 275 This is due to the fact that HTTP by its nature may require the 276 request to be re-issued, accompanied by authentication credentials or 277 other data that was either missing or invalid in the original 278 request. 280 Note that it is not recommended to pipeline more data than the amount 281 that can fit to the remainder of the TCP packet that the proxy 282 request is in. Pipelining more data can cause a TCP reset if the 283 proxy fails or challenges the request, and subsequently closes the 284 connection before all pipelined TCP packets are received by the proxy 285 server host. A TCP reset will cause the proxy server's response to 286 be discarded, and not be available to the client -- thus being unable 287 to determine whether the failure was due to a network error, access 288 control, or an authentication challenge. 290 TCP PROTOCOL TUNNELING IN WEB PROXY SERVERS INTERNET-DRAFT August 1998 292 4. Extensibility 294 The tunneling handshake is freely extensible using the HTTP/1.x 295 headers; as an example, to enforce authentication for the proxy the 296 proxy will simply use the 407 status code and the Proxy-authenticate 297 response header (as defined by the HTTP/1.x specification) to ask the 298 client to send authentication information: 300 HTTP/1.0 407 Proxy authentication required 301 Proxy-authenticate: ... 303 The client would then reperform the request, and send the 304 authentication information in the Proxy-authorization header: 306 CONNECT home.netscape.com:443 HTTP/1.0 307 User-agent: ... 308 Proxy-authorization: ... 310 ...data to be tunnelled to the server... 312 The full example displayed in an interleaved multicolumn format: 314 CLIENT -> SERVER SERVER -> CLIENT 315 -------------------------------------- ----------------------------------- 316 CONNECT home.netscape.com:443 HTTP/1.0 317 User-agent: Mozilla/4.0 318 <<< empty line >>> 319 HTTP/1.0 407 Proxy auth required 320 Proxy-agent: Netscape-Proxy/1.1 321 Proxy-authenticate: ... 322 <<< empty line >>> 323 CONNECT home.netscape.com:443 HTTP/1.0 324 User-agent: Mozilla/4.0 325 Proxy-authorization: ... 326 <<< empty line >>> 327 HTTP/1.0 200 Connection established 328 Proxy-agent: Netscape-Proxy/1.1 329 <<< empty line >>> 330 <<< data tunneling to both directions begins >>> 332 5. Multiple Proxy Servers 334 This specification applies equally to proxy servers talking to other 335 proxy servers. As an example, double firewalls make this necessary. 336 In this case, the inner proxy is simply considered a client with 338 TCP PROTOCOL TUNNELING IN WEB PROXY SERVERS INTERNET-DRAFT August 1998 340 respect to the outer proxy. 342 6. Security Considerations 344 The CONNECT tunneling mechanism is really a lower-level function than 345 the rest of the HTTP methods, kind of an escape mechanism for saying 346 that the proxy should not interfere with the transaction, but merely 347 forward the data. In the case of SSL tunneling, this is because the 348 proxy should not need to know the entire URI that is being accessed 349 (privacy, security), only the information that it explicitly needs 350 (hostname and port number) in order to carry out its part. 352 Due to this fact, the proxy cannot necessarily verify that the 353 protocol being spoken is really what it is supposed to tunnel (SSL 354 for example), and so the proxy configuration should explicitly limit 355 allowed connections to well-known ports for that protocol (such as 356 443 for HTTPS, 563 for SNEWS, as assigned by IANA, the Internet 357 Assigned Numbers Authority). 359 Ports of specific concern are such as the telnet port (port 23), SMTP 360 port (port 25) and many UNIX specific service ports (range 512-600). 361 Allowing such tunnelled connections to e.g. the SMTP port might 362 enable sending of uncontrolled E-mail ("spam"). 364 7. References 366 [HTTP/1.0] T. Berners-Lee, R. Fielding, and H. Frystyk. 367 Hypertext Transfer Protocol -- HTTP/1.0. 368 RFC 1945, MIT/LCS, UC Irvine, May 1996. 370 [HTTP/1.1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and 371 T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. 372 RFC 2068, UC Irvine, DEC, MIT/LCS, January, 1997. 374 [TLS] T. Dierks, C. Allen, A. O. Freier, P. L. Karlton, and P. Kocher. 375 The TLS (Transport Layer Security) Protocol. 376 Internet-Draft draft-ietf-tls-protocol-05.txt, 377 Consensus Development, Netscape Communications, 378 November 12, 1997. 380 [SSL] K. Hickman, T. Elgamal, "The SSL Protocol", 381 draft-hickman-netscape-ssl-01.txt, Netscape Communications 382 Corporation, June 1995. 384 [SSL3] A. O. Freier, P. Karlton, Paul C. Kocher, 385 "The SSL Protocol -- Version 3.0", 387 TCP PROTOCOL TUNNELING IN WEB PROXY SERVERS INTERNET-DRAFT August 1998 389 draft-ietf-tls-ssl-version3-00.txt, November 18, 1996. 391 8. Author's Address: 393 Ari Luotonen 394 Mail-Stop MV-068 395 Netscape Communications Corporation 396 501 East Middlefield Road 397 Mountain View, CA 94043 398 USA