Internet DRAFT - draft-belingueres-http-tls-filter
draft-belingueres-http-tls-filter
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.
<draft-ietf-tls-https-04.txt>
5 Khare, R., Lawrence, S., "Upgrading to TLS within HTTP/1.1",
Internet-Draft, Work in Progress. <draft-ietf-tls-http-upgrade-
04.txt>
6 Belingueres, G., "TCP Security Filter", Internet-Draft, Work in
Progress. <draft-belingueres-tcpsec-00.txt>
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. <draft-bellovin-tcpfilt-00.txt>
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]
