FYI,
this should also show up as an I-D shortly.
Carl-Uno
--
>Subject: Repost: Upgrading to TLS within HTTP
>Date: Mon, 16 Mar 1998 15:50:05 PST
>From: Rohit Khare <rohit at bordeaux.ics.uci.edu>
>>>Upgrading to TLS Within HTTP
>> _Rohit Khare_, UC Irvine, March 16, 1998
>> _________________________________________________________________
>> 0. Motivation
>> At the [1]Washington DC IETF meeting last year, the Applications Area
> Directors indicated they would like to see a mechanism for applying
> Transport Layer Security [TLS] within an [2]HTTP connection, at the
> same port, instead of only being able to recommend a distinct port
> (443) and scheme (https). The TLS working group has moved forward with
> an extensive draft on properly implementing https
> ([3]draft-ietf-tls-https-00), but there is alternate precedent in SMTP
> and other applications of TLS ([4]draft-hoffman-smtp-ssl,
> [5]draft-newman-tls-imappop-03, [6]murray-auth-ftp-ssl-00).
>> There has already been extensive debate on the [7]http-wg ,
> [8]ietf-tls and [9]ietf-apps-tls mailing lists about the advisability
> of permitting optional 'upgrades' to secure connections within the
> same channel, primarily focusing on the thread of man-in-the-middle
> attacks. Our intent here is not to engage in this debate, but merely
> to document a proposed mechanism for doing either with HTTP. Several
> applications being built upon HTTP might use this mechanism, such as
> the [10]Internet Printing Protocol; we look to them for implementation
> guidance.
>> 1. Introduction
>> 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.
>> The need to 'secure' running connections is not merely 'running SSL
> over port 80', an early challenge for firewall developers answered by
> Ari Luotonen's [11]ssl-tunneling-02 draft in 1995. The HTTP/1.1 spec
> reserves CONNECT for future use, deferring to the more recent
> [12]draft-luotonen-web-proxy-tunneling-00 proposal. This technique
> perpetuates the concept that security is indicated by a magic port
> number -- CONNECT establishes a generic TCP tunnel, so port number is
> the only way to specify the layering of TLS with HTTP (https) or with
> NTTP (snews).
>> Instead, the preferred mechanism to initiate and insert TLS in an
> HTTP/1.1 session should be the Upgrade: header, as defined in section
> 14.42 of rev-03. Ideally, TLS-capable clients should add "Upgrade:
> TLS/1.0" to their initial request, and TLS-capable servers may reply
> with "101 Switching Protocol", complete the handshake, and continue
> with the "normal" response to the original request. However, the
> specification quoth:
>> "The Upgrade header field only applies to switching
> application-layer protocols upon the existing transport-layer
> connection."
>> Aside from this minor semantic difference -- invoking TLS indeed
> changes the existing transport-layer connection -- this is an ideal
> application of Upgrade. This technique overlays the TLS-request on an
> HTTP method; requires client-initiation, and allows servers to choose
> whether or not to make the switch. Like the other examples of
> TLS-enabled application protocols, the original session is preserved
> across the TLS handshake; secured communications resumes with a
> servers' reply.
>> The potential for a man-in-the-middle attack (wherein the "TLS/1.0"
> upgrade token is stripped out) is precisely the same as for mixed
> http/https use:
>> 1. Removing the token is similar to rewriting web pages to change
> https:// links to http:// links.
> 2. The risk is only present if the server is willing to vend that
> information over an insecure channel in the first place
> 3. If the client knows for a fact that a server is TLS-compliant, it
> can insist on it by only connecting as https:// or by only sending
> an upgrade request on a no-op method like OPTIONS.
>> Furthermore, for clients which do not actively try to invoke TLS,
> servers can use Upgrade: to advertise TLS compliance, too. 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.
>> 2. Potential Solution
>> Define "TLS/x.y" as a reference to the TLS specification
> ([13]draft-ietf-tls-protocol-03), with x and y bound to its major and
> minor version numbers. Section 6.2.1 of the current draft explains why
> the TLS version would currently be defined as 1.0, not the actual
> parameters on the wire (which is "3.1" for backwards compatibility
> with SSL3).
>> An HTTP client may initiate an upgrade by sending "TLS/x.y" as one of
> the field-values of the Upgrade: header. The origin-server MAY respond
> with "101 Switching Protocols"; if so it MUST include the header
> "Upgrade: TLS/x.y" to indicate what it is switching to.
>> Servers which can upgrade to TLS MAY include the header "TLS/x.y" in
> an Upgrade response header to inform the client; servers SHOULD
> include such indication in response to any OPTIONS request.
>> Similarly, servers MAY require clients to switch to TLS first by
> responding with a new error code "418: Upgrade Required", which MUST
> specify the protocol to be supported. @@ This is a change to 'core'
> HTTP; if, processwise, it's too difficult to slip in a general-purpose
> error code, we may have to fall-back to "418: TLS Required".
>> Upgrade is a hop-by-hop header (Section 13.5.1), so each intervening
> proxy which supports TLS MUST also request the same version of TLS/x.y
> on its subsequent request. Furthermore, any caching proxy which
> supports TLS MUST NOT reply from its cache when TLS/x.y has been
> requested (although clients are still recommended to explicitly
> include "Cache-control: no-cache").
>> Note: proxy servers may be able to request or initiate a TLS-secured
> connection, e.g. the outgoing or incoming firewall of a trusted
> subnetwork.
>> 3. Next Steps
>> I could proceed by formalizing Section 2 as an Internet-Draft, but
> under the jurisdiction of which IETF working group? Furthermore, I do
> not have access nor personal interest in a TLS-capable client/server
> pair to experiment with.
>> N.B. I believe this work is completely separate from HTTP-extension
> work proceeding in the web evolution / http-extension working group.
> This uses Upgrade for its stated purpose -- to switch to an entirely
> different protocol -- not to define or modify HTTP methods and
> semantics.
>> Please watch [14]http://www.ics.uci.edu/~rohit/http-tls for updates of
> this document and any Internet-Drafts relating to this proposal.
>> 4. Acknowledgments
>> Thanks to Paul Hoffman for his work on the STARTTLS command extension
> for ESMTP. Thanks to Roy Fielding for assistance with the rationale
> behind Upgrade: and OPTIONS.
>> 5. References
>>References
>> 1. http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q4/0495.html> 2.
http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-03.txt
> 3. http://ds.internic.net/internet-drafts/draft-ietf-tls-https-00.txt> 4. http://www.imc.org/ietf-apps-tls/draft-hoffman-smtp-ssl> 5. http://ds.internic.net/internet-drafts/draft-newman-tls-imappop-03.txt> 6. http://www.consensus.com/ietf-tls/murray-auth-ftp-ssl-00.txt> 7. http://www.ics.uci.edu/pub/ietf/http/> 8. http://www.consensus.com/ietf-tls/> 9. http://www.imc.org/ietf-apps-tls/> 10. http://www.pwg.org/ipp/index.html> 11. http://www.consensus.com/ietf-tls/ssl-tunneling-02.txt> 12.
http://ds.internic.net/internet-drafts/draft-luotonen-web-proxy-tunneling-00
.txt
> 13. http://www.consensus.com/ietf-tls/tls-protocol-03.txt> 14. http://www.ics.uci.edu/~rohit/http-tls>>