Edward Lee schrieb: > The main reason for /Link Fingerprints for everything/ is that only > doing the checks on a subset of things could confuse users that have > learned the Link Fingerprint provides some level of security. >
Don't educate users about security. Most will not understand that it may in fact just provide some security for resources fetched from third-party servers. MIM-attacks will just get somewhat harder to perform. And malicious sites providing LF themselves will just ensure untampered fetches of malware. > > As things are implemented right now (for me), the channel consumers > (listeners) will still get the transferred data as it arrives > (OnDataAvailable). The only difference is that OnStopRequest will have > an error code if the Link Fingerprint failed. If you still want to implement this on a channel level, this approach sound reasonable. > In the case of the built in Firefox download manager, it will need to > explicitly remove the file after the transfer has finished provided the > status is NS_ERROR_INVALID_LINK_FINGERPRINT. I would expect DM to offer Retry/Delete/Ignore, but thats just a detail. > One caveat is that as of *right now*, my implementation will kill a > transfer if the expected hash is syntactically wrong (i.e., wrong length > or contains non-hex characters). In this case, there will be no > OnDataAvailables. > > And of course, these things are up for discussion and can change. :) > Disallowing those "corrupt LF" request is in fact what I wouldn't like to see. What if a webmaster somehow got the LF wrong? The user would get punished for it. Even SSL will let you continue if there is something wrong like non-matching hostnames; and SSL provides reliable security. I'd like to see that the user gets some kind of notification instead, telling him, that although there was a link fingerprint it was corrupt. OTOH I'm myself not quite sure how to handle this, as I wouldn't expect the regular user to understand such warning. > That's only if they don't update to know about Link Fingerprints. If > those products make the decision to not support Link Fingerprints, all > they need to do is strip off the #fragment-id before making the request. [ Ranges related ] > The end-user who requested a Link Fingerprinted download in a browser > that supports Link Fingerprints would expect the download to be checked. > If we go down the path of (1), download managers that haven't updated or > lack knowledge of Link Fingerprints would download the file in chunks > and *not* do the check - breaking the user's security trust of using > Link Fingerprints. > > By forcing Link Fingerprints on all connections as in (2), channel > consumers like download managers must decide if they want to use Link > Fingerprints. > > It's not a major use case, but it's available for those who want to use > it. For those who don't want it, strip the #fragment-id. > > Ed Therefore I wouldn't want to establish a "user's trust" in the "channels". Tell them that the built-in download manager supports LF, and that the image loader supports them, but don't try to tell them that LF will make third party products more secure, even if those are operating from within FX/TB/XR. So if dTa would remove the #hash to get back full support for ranges and there was LF support was not fully implemented or buggy... Checking ranges furthermore would mean: throw away the Range header and fully retrieve that URL. Which generally sounds like breaking a lot of stuff. You simply cannot know if a consumer will request 10-20, 0-30, 1-4 or whatever range, and therefore you cannot generate a set of hashes for ranges. So I still am in favor of implementing LF within the actual consumers, as only they know how to handle stuff correctly, as only they got the full stream. And you will have to recognize that you will indeed affect other applications as well, eg. those built on to of XULRunner, with this approach. In fact you're changing stuff marked FROZEN; not the actual interfaces but a whole lot of behavior. Nils _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
