What kind of uri are considered insecure by CanvasHttp?

[aetherus_zhou]

Currently I'm creating an adapter that provides Kaltura-ish API and uploads videos to an on-premises server. The problem is that no matter what kind of logFileUrl I return in the response of bulkUpload.add API, CanvasHttp always raises CanvasHttp::InsecureUriError (I'm testing on localhost and gives it variable domain names via /etc/hosts).  What kind of uri are considered insecure by CanvasHttp? Why localhost and 127.0.0.1 are considered insecure?

[robotcars]

Canvas requires HTTPS/secure with signed certificates. I believe self-signed certificates will work for development, but provide errors in production.

[jsimon3]

Welp you type fast.... Ｏｏ｡｡(￣￢￣*)

[aetherus_zhou]

It's not about the TLS/SSL certificate.

I do have a trusted certificate for localhost, nevertheless the CanvasHttp::InsecureUriError is always thrown.

If you look at the file gems/canvas_http/spec/canvas_http_spec.rb, you'll see these test cases:

expect { CanvasHttp.validate_url('http://127.0.0.1') }.not_to raise_error
expect { CanvasHttp.validate_url('http://127.0.0.1', check_host: true) }.to raise_error(CanvasHttp::InsecureUriError)

So 127.0.0.1 will definitely cause the error when check_host is set to true, but whether https or not simply does not matter.

Unfortunately, CanvasHttp::get calls CanvasHttp::request, which in turn calls CanvasHttp::validate_url, and check_host: true is hard coded there so I had no choice but to intrusively modify the code. Also, you can see http.verify_mode = OpenSSL::SSL::VERIFY_NONE hard coded in the implementation of CanvasHttp::request (in the file gems/canvas_http/lib/canvas_http.rb), so whether the TLS/SSL certificate is trusted or not doesn't matter either. My concern is that CanvasHttp is used in many places in many source files. My modification to the code may break the existing code.

[jsimon3]

I am not sure about this one, I test my LTI connections on localhost all the time but I do use a self signed certificate. I am not sure if you already did this but if not you could try and spin up a self signed-SSL and test your application.

[aetherus_zhou]

As described in my reply to Robert Carroll, the error has nothing to do with TLS/SSL. I also saw the instance variable @blocked_ip_filters being used in the implementation of CanvasHttp, but I can't find where it is initialized.

[aetherus_zhou]

OK, I found it. It's in the config/initializers/canvas_http.rb.

CanvasHttp.blocked_ip_filters = -> { Setting.get('http_blocked_ip_ranges', '127.0.0.1/8').split(/,/).presence }

So Canvas just tries getting the value of the record in the settings table with name = 'http_blocked_ip_ranges', if that record does not exist, using '127.0.0.1/8'. I changed '127.0.0.1/8' to '', then everything works fine. I just wonder why 127.0.0.1 is considered insecure, or being more general, what does the word "insecure" actually mean in CanvasHttp.

[robotcars]

 @aetherus_zhou ,

Sorry, I'm not that familiar with the source code or trying to trouble shoot it in development environments.

The Canvas IRC channel has engineers and developers who self host available for questions, as well as a mailing list.

It might be the best option for this issue as not too many hang around here.

Canvas Dev & Friends - Instructure Tech Blog 

[jsavage2]

This isn't a Canvas question. It *is* insecure. Using the loopback interface for anything other than the most basic proofs of concept or keep-alive tests (in other words, what it was designed for) is dangerous. If you're using it in a web app, in particular, there's always a chance it can leak to the browser or be resolved by DNS and that's a problem. 

There's a proposal out there to revise RFC 6761 to close some of the loopholes, but it's not been accepted, yet. And while w3.org allows for a 127.0.0.1 carveout in the Secure Context recommendations, it doesn't require it to be present. (and most servers have a firewall blocking 127.0.0.1:8000 in any case...)

The Canvas project just enforces good programming practices and SBD principles.

If you're storing files on the Canvas server itself, just grab the hostname from the environment and use /etc/hosts or similar to make sure it resolves if you don't have it configured in DNS.

[aetherus_zhou]

Interesting. 1 question, though, why Canvas restricts access to "insecure" loopback interface, while allowing more dangerous Man-in-the-Middle attack by not verifying TLS/SSL certificates?