Notes: Hashing files with no identifiers can lead to bad behaviour.

Created on 10 Feb 2018  路  6Comments  路  Source: ipfs/notes

Not an issue but a debate we need to address
Since the files are hashed and identified as such,
Wouldn't be easy for someone to send a data stream with malicious content
that we won't even have an indicator to what it could be? since its all hashed.

No domains, no MIME types, no extensions, We are pretty much working blindly here and expecting
the URL given to be safe, but it could be anything.

Should we discuss the issue and see how we can resolve it?

Most helpful comment

IPFS actually has (much) better security guarantees here than HTTP(s). Let's look at how visiting a website works today:

  1. Lookup the domain from DNS (unauthenticated, modulo DNSSec which isn't widely deployed).
  2. Connect to that website, hopefully using HTTPS (authenticated using the broken CA system).
  3. Fetch an HTML page (authenticated by the broken CA system). Worse, you're often fetching this from a CloudFlair reverse proxy (a very juicy single point of failure), a shared hosting company, etc.
  4. Fetch all the resources (scripts, images, etc.) used by that page, likely from a third party CDN. Usually, that third party CDN can serve you whatever it wants, not necessarily what the website intended (although one can now use subresource integrity to prevent this).

With IPFS, you'd:

  1. Resolve an IPNS address (secured by a cryptographic signature).
  2. Fetch an HTML page from some random node by hash. At this point, it doesn't really matter where we get page, we can always validate that it's the correct content by checking the hash.
  3. Fetch the associated scripts etc., again, named by hash.

Now granted, using an IPNS address isn't nearly as usable as using a domain name. To get the same level of usability, we'd need some name system like DNS that maps human readable names to IPNS addresses. However, there are a lot of people working on systems like that (things like NameCoin).

Note: mimetypes/extensions provide no security as the server can just lie.

All 6 comments

IPFS actually has (much) better security guarantees here than HTTP(s). Let's look at how visiting a website works today:

  1. Lookup the domain from DNS (unauthenticated, modulo DNSSec which isn't widely deployed).
  2. Connect to that website, hopefully using HTTPS (authenticated using the broken CA system).
  3. Fetch an HTML page (authenticated by the broken CA system). Worse, you're often fetching this from a CloudFlair reverse proxy (a very juicy single point of failure), a shared hosting company, etc.
  4. Fetch all the resources (scripts, images, etc.) used by that page, likely from a third party CDN. Usually, that third party CDN can serve you whatever it wants, not necessarily what the website intended (although one can now use subresource integrity to prevent this).

With IPFS, you'd:

  1. Resolve an IPNS address (secured by a cryptographic signature).
  2. Fetch an HTML page from some random node by hash. At this point, it doesn't really matter where we get page, we can always validate that it's the correct content by checking the hash.
  3. Fetch the associated scripts etc., again, named by hash.

Now granted, using an IPNS address isn't nearly as usable as using a domain name. To get the same level of usability, we'd need some name system like DNS that maps human readable names to IPNS addresses. However, there are a lot of people working on systems like that (things like NameCoin).

Note: mimetypes/extensions provide no security as the server can just lie.

That, is a very fine answer, Thank you.

To highlight what we all already know, IPFS could be the complementary element needed for blockchain
to use for (Sorry for using such grandiose meaningless term) new internet, As we can see with d.tube
and its usage of IPFS and the fake pseudo/like blockchain of steem, Of course its just a pliot,
But we all know that the human element comes into play, and domain-name like situation could be the "Make-or-break" aspect of a new internet that is in dire need to come to life.

I wish you all thank you, Wish i could help but i am not a GO/JS developer, more of a C and family developer, But if i could find any interesting bugs and report them, I will.

Please do! Also, FYI, Go was heavily inspired by C (the authors of Go wanted a better, safer C).

Not to derail the subject but no mate, no.
Unsafe C is what make C, great, We tried (Annex K) for c11, it was a failure for obvious reasons.
If you want to have safe code... write safe code... and have testers and Q/A team.

@Illasera this is definitely not the right place for that discussion.

Seems to me that the discussion reached a conclusion. Closing this one :) Reopen if necessary

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jbshirk picture jbshirk  路  3Comments

klueq picture klueq  路  5Comments

jbenet picture jbenet  路  6Comments

jbenet picture jbenet  路  3Comments

czanella picture czanella  路  3Comments