RFC 2818

HTTP Over TLS

📅 published May 2000, from ietf

RFC 2818: HTTP Over TLS 🎀

Okay bestie, here's the title block first. This is RFC 2818, titled HTTP Over TLS. It's from the Network Working Group, and the author is E. Rescorla of RTFM, Inc. 💅 It's Informational, dated May 2000. The title block doesn't list anything it obsoletes or updates.

Status of This Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 📜

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🌸

Okay so this doc explains how to use TLS to lock down HTTP connections across the Internet. The current move is to stack HTTP on top of SSL (the older version that came before TLS), and you tell the secure traffic apart from the insecure stuff by using a different server port. This document writes that practice down, but with TLS. There's also a companion doc, [RFC2817], that describes a way to run HTTP/TLS on the same port as normal HTTP. 🦋

Table of Contents 📚

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . 2
   1.1. Requirements Terminology  . . . . . . . . . . . . . . . 2
   2. HTTP Over TLS . . . . . . . . . . . . . . . . . . . . . . 2
   2.1. Connection Initiation . . . . . . . . . . . . . . . . . 2
   2.2. Connection Closure  . . . . . . . . . . . . . . . . . . 2
   2.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 3
   2.2.2. Server Behavior . . . . . . . . . . . . . . . . . . . 3
   2.3. Port Number . . . . . . . . . . . . . . . . . . . . . . 4
   2.4. URI Format  . . . . . . . . . . . . . . . . . . . . . . 4
   3. Endpoint Identification . . . . . . . . . . . . . . . . . 4
   3.1. Server Identity . . . . . . . . . . . . . . . . . . . . 4
   3.2. Client Identity . . . . . . . . . . . . . . . . . . . . 5
   References . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Security Considerations  . . . . . . . . . . . . . . . . . . 6
   Author's Address . . . . . . . . . . . . . . . . . . . . . . 6
   Full Copyright Statement . . . . . . . . . . . . . . . . . . 7

1. Introduction 🌈

So HTTP [RFC2616] was originally sent in the clear on the Internet. 🙈 But people started using HTTP for sensitive stuff, so it needed real security. SSL, and its successor TLS [RFC2246], were built to give you channel-oriented security. This document explains how to run HTTP over TLS. ✨

1.1. Requirements Terminology 👑

The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be read as described in [RFC2119]. 🧚

2. HTTP Over TLS 💜

Honestly, HTTP/TLS is very simple. You just use HTTP over TLS exactly the way you'd use HTTP over TCP. It's giving "same thing, but safer" 🫶

2.1. Connection Initiation 🚪

The agent acting as the HTTP client should also act as the TLS client. It should open a connection to the server on the right port and then send the TLS ClientHello to kick off the TLS handshake. When the TLS handshake has finished. The client may then start its first HTTP request. All HTTP data MUST be sent as TLS "application data". Normal HTTP behavior, including retained connections, should be followed. 💅

2.2. Connection Closure 🔐

TLS has a built-in way to close a connection securely. When a valid closure alert arrives, an implementation can be sure that no more data will show up on that connection. TLS implementations MUST start an exchange of closure alerts before they close a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its own closure alert, which creates an "incomplete close". Note that an implementation doing this MAY choose to reuse the session. This SHOULD only happen when the application knows (usually by spotting HTTP message boundaries) that it has received all the message data it cares about. 🦋

As specified in [RFC2246], any implementation that gets a connection close without first getting a valid closure alert (a "premature close") MUST NOT reuse that session. Here's the tea: a premature close doesn't mean the data already received is insecure. It just means the data coming later might have been cut off. ☕ Because TLS doesn't care about HTTP request/response boundaries, you have to look at the HTTP data itself (specifically the Content-Length header) to figure out whether the cut happened inside a message or between messages. 🔍

2.2.1. Client Behavior 💖

Since HTTP uses connection closure to mark the end of server data, client implementations MUST treat any premature closes as errors and treat the data received as possibly truncated. In some cases HTTP lets the client find out whether truncation happened, so if it got the complete reply, it may tolerate such errors, following the principle to "[be] strict when sending and tolerant when receiving" [RFC1958]. But often truncation doesn't show up in the HTTP protocol data. Two cases deserve special attention:

  • An HTTP response without a Content-Length header. Since the data length is signalled by connection close, a premature close generated by the server cannot be told apart from a spurious close generated by an attacker. 😱
  • An HTTP response with a valid Content-Length header that gets closed before all the data has been read. Because TLS does not provide document oriented protection, it is impossible to determine whether the server has miscomputed the Content-Length or an attacker has truncated the connection. 💀

There is one exception to the rule above. When a premature close happens, a client SHOULD treat as completed all requests for which it has received as much data as the Content-Length header specifies. ✨

A client that detects an incomplete close SHOULD recover gracefully. It MAY resume a TLS session closed in this fashion. 🌸

Clients MUST send a closure alert before closing the connection. Clients that aren't ready to receive any more data MAY choose not to wait for the server's closure alert and just close the connection, which generates an incomplete close on the server side. 🙌

2.2.2. Server Behavior 🖥️

RFC 2616 lets an HTTP client close the connection at any time, and it requires servers to recover gracefully. 🫠 In particular, servers SHOULD be ready to receive an incomplete close from the client, since the client can often tell when the end of server data is. Servers SHOULD be willing to resume TLS sessions closed in this fashion. 💅

Implementation note: in HTTP implementations that don't use persistent connections, the server normally expects to be able to signal the end of data by closing the connection. When Content-Length is used, though, the client may already have sent the closure alert and dropped the connection. 🍓

Servers MUST attempt to start an exchange of closure alerts with the client before closing the connection. Servers MAY close the connection after sending the closure alert, which generates an incomplete close on the client side. 🫶

2.3. Port Number 🔌

The first data an HTTP server expects from the client is the Request-Line production. The first data a TLS server (and therefore an HTTP/TLS server) expects is the ClientHello. So the common practice has been to run HTTP/TLS on a separate port to tell which protocol is in use. When HTTP/TLS runs over a TCP/IP connection, the default port is 443. This doesn't rule out running HTTP/TLS over another transport. TLS only assumes a reliable, connection-oriented data stream. 🎀

2.4. URI Format 🔗

HTTP/TLS is told apart from HTTP URIs by using the 'https' protocol identifier in place of the 'http' one. Here's an example URI that specifies HTTP/TLS:

https://www.example.com/~smith/home.html

3. Endpoint Identification 🕵️‍♀️

3.1. Server Identity 🪪

Generally, HTTP/TLS requests come from dereferencing a URI, so the client already knows the server's hostname. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, to prevent man-in-the-middle attacks. 🛡️

If the client has outside information about the server's expected identity, the hostname check MAY be skipped. (For example, a client might be connecting to a machine whose address and hostname are dynamic, but the client knows the certificate the server will present.) In those cases it's important to narrow down the acceptable certificates as much as possible, to prevent man-in-the-middle attacks. In special cases it may be appropriate for the client to just ignore the server's identity, but it must be understood that this leaves the connection open to active attack. 😬

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Using the Common Name is existing practice, but it's deprecated, and Certification Authorities are encouraged to use the dNSName instead. 📢

Matching is done using the matching rules specified in [RFC2459]. If more than one identity of a given type is in the certificate (for example, more than one dNSName), a match against any one of the set is considered acceptable. Names may contain the wildcard character *, which is considered to match any single domain name component or component fragment. For example, *.a.com matches foo.a.com but not bar.foo.a.com. And f*.com matches foo.com but not bar.com. 🌟

Sometimes the URI is given as an IP address instead of a hostname. In that case, the iPAddress subjectAltName must be present in the certificate, and it must exactly match the IP in the URI. 🔢

If the hostname doesn't match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the chance to continue with the connection anyway) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if one is available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but they MUST provide a setting that enables it. ⚠️

Heads up, bestie: the URI itself often comes from an untrusted source, and the check above gives no protection if that source has been compromised. For example, if the URI came from clicking a link on an HTML page that was itself fetched without HTTP/TLS, a man in the middle could have swapped the URI out. To stop this kind of attack, users should carefully examine the certificate the server presents to see whether it meets their expectations. 🚨

3.2. Client Identity 🪞

Usually the server has no outside knowledge of what the client's identity ought to be, so checks (beyond confirming that the client has a certificate chain rooted in an appropriate CA) aren't possible. If a server does have that knowledge (typically from some source outside HTTP or TLS), it SHOULD check the identity as described above. 🫶

References 📚

Okay bestie, the reading list is here, and every single source is listed with all its details so you can go find them yourself 🧚

  • [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile", RFC 2459, January 1999. 🔐
  • [RFC2616] 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. 🌐
  • [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💜
  • [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999. 🎀
  • [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. ✨

Security Considerations 💀

Okay, this one is dramatic and I love that for us. This entire document is about security. Like, the whole thing. 🙈🔥

Author's Address 🦋

This one was written by Eric Rescorla, and here's where to reach him:

Eric Rescorla
RTFM, Inc.
30 Newell Road, #16
East Palo Alto, CA 94303

Phone: (650) 328-8631
EMail: ekr@rtfm.com

Now the legal part. I'm keeping the wording exactly as written because it's a notice and it has to stay complete, no cap. 🫶

Copyright (C) The Internet Society (2000).  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.

Acknowledgement 🧚‍♀️

Last but not least, the RFC Editor function is currently funded by the Internet Society. Thank you to them for keeping the lights on, periodt. 👑✨

📦 where this page comes from