determine if it meets their expectations".





 
RFC 2817                  HTTP Upgrade to TLS                   May 2000


   Furthermore, for clients that do not explicitly try to invoke TLS,
   servers can use the Upgrade header in any response other than 101 or
   426 to advertise TLS compliance. 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.

8.1 Implications for the https: URI Scheme

   While nothing in this memo affects the definition of the 'https' URI
   scheme, widespread adoption of this mechanism for HyperText content
   could use 'http' to identify both secure and non-secure resources.

   The choice of what security characteristics are required on the
   connection is left to the client and server.  This allows either
   party to use any information available in making this determination.
   For example, user agents may rely on user preference settings or
   information about the security of the network such as 'TLS required
   on all POST operations not on my local net', or servers may apply
   resource access rules such as 'the FORM on this page must be served
   and submitted using TLS'.

8.2 Security Considerations for CONNECT

   A generic TCP tunnel is fraught with security risks. First, such
   authorization should be limited to a small number of known ports.
   The Upgrade: mechanism defined here only requires onward tunneling at
   port 80. Second, since tunneled data is opaque to the proxy, there
   are additional risks to tunneling to other well-known or reserved
   ports. A putative HTTP client CONNECTing to port 25 could relay spam
   via SMTP, for example.

References

   [1]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
        Leach, 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. Jensen,
        "Web Distributed Authoring and Versioning", RFC 2518, February
        1999.






 
RFC 2817                  HTTP Upgrade to TLS                   May 2000


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

Authors' Addresses

   Rohit Khare
   4K Associates / UC Irvine
   3207 Palo Verde
   Irvine, CA  92612
   US

   Phone: +1 626 806 7574
   EMail: rohit@4K-associates.com
   URI:   http://www.4K-associates.com/