From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8565.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc8565.txt (limited to 'doc/rfc/rfc8565.txt') diff --git a/doc/rfc/rfc8565.txt b/doc/rfc/rfc8565.txt new file mode 100644 index 0000000..c087fb8 --- /dev/null +++ b/doc/rfc/rfc8565.txt @@ -0,0 +1,619 @@ + + + + + + +Independent Submission E. Fokschaner +Request for Comments: 8565 1 April 2019 +Category: Informational +ISSN: 2070-1721 + + + Hypertext Jeopardy Protocol (HTJP/1.0) + +Abstract + + The Hypertext Jeopardy Protocol (HTJP) inverts the request/response + semantics of the Hypertext Transfer Protocol (HTTP). Using + conventional HTTP, one connects to a server, asks a question, and + expects a correct answer. Using HTJP, one connects to a server, + sends an answer, and expects a correct question. This document + specifies the semantics of HTJP. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not candidates for any level of Internet Standard; + see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8565. + +Copyright Notice + + Copyright (c) 2019 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + + + + + + +Fokschaner Informational [Page 1] + +RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 + 3. Comparison with HTTP . . . . . . . . . . . . . . . . . . . . 3 + 4. Response and Request Semantics . . . . . . . . . . . . . . . 4 + 4.1. Applicability of Postel's Robustness Principle . . . . . 4 + 4.2. Identifying the Server Associated with an HTJP Response . 5 + 4.3. Temporal Considerations . . . . . . . . . . . . . . . . . 5 + 4.4. Pseudo-Valid HTJP Messages . . . . . . . . . . . . . . . 6 + 4.5. HTTP Responses That Are Not Requestable . . . . . . . . . 6 + 5. Caches and Proxies . . . . . . . . . . . . . . . . . . . . . 7 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 7.1. Securing HTTP against HTJP . . . . . . . . . . . . . . . 7 + 7.1.1. Anti-HTJP-Nonce Header . . . . . . . . . . . . . . . 8 + 7.2. HTJPS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 + 8.2. Informative References . . . . . . . . . . . . . . . . . 10 + Appendix A. Hypertext Double Jeopardy Protocol . . . . . . . . . 11 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 + +1. Introduction + + The Hypertext Jeopardy Protocol (HTJP) 1.0 is a stateless + application-level response/request protocol that functions as the + semantic inverse of the Hypertext Transfer Protocol (HTTP) 1.1 . + + It can roughly be specified in relation to HTTP by the following + rules: + + o Where an HTTP client would send an HTTP request message, an HTJP + client would send an HTTP response message. + + o Where an HTTP server would send an HTTP response message, an HTJP + server would send an HTTP request message. + + o The HTTP request sent as an HTJP response should be an HTTP + request that (if sent to the appropriate HTTP server) would elicit + the HTTP response sent in the HTJP request. + + HTJP is compatible with the HTTP/1.1 specification, at least in + spirit, if not in letter. + + + + + + +Fokschaner Informational [Page 2] + +RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019 + + + HTJP has novel applications in all the following areas: + + o Generative automated testing of HTTP implementations and HTTP- + based applications. + + o Monitoring of HTTP-based applications in production. + + o Forensic and diagnostic reconstruction of HTTP requests from HTTP + response logs. + + o Discovery of first-party and third-party security vulnerabilities. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Comparison with HTTP + + It is a little-known fact that HTTP/1.1 already defines itself to be + its own inverse mode of operation. Section 3.1 of RFC 7230 + [RFC7230], which describes the start line of the HTTP message format, + states: + + In theory, a client could receive requests and a server could + receive responses, distinguishing them by their different start- + line formats, but, in practice, servers are implemented to only + expect a request [...] and clients are implemented to only expect + a response. + + It is only convention that HTTP clients send HTTP requests and that + HTTP servers send HTTP responses. Therefore, HTJP is just HTTP with + some alternative conventions. It is not a distinct protocol. + Furthermore, since all messages in HTJP are indistinguishable from + HTTP messages, an HTJP peer would have no way of identifying itself + explicitly as using HTJP rather than HTTP. + + Therefore, we describe HTJP as a "pseudo-protocol" in order to + distinguish clients, servers, and conversations that are using the + HTTP conventions laid out in this document from those that use + conventions that are more commonly associated with HTTP. + + + + + + + +Fokschaner Informational [Page 3] + +RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019 + + +4. Response and Request Semantics + + An HTJP request MUST be an HTTP response message. An HTJP response + message MUST be an HTTP request message that, if issued to the + appropriate HTTP server, would elicit the HTTP response specified by + the HTJP request being replied to. + + As described in Section 3, HTJP is unconventional but valid HTTP, and + so the entirety of the HTTP specification (as defined in [RFC7230], + [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235]) MUST be + respected when doing so is consistent with HTJP's unique semantics. + + The following example illustrates a typical message exchange for an + HTJP request concerning the same hypothetical server from Section 2.1 + of RFC 7230 [RFC7230]. + + Client request: + + HTTP/1.1 200 OK + Date: Mon, 27 Jul 2009 12:28:53 GMT + Server: Apache + Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT + ETag: "34aa387-d-1568eb00" + Accept-Ranges: bytes + Content-Length: 51 + Vary: Accept-Encoding + Content-Type: text/plain + + Hello World! My payload includes a trailing CRLF. + + Server response: + + GET /hello.txt HTTP/1.1 + Host: www.example.com + +4.1. Applicability of Postel's Robustness Principle + + Implementations of HTJP SHOULD respect Postel's Robustness Principle + [IAB-PROTOCOL-MAINTENANCE]. + + Applied to HTJP, Postel's Robustness Principle implies that, given + the choice of multiple valid HTJP responses for an HTJP request, one + SHOULD prefer a response that is more adherent to the HTTP standard + or uses fewer HTTP features. For example, sometimes a User-Agent + header has no bearing on the HTTP response from an HTTP server. On + seeing such a response in an HTJP request, an HTJP server could + validly respond with a practically unlimited number of permutations + on the User-Agent header value. However, it SHOULD prefer to respond + + + +Fokschaner Informational [Page 4] + +RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019 + + + with an HTTP request that has no User-Agent header whatsoever, in + keeping with Postel's Robustness Principle. + + The same consideration applies when encountering an HTJP request for + which there are both valid and "pseudo-valid" (Section 4.4) HTJP + responses available. + +4.2. Identifying the Server Associated with an HTJP Response + + It may be of interest to a user of HTJP to try issuing an HTJP + response as an HTTP request to the appropriate server. This brings + up the issue of correctly identifying the host to which the HTJP + response should be sent. Much of the time this will be able to be + determined from the Host header field of the HTJP response. The Host + header is required by conformant HTTP/1.1 requests. In the case that + the Host header is not present (for example, if the HTJP response is + an HTTP/1.0 request rather than HTTP/1.1), an HTJP response MAY use + the absolute URI form in the HTTP request line, to add clarity about + the target host if it would be validly accepted by the server. This + specific example is complicated by the fact that prior to HTTP/1.1 it + was not required that implementations accept the absolute URI form. + For this reason, it is also possible to phrase the HTJP response as + an HTTP request to a Forward Proxy server, which would have accepted, + indeed needed, the absolute URI request line prior to and after + HTTP/1.1. As a last resort, it may be possible to heuristically + derive the target host of an HTJP response from the HTJP request; for + example, the HTJP request may have absolute references to other HTTP + resources that seem to come from the same host. + +4.3. Temporal Considerations + + When an HTJP response is issued, there is no guarantee that, by the + time the response is received by an HTJP client, the HTTP server that + is associated with said response will still reply with it. Providing + any guarantee about "when" an HTTP server would reply with said + response is obviously a theoretically unsolvable problem and + therefore outside the scope of this HTJP specification. It is only + required that the HTJP response be correct at some point in the range + of the 32-bit Unix Timestamp; see "Seconds Since the Epoch" + (Section 4.16) of Unix General Concepts [UNIX-General-Concepts]. + + HTJP servers that are responding with an HTTP request for a volatile + resource, and with high confidence in the time range at which the + resource would be in the state described by the HTJP request, MAY add + a Date header to the HTJP response. This is in conformance with the + ability for HTTP requests to carry a Date header; see Section 7.1.1.2 + of [RFC7231]. + + + + +Fokschaner Informational [Page 5] + +RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019 + + + HTJP clients can try to demand more temporal certainty by adding a + Date header to their HTTP response, embedding criteria for the time + of the HTTP response in the HTTP response itself. Of course, the + client might still only receive that exact HTTP response if it + manages to deliver the HTTP request at the precise time of the + previously requested Date header, and even then it is still not + guaranteed due to HTTP caching et cetera. + +4.4. Pseudo-Valid HTJP Messages + + In the wild, HTTP clients and servers have been known to occasionally + exchange HTTP messages that are not conformant to any HTTP + specification. For this reason, we will identify a class of messages + that are, on the one hand, invalid HTTP messages, yet at the same + time, correctly answerable HTJP requests or correct answers to an + HTJP request, as "pseudo-valid" HTJP messages. + + Consider, for example, an HTTP server that erroneously reports a + Content-Length header field of zero when sending an HTTP payload of + non-zero length. Despite this HTTP message violating the HTTP + specification, it is possible for an HTJP server to receive such a + message and correctly respond to it, satisfying the HTJP semantics in + doing so. + + This applies to both HTJP requests and HTJP responses. There may be + times when the only valid HTJP response is an invalid HTTP request. + When there are both valid and invalid HTTP requests that could + satisfy the HTJP request, Postel's Robustness Principle SHOULD be + applied, as described in Section 4.1. + +4.5. HTTP Responses That Are Not Requestable + + Given that an HTJP response MUST be an HTTP request, and that HTTP + requests do not have a status field (such as a status code), there is + no way for an HTJP response to signal a failure in response to an + HTJP request, via a status code or otherwise. The correct HTJP + response to an HTJP request when a server cannot determine an HTTP + request that elicits the HTTP response is to not respond at all. The + HTJP responder MAY close the connection; however, the HTJP requester + MUST NOT interpret the closing of the connection as a response. This + can have issues when HTJP servers are hosted behind non-HTJP-aware + HTTP proxies, as the proxy may inject a 5xx HTTP response, which + could be misinterpreted as an HTJP response. See more on proxies in + Section 5. + + + + + + + +Fokschaner Informational [Page 6] + +RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019 + + +5. Caches and Proxies + + Despite being valid HTTP traffic, support for caching and proxying of + HTJP traffic is unfortunately not widespread. It is estimated that + currently approximately 0.0% of all HTTP-aware intermediaries + gracefully handle HTJP traffic. For this reason, it is currently + RECOMMENDED that HTJP should not be deployed behind an HTTP proxying + or caching layer. Support will likely increase proportionally to + HTJP's popularity in production. + +6. IANA Considerations + + In order that implementations of this specification can operate + correctly, and in accordance with [BCP90], the following new HTTP + header field would need to be registered in the "Message Headers" + registry maintained at + . To find out the + details of this registration, an application should send an HTJP + request to a suitable server specifying the Anti-HTJP-Nonce value + that the server would have supplied had the IANA registration been + made. + + +-------------------+----------+---------------+---------------+ + | Header Field Name | Protocol | Status | Reference | + +-------------------+----------+---------------+---------------+ + | Anti-HTJP-Nonce | http | informational | Section 7.1.1 | + +-------------------+----------+---------------+---------------+ + +7. Security Considerations + +7.1. Securing HTTP against HTJP + + An incomplete implementation of HTJP is inadvisable from a security + perspective. A complete implementation of HTJP may have interesting + security features that are worthy of detailed examination. Due to + its semantics, the issuing of a successfully authorized HTTP response + to an HTJP server will result in a reply containing the HTTP request + that elicits said response, including any credentials, tokens, + cookies, or other authorization materials that were required to + elicit that response. + + + + + + + + + + + +Fokschaner Informational [Page 7] + +RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019 + + + As an example: + + Client request: + + HTTP/1.1 200 OK + Date: Mon, 27 Jul 2009 12:28:53 GMT + Content-Length: 61 + Content-Type: text/plain + + Some predictable information accessed using authorization. + + Server response: + (line breaks in the Authorization header are for RFC formatting) + + GET /information.txt HTTP/1.1 + Host: authorised-usage-service.example.com + Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. + eyJzdWIiOiJodGpwIiwibmFtZSI6IkV2ZXJ5b25lIiwiaWF0IjowfQ. + JOL-kIObgTI0MzFfm1yVFFkIo1xf7DZGjY_oedRBZW0 + + Given that we cannot prevent anyone from attempting to implement + HTJP, it is RECOMMENDED to consider how HTJP impacts security when + using HTTP. + + Note that it was only possible to query for the credentialed HTTP + request because the response to the authorized request was + predictable. HTTP servers could mitigate this vulnerability exposed + by HTJP by only serving a response that is at least as secret as the + credentials themselves in response to an authorized request. + +7.1.1. Anti-HTJP-Nonce Header + + A generic solution to this problem is to use an "Anti-HTJP-Nonce" + HTTP header in HTTP responses. The value of an "Anti-HTJP-Nonce" + header SHOULD be a cryptographically secure random number in any + encoding that is valid for an HTTP header value. The length of this + number SHOULD be determined by the producer of the HTTP response, + accounting for their method of random number generation and their + threat model. + +7.2. HTJPS + + HTJP, being just HTTP, has most of the same security concerns and + features as HTTP itself. For example, the use of HTJP over an + encrypted connection, such as TLS 1.3 [RFC8446], similar to HTTP + Secure (HTTPS), is referred to as HTJP Secure (HTJPS). However, it + is important to note that, unlike with HTTPS, it is not expected that + the hostname you are securely communicating with is the same hostname + + + +Fokschaner Informational [Page 8] + +RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019 + + + as featured in the Host headers or absolute URIs of the HTJP messages + themselves, as HTJP messages are typically referring to other HTTP + hosts. This excludes the case of a server that supports both + conventional HTTP and HTJP, where it is possible to make HTJP + requests securely to the same host that is also the subject of the + HTJP requests being made. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + . + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + DOI 10.17487/RFC7231, June 2014, + . + + [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Conditional Requests", RFC 7232, + DOI 10.17487/RFC7232, June 2014, + . + + [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., + "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", + RFC 7233, DOI 10.17487/RFC7233, June 2014, + . + + [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", + RFC 7234, DOI 10.17487/RFC7234, June 2014, + . + + [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Authentication", RFC 7235, + DOI 10.17487/RFC7235, June 2014, + . + + + + + + +Fokschaner Informational [Page 9] + +RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019 + + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [UNIX-General-Concepts] + "General Concepts", Chapter 4 of "The Open Group Base + Specifications, Issue 7", 2018 edition, IEEE + Std 1003.1-2017, 2018, . + +8.2. Informative References + + [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004, . + + [IAB-PROTOCOL-MAINTENANCE] + Thomson, M., "The Harmful Consequences of the Robustness + Principle", Work in Progress, draft-iab-protocol- + maintenance-02, March 2019. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fokschaner Informational [Page 10] + +RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019 + + +Appendix A. Hypertext Double Jeopardy Protocol + + Also worth mentioning, in case one encounters it in the wild, is the + Hypertext Double Jeopardy Protocol (HTJ2P). The Hypertext Double + Jeopardy Protocol 1.0 is a stateless application-level request/ + response protocol that functions as the inverse of the Hypertext + Jeopardy Protocol (HTJP) 1.0 . + + An HTJ2P response MUST be an HTTP response which would be issued for + an HTTP request delivered as the HTJ2P request. Implementations of + HTJ2P have groundbreaking potential in the fields of HTTP caching, + and in the implementation of HTJP. + +Acknowledgements + + The author thanks Alex Trebek for his distinguished contributions to + culture and society. The author thanks Peter Phillips for the + suggestion of the Anti-HTJP-Nonce header. The author also wishes to + thank anyone who has ever built a tool or a technology that made + people ask "Why?". + +Author's Address + + Edmund Fokschaner + + Email: edfokschaner@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + +Fokschaner Informational [Page 11] + -- cgit v1.2.3