HTTPS endpoint for IPFS HTTP API

[Gozala]

Unfortunately safari blocks requests to http://127.0.0.1 I was hoping they would eventually start treating it as potentially trustworthy eventually but even last technology preview seems to block it. Which means HTTPS sites are unable to talk to local daemon through HTTP API.

I would like to suggest to use idea implemented in my PoC:
https://github.com/Gozala/lunet/tree/25d0ab4231d5591a14ece75044fa0ed245fde026#srclocal

Note: On first run daemon can generate self signed certificate and add to a locally trusted roots on the system. Daemon could listen on say 5002 port along side of 5001 and serve it over HTTPS with that certificate. This setup works fine on Safari and Chrome, although not in Firefox, however Firefox and Chrome both treat http://127.0.0.1 as potentially trustworthy (although there is a bug in Firefox when doing so in SW, but we can fix that) which is to say you could cover all major browsers by trying http://127.0.0.1:5001 and then by falling back to https://127.0.0.1:5002.

[Gozala]

BTW that is also a primary reason why I end up needing a my custom server in PoC, otherwise I could just leverage daemon.

[lidel]

Just for the record, if there is no other option to support Safari we could do this TLS dance only on Mac.
Instead of running additional server, ipfs-desktop could do this. It aims to be default choice for Mac users.

Relevant excerpts from discussion after #137 (comment):

Is there a way we could remove the need for self-signed certificates? I am afraid adding stuff to system cert vault simply won't work in many environments. It may also get our apps automatically blacklisted in various enterprise-y places due to "malicious behavior".

I have being using npmjs.com/package/tls-keygen to do that on first run and it does seem to work just fine on my Mac, however that does not mean it will work everywhere. Maybe doing only on Mac or doing it on opt-in would be a reasonable compromise ?

I'm not sure I have anything to address this, however certificate can be issued generated [to limit abuse, CA needs to be unique per machine - lidel] only for 127.0.0.1 which means it doesn't create any attack vector, although I do not know if that is argument that will work in enterprise.

I also suspect Safari is not a choice for enterprise so maybe it's not that relevant ?

[Gozala]

@lidel I have being doing more digging into this and there some good news:

1. Safari seems to have gotten around to accepting that following spec and treating 127.0.0.1 as potentially trustworthy is a right thing to do. 🎉 So I imagine we won't need this workaround sooner or later. I'm not sure there is a way to help in driving Bug 171934 but that's probably a best way to get it supported.

2. Apple has notion of Safari App Extensions that I believe work across their desktop / mobile and are supposed to be bundled with native apps. Furthermore on Mobile it's probably a better option than local http server (because apps in background get suspended frequently). I think it would be best to bundle such app extension with IPFS Desktop app instead.

[lidel]

"potentially trustworthy" problem will most likely be tackled as part of localhost improvements happening via partnership with Igalia. Tracked in #109 (comment)