Trusted Linker Download Redirection (TLDR)

Transport Layer Security (TLS/SSL) can add an often much needed level of security to the Hypertext Transfer Protocol (HTTP) (a combination normally referred to as HTTPS) but the encryption algorithms are often too much of a strain for busy public file download servers, especially when arguably the data stream does not really need to be encrypted (the files are publicly accessible anyway). As a result, servers providing public file downloads, even potentially dangerous file types such as those with executable code, scripts, etc., often do not deliver the files using HTTPS. However, this makes the downloads vulnerable to Man-in-the-Middle (MitM) attacks; an attacker could change the data during transit to serve the client with malware. Trusted Linker Download Redirection (TLDR) describes a process by which an (assumed trustworthy) HTTPS URL can redirect to a non-HTTPS download URL and give the user agent extra information about the file so that, once downloaded, the agent can check whether the file is the same one that the trustworthy site verified.

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 The URL that provides the TLDR HTTP headers as it redirects the user agent to a new URL (using the "Location:" header). The URL that the trusted linker redirects to. Will be identical to 'Final Destination' unless the Link redirects elsewhere. The final URL (not necessarily using HTTP) that provides the file data (may be identical to "The link")

The TLDR headers SHOULD only be sent by the Trusted Link web server with responses that use one of the following HTTP status codes: 302 "Found" 303 "See Other" 307 "Temporary Redirect" Note that the permanent redirects (such as 301 "Moved Permanently" and 308 "Permanent Redirect") are not included in the list. These status codes instruct user agents to send all future requests to the URL provided in the "Location" header, thereby bypassing the Trusted Linker completely. It seems nonsensical to provide a TLDR service for the user agent's first request only!

Ideally, servers implementing TLDR should do so over the HTTPS protocol and not plain HTTP. If the headers are delivered without the safety that TLS/SSL provides, TLDR cannot detect Man in the Middle (MitM) attacks. However, it does provides a bit of extra protection if used over plain HTTP assuming no MitM. For example, if the Final Destination server becomes compromised or for any other reason starts providing a different file to the one that it was before, the checksum will not match and this will be detected.

These HTTP response headers are all OPTIONAL but a web server must provide at least one to be a Trusted Linker. It should provide as many of them as possible in order to give user agents the biggest choice. To avoid ambiguity, a web server MUST NOT return more than one TLDR header with the same name. When more than one checksum is provided by the server, it is not recommended for a user agent to use more than one of the checksums provided. It should select one; preferably the checksum function considered most secure at the time. The method by which the user agent selects a hash function MAY be user configurable. All checksums are calculated on the complete file contents. If the file is delivered to the client using any kind of transfer encoding (such as HTTP gzip, chunked, etc.), the checksums MUST be calculated on the decoded data. Any kind of transfer mechanism that results in ambiguous output data (such as "ASCII mode" FTP) is not supported. The examples given below each show the server replying with a different value for the HTTP status code. This is just to illustrate the different codes that can use TLDR and bears no relationship to the checksum hash function used. While the examples with the longer header values are shown split to multiple lines, this is to aid the readability of this document and it is recommended that the actual header values are kept on a single line.

Location-Checksum-MD5 = "Location-Checksum-MD5: " md5-checksum md5-checksum should be a string giving the expected 128-bit MD5 message digest for the resulting downloaded file (see ).

HTTP/1.0 302 Moved Temporarily Location: http://www.example.com/files/download.tar.gz Location-Checksum-MD5: ccca8352847856cd4c2df77ce675de2b

Location-Checksum-SHA1 = "Location-Checksum-SHA1: " sha1-checksum sha1-checksum should be a string giving the expected 160bit SHA1 message digest for the resulting downloaded file (see ).

HTTP/1.1 302 Found Location: http://www.example.com/files/download.tar.gz Location-Checksum-SHA1: d98eaf66de93d9512958d6c7f5ed58d059dea53f

Location-Checksum-SHA256 = "Location-Checksum-SHA256: " sha256-checksum sha256-checksum should be a string giving the expected 256bit SHA-256 message digest for the resulting downloaded file (see ).

HTTP/1.1 303 See Other Location: http://www.example.com/files/download.tar.gz Location-Checksum-SHA256: d9c30fccbfd25469b41c1e2c68b3b1a8f2a241e1808 07d6beb3bc63ddfef6ff2

Location-Checksum-SHA512 = "Location-Checksum-SHA512: " sha512-checksum sha512-checksum should be a string giving the expected 512bit SHA-512 message digest for the resulting downloaded file (see ).

HTTP/1.1 307 Temporary Redirect Location: http://www.example.com/files/download.tar.gz Location-Checksum-SHA5126: a5555882da0419d98dd6b098e616aa66d7a5c13e54 9c2ab59dd7634ed07e379fafb4370925f65ff08d0cd50a19691acb6671a8d30b5298 0130dcc1bbfaf6a351

The user agent MAY display some kind of notification to the user upon starting a download using TLDR. However, it SHOULD NOT show any notification unless the Trusted Linker used HTTPS (because it might give the user a false sense of safety.)

Once the file has completely downloaded, the user agent calculates a checksum using its choice of the provided message digest algorithms and compares it to the one provided by the Trusted Linker. It then takes appropriate action depending on the result:

If the original TLDR checksum headers were sent using HTTPS, user agents MAY notify the user that the downloaded file was as expected according to the Trusted Linker. However, if they do, they SHOULD clearly provide the user with enough information about the Trusted Linker URL so that they can decide whether or not they do actually trust it (e.g. the fully qualified domain name). See the Security Considerations section for an explanation as to why this is necessary. If the original TLDR checksum headers were sent over plain HTTP, user agents SHOULD NOT give any positive feedback to the user because of the possibility of a Man in the Middle (MitM) attack.

All the statements in this section apply even if the TLDR checksum headers were sent over plain HTTP. Any checksum mismatch is a cause for alarm. If the checksums do not match, the user agent MUST give some kind of feedback to warn the user that something is wrong. The user agent SHOULD also remove or quarantine the downloaded file to prevent it being used accidentally.

It is possible for a Trusted Linker to redirect to a Link that redirects again. There could be any number of redirections and any of the hops along this redirect chain could also provide new TLDR headers. If this happens, a user agent SHOULD simply ignore these headers. The first hop in a chain of redirects that provides TLDR is considered the most trust-worthy.

The author has created a prototype Add-on for the Mozilla Firefox web browser which demonstrates TLDR in action. Links to download the Add-on and some example download links that implement TLDR can be found at a page on the author's website.

TLDR could be extended in the future to take advantage of other types of verification. Perhaps OpenPGP related HTTP response headers could be used, possibly by providing one or more trusted public key fingerprints along with the URL of a signature for the file. I hope to explore this idea in future revisions of this document.

The author is aware of the existing acronym "TL;DR" meaning "Too Long; Didn't Read" and feels that it is appropriate that this proposed standard has the same acronym as it aptly describes the way most people probably feel when they see instructions on how to manually verify the integrity of their downloads such as these instructions on httpd.apache.org. The author would like to make it clear that he is not criticising these instructions in any way but instead pointing out that a manual verification process is quite lengthy and tedious, and therefore often skipped completely.

[TO BE REMOVED: HTTP header fields should be registered within the "Message Headers" registry maintained at https://www.iana.org/assignments/message-headers/ ] This document defines a number of HTTP header fields, so their associated registry entries shall be added according to the permanent registrations below (see [BCP90]):

The purpose of TLDR is to allow for an automated process of file verification assuming a Trusted Linker. Provided the Trusted Linker can be truly trusted, the method is sound.

The most important consideration is whether or not the the Trusted Linker is actually trustworthy. If it is not, then TLDR offers no benefit. As a result, user agents that implement TLDR SHOULD make it clear to the user which https:// URL is being trusted.

This is necessary because a string of redirects (using HTTP, JavaScript, or any other method) could trick the user into confusing the actual Trusted Linker for a different site: https://trusted.example.com/files/file.tar.gz |=== redirects in some way to ===> http://hacked.example.org/files/file.tar.gz |=== which then redirects to ===> https://evil.example.net/tldr/file.tar.gz |=== which redirects using TLDR to ===> http://hacked.example.org/filez/file.tar.gz (which is malware and downloads with TLDR) In the example, without information to the contrary, the user may incorrectly assume that the Trusted Linker is trusted.example.com but it is actually evil.example.net

As stated in , TLDR only provides detection of modification by a Man in the Middle (MitM) if the checksum headers are delivered via HTTPS. If they are instead delivered by plain HTTP, they can be modified in transit by the MitM such that the checksums verify a different file of the MitM's choosing which they can then deliver to the user agent.

Although TLDR can help to detect when there is an integrity problem with a file download, it offers no means to retrieve a verified file should this situation arise. How can a Trusted Linker obtain the file in a secure way such that they can be sure of its integrity before calculating the checksum? This is somewhat outside of the scope of this document but a few options include: The Trusted Linker may have downloaded the file using HTTPS The Trusted Linker may have verified the file using OpenPGP and an established Web of Trust. The Trusted Linker and Final Destination servers may belong to the same organisation, e.g. the Trusted Linker could be https://trusted.example.com/tldr/software.tar.gz and the Final Destination could be http://trusted.example.com/files/software.tar.gz