Network Working Group G. Belingueres Internet-Draft Independent Consultant Expires: May 23, 2000 November 23, 1999 HTTP over TLS using a TCP Filter draft-belingueres-http-tls-filter-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 1. Abstract This document explains how to use the TCP Security Filter mechanism to initiate a Transport Layer Security (TLS) session to secure HTTP connections over the Internet. 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). As an additional point, a similar mechanism like the described here could be used to provide other different kind of layers to HTTP connections. 2. Introduction The popular HTTP [2] protocol is used in the clear over the Internet. That means that it provides an insecure channel to deliver their messages. The common technique to secure HTTP traffic is to use SSL (or their successor, TLS) [3] as a virtual transport layer for HTTP messages. This distinction among secure and insecure traffic is Belingueres Expires Mayo 23, 2000 [Page 1] Internet-Draft HTTP over TLS using a TCP Filter November 1999 accomplished by providing two different services (i.e. tow different port numbers are used). This is the approach given in [4], and what is in use at the present time. The advantage is that it is simple. The disadvantage is that an application protocol requiring transport their data over TLS requires an extra port number available. Other way to require the secure virtual transport layer presence is extending the HTTP protocol definition to indicate that requirement. This is the approach taken in [5]. The advantage (among others) is it can share the same well known port for both kind of services. The disadvantage is it requires to extend the application protocol, taken care that defined message semantics don't be misused, confused or invalidated by new extensions. I present here another method to activate secure HTTP connections, based on the agreement of a TCP Security filter [6] at the moment of creating the TCP [7] connection. If the agreed security filter is of type "TLS Family", then the HTTP protocol deliver their messages using the TLS protocol as the secure virtual transport layer. This means that both secure and insecure HTTP connections share the same port. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [8]. 3. Connection setting When a client request a secure connection to an URI like https://www.example.com, it SHALL open a new TCP connection to the well known port 80, setting as a TCP Security filter the "TLS Family" code. After the 3-way handshake for opening a TCP connection, both parties known what TCP filters are agreed, as defined in [9]. If such a filter is the "TLS Family" one, then the client immediately MUST begin the TLS handshake with the TLS' ClientHello message. If the TCP connection has no option returned from the server, then a security layer can not be instantiated and proper feedback SHOULD be provided to the user; in this case the connection SHOULD be reseted. Since the TCP Security Filter defines a family of protocols, the actual protocol instantiated MUST be one of the defined by the TLS Family option, i.e. SSL 2.0, SSL 3.0 or TLS 1.0. As that protocols provide backward compatibility, is sufficient to send the ClientHello message with the highest TLS version number possible. In the other hand, the HTTP server is waiting for a connection. After finishing the 3-way handshake, it checks for the TCP filters agreed. If no option is set, then the server MUST proceed as a normal HTTP Belingueres Expires May 23, 2000 [Page 2] Internet-Draft HTTP over TLS using a TCP Filter November 1999 connection, as defined in [2]. If the "TLS Family" option is agreed, the server has to left the connection in hands of the TLS protocol to perform the TLS handshake. Once done with the TLS handshake, the HTTP server can continue with their normal behavior, as defined in [4]. If a TCP option encountered by the either the server or the client is not supported, it MUST be reported as an error, and the TCP connection SHOULD be reseted. 4. HTTP over TLS behavior After the connection as been established as pointed by the above section, both the server and client MUST behave as described in [4]. 5. Forward Compatibility and Layering Since TCP filters can be layered in any way, it could happen that additional filters could be required by an HTTP connection. In that case, either the additional filters position above or below the TLS protocol, it must define its own opening and closing semantics, taken care of security risks that special combinations could arise. Also, as the quantity of filters become higher than 1, not all permutations of TCP filters will have sense to apply. The HTTP protocol will have to check the filter list of that open connection for permutations of filters that are correct. Out-of-order list of filters SHOULD cause that connection to reset. 6. Security Considerations Indicating the need of open a secure connection with an HTTP server using a Security filter should not cause security weakness on HTTP nor TLS. Man-in-the-middle attacks are detectable, as the parties could be adequately authenticated by TLS, as [4] specifies. As a final note, this document does not analyses the security provided by the TLS protocol instantiated. 9. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Fielding, R. et. al., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Belingueres Expires May 23, 2000 [Page 3] Internet-Draft HTTP over TLS using a TCP Filter November 1999 3 Allen, C., and Dierks, T., "Transport Layer Security Protocol v1.0", RFC 2246, January 1999. 4 Rescorla, E., "HTTP over TLS", Internet-Draft, Work in Progress. 5 Khare, R., Lawrence, S., "Upgrading to TLS within HTTP/1.1", Internet-Draft, Work in Progress. 6 Belingueres, G., "TCP Security Filter", Internet-Draft, Work in Progress. 7 Postel, J., "Transport Control Protocol", STD 7, RFC 793, September 1981. 8 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9 Bellovin, S. et. al., "TCP Filters", Internet-Draft, Work in Progress. 10. Acknowledgments 11. Author's Addresses Gabriel Belingueres Independent Consultant Ines Indart, CP 2747, Argentina Email: gaby@ieee.org Belingueres Expires May 23, 2000 [Page 4] Internet-Draft HTTP over TLS using a TCP Filter November 1999 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. 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. Belingueres Expires May 23, 2000 [Page 5]