--api doesn't support TLS

[MichaelMure]

Version information:

go-ipfs version: 0.4.19-
Repo version: 7
System version: amd64/linux
Golang version: go1.11.5

Type: enhancement

Description:

Based on my understanding of multiaddr, it should be possible to do something like ipfs --api="/dns4/ipfs.io/tcp/5001/https" id to connect to a remote node using TLS. You guessed already, that doesn't work.

What happen is that go-ipfs, even though the https part is parsed properly, keep doing http requests. Obviously, the component that add the TLS layer in front of the API doesn't like that very much, return and error, and the call fail with:

14:38:00.954 ERROR  cmds/http: could not guess encoding from content type "text/html" parse.go:198
Error: unknown error content type: text/html

I understand that go-ipfs doesn't natively support TLS for its API, but it's a common and natural way to protect a node exposed over the internet. Can this be sorted out ?

[Stebalien]

The key missing part here is finishing enough of the multiaddr spec (@lgierth?) to support this. I believe the "correct" multiaddr way would be /dns4/ipfs.io/tcp/5001/tls/http but that hasn't quite been figured out yet.

[MichaelMure]

FYI, this one return Error: no protocol with name tls

[ghost]

We'll get /tls and /http properly defined and implemented very soon, status tracked here: multiformats/multiaddr#47 and multiformats/multiaddr#63

[lidel]

There are multiple problems with this:

1. go-ipfs implements minimum of HTTP required for interop, for everything else a reverse proxy should be used
2. HTTPS on its own is not enough to protect API. Right now API does not provide any ACL (see API Tokens discussion in API Tokens #1532), so exposing API requires adding access control via reverse proxy anyway

For both reasons, it is unlikely that go-ipfs will support API over https:// without reverse proxy any time soon.

Closing this as a duplicate of discussion in #5974 (feel free to continue there)

[folex]

Please correct me if I'm wrong, but it seems to me that #6137 (this issue) is about supporting client-side TLS while #5974 is about server-side TLS.

What I mean by "client-side" is e.g. when IPFS is behind TLS-terminating reverse proxy (nginx, caddy, etc) and now I want to do ipfs --api /dns4/mydomain.org/tcp/15001/https.