Firefox3/Link Fingerprints

Status

Feature tracking bug

• [SoC] Link Fingerprints bug 377245
• Link Fingerprints Internet Draft
• Existing implementation for necko in bug 377245 can be modified for Firefox 3 Download Manager

Overview

Link Fingerprints allows Firefox to verify automatically that an end user downloads the same file that the link provider intended. This can be accomplished by the download manager looking for a specially crafted URL of the format: http://site/file#hash(sha256:abc123) where the #fragment-id indicates that the link has a Link Fingerprint and the expected sha256 hash is abc123.

The changes are backwards compatible and only require surgical modifications to the download manager client (no changes to servers or networks), and in the common case, everything will look the same as before. Link Fingerprints is easily incrementally deployable because with Firefox supporting it, site administrators will get faster feedback that a linked download might have been compromised and fix the download which helps all users (not just Firefox users).

Use Cases

File downloads that are spread across mirrors and referenced from a central site can use Link Fingerprints to extend the increased security of the central site. For example, www.mozilla.com links to 3rd party mirrors that could have the Firefox binary modified to contain a virus; however, if the link pointing to the mirror has a Link Fingerprint, the download manager can automatically check the hash and prevent the user from using the file.

In the common case where the download does not have a Link Fingerprint or when the hash matches, the user sees nothing different from now. Only if there is a fingerprint mismatch will the file be removed and have the user notified to contact the site administrators with an error such as "<file> was not saved because the file appears to be corrupted. Please contact the site administrator."

Requirements

• Detect if a download has a Link Fingerprint
• Compute and check the hash of the downloaded file (nsICryptoHash)
• Remove file and alert user if there's a failure

Schedule

• Simplify the existing implementation in bug 377245, perhaps all in javascript or nsDownloadManager.cpp?
• Potentially coordinate with download resuming implementation

Implementation Plan

• Reuse the parsing from necko implementation or do it in javascript: url.match(/#hash\(sha256:[0-9a-f]{64}\))
• Update the hash directly from the data (webbrowserpersist/exthandler) or read from the file (incrementally or at the end)
• Reuse the prompter service for failure to alert the user
• Perhaps leverage the antivirus/malware scanning state (see CON-006a)

UI Design Documentation

• The user would get an alert on failure, which reuses the existing download manager's failure message code logic

Design Impact

Security and Privacy

Link Fingerprints doesn't necessarily affect security, but it can help ensure security related file downloads are correctly retrieved.

Exported APIs

The download manager implementation can be stand-alone, but potentially a new Link Fingerprints interface can be created to provide functionality such as "URIHasLinkFingerprints"

Web Compatibility

The current status of Link Fingerprints is an Internet Draft going through IETF, but there are potential existing implementations such as the Firefox DownThemAll extension.

Link Fingerprints uses the fragment identifier of a URL, which isn't used for file downloads anyway, and its format is backwards compatible.

Performance

The computation of the file hash can be done incrementally as the download transfers, so when it finishes, the user can access the file right away or be notified that the file was corrupted.

Reliability

The user does not need to decide on anything for successful or failed Link Fingerprint downloads. Firefox will either make the file available or delete it without a user decision.

l10n and a11y

There is a new string letting the user know that the file is corrupt and that the site administrator should be contacted.

Configuration

A hidden pref could potentially be added to turn off Link Fingerprints checking, but that isn't really necessary as the user can manually remove the Link Fingerprint #fragment-id and download.

Relationships to other projects

The implementation might change depending on download resuming..

Discussion & Implications

Caveats / What We've Tried Before

Necko implementation works is has Link Fingerprints tied too closely to networking code.

References

• http://www.gerv.net/security/link-fingerprints
• http://www.ietf.org/internet-drafts/draft-lee-uri-linkfingerprints-00.txt