API does not support SSL

[hazae41]

Version information: 0.4.23

Description:

When https://webui.ipfs.io tries to connect to an external API over http, Google Chrome throws a Mixed Content error.

Maybe we should enable SSL on the API server?

[hazae41]

A similar issue ipfs-inactive/faq#136

[Stebalien]

This isn't something we can solve as we'd need a TLS certificate for localhost.

@lidel is this a known issue? IIRC, localhost should be considered a secure origin so I wonder if we're using 127.0.0.1 somewhere or if this is a misconfiguration.

[hazae41]

I'm not using localhost, as I mentioned I'm using an API on my LAN

We could use a self-signed certificate

[Stebalien]

Ah, got it. Then there's not much we can do here. Is there any reason you can't use http://YOUR_API:5001/webui?

[hazae41]

Yes, for security reasons, and because I want to connect to the API from a secure context (e.g. an Android app, a PWA, ...)
The WebUI was just an example.

[Stebalien]

If you want security, you'd also need authentication. The usual approach is to stick an nginx reverse proxy out in front and use basic auth or a cookie, but I'm not sure how well this will work with the WebUI.

[hazae41]

It seems like a hacky workaround, end-users would need to install their own reverse proxy, why not just enable SSL?

[lidel]

@hazae41 just like @Stebalien noted, this is a known, hard limitation in web browsers.
AFAIK there is nothing we can do about mixed-content warning that would resolve the problem in seamless fashion.

Adding native support for https:// on API port in go-ipfs is not feasible

We can't add TLS to API port in go-ipfs because it won't work in all setups, including yours: it won't be able to generate a valid certificate for a service in LAN (iirc most of ToS of public CA forbid that type of use case), and self-signed ones solve nothing: you need to inject Root CA into browser keystore anyway, which makes it more hacky than setting up a reverse proxy. It also gives false sense of security: you would have encryption but still no access control. We need something like API Tokens for that (#1532).

What are viable options for using API from a node in LAN?

I understand why you might want to reuse a node from LAN, but your options are limited:

Set up self-signed TLS or localhost

To remove security warnings you need to put API in Secure Context. It means deploying TLS by adding reverse proxy + setting up self-signed certs as suggested above OR move the API to localhost (which is a Secure Context, even without TLS).

Tunnel from localhost port to a machine in LAN

If you don't want to set up TLS and really don't want to run IPFS on local machine and prefer to run it on a different one in your LAN, you can make it work if you open a port on localhost that is tunneled to a machine in your LAN, something like ssh -L 5001:127.0.0.1:5001 user@machine-in-lan
From the browser's perspective API will be at 127.0.0.1:5001 – removing the warning.

[hazae41]

Why would self-signed certs work on the reverse proxy and fail on the regular server?

[lidel]

Certs will behave the same in both cases.

The issue is elsewhere: self signed certificate will cause web browser to show validation error, so it is not something useful in production.
That is why there is no self-signed TLS for API port in go-ipfs.

(If you want to use self-signed setup, you need not only a reverse proxy, but also manually tweak your browser anyway: add exception or a root CA cert)

[alx696]

Certs will behave the same in both cases.

The issue is elsewhere: self signed certificate will cause web browser to show validation error, so it is not something useful in production.
That is why there is no self-signed TLS for API port in go-ipfs.

(If you want to use self-signed setup, you need not only a reverse proxy, but also manually tweak your browser anyway: add exception or a root CA cert)

@lidel The point is not the signing of the certificate. But whether IPFS can provide native TLS support. Golang is able to support this through parameters(path to certificates).

Because Browsers and Android require TLS, Without TLS, can't access the link. Our company's intranet products also use TLS through self-signed certificates. In this case, we will install the root certificate, so whether it is self-signed is not a problem.

Of course it can be through a proxy, but if it can be supported natively, why not? Proxy configuration is troublesome, and there are many restrictions.

if tlsCert == "" || tlsKey == "" {
  log.Fatalln(http.ListenAndServe(":40001", nil))
} else {
  log.Fatalln(http.ListenAndServeTLS(":40001", tlsCert, tlsKey, nil))
}

[godcong]

Certs will behave the same in both cases.
The issue is elsewhere: self signed certificate will cause web browser to show validation error, so it is not something useful in production.
That is why there is no self-signed TLS for API port in go-ipfs.
(If you want to use self-signed setup, you need not only a reverse proxy, but also manually tweak your browser anyway: add exception or a root CA cert)

@lidel The point is not the signing of the certificate. But whether IPFS can provide native TLS support. Golang is able to support this through parameters(path to certificates).

Because Browsers and Android require TLS, Without TLS, can't access the link. Our company's intranet products also use TLS through self-signed certificates. In this case, we will install the root certificate, so whether it is self-signed is not a problem.

Of course it can be through a proxy, but if it can be supported natively, why not? Proxy configuration is troublesome, and there are many restrictions.

if tlsCert == "" || tlsKey == "" {
  log.Fatalln(http.ListenAndServe(":40001", nil))
} else {
  log.Fatalln(http.ListenAndServeTLS(":40001", tlsCert, tlsKey, nil))
}

Yes, mobile ends such as ios and android require https.
Although it is a local connection, or LAN connection
If https cannot be configured, ipfs are completely unavailable relative to the mobile side.