Running over TLS?

[TheDavidJohnson]

A huge "thank you" for making this software available, as always!

I've set up a nodeStorage server on an Ubuntu VPS and now I've gotten myWordEditor running as well. It's running beautifully...

The question I have has to do with running myWordEditor over a TLS connection via https.

It appears that some components are hardcoded to the http protocol, as when I connect to myWordEditor via https (as is my habit with all tools running on this server), this is the result:

Screenshot via imgur

I'm guessing that running over https wasn't originally envisioned. If you're able to point me in the right direction, I'm happy to do some work to make the needed modifications. Thanks!

[scotthansonde]

I tested this on my local machine with an ngrok URL and got the same result. The browser is blocking all "insecure content", all the stylesheets and scripts in index.html called with http://

448f1071.ngrok.io/:1 Mixed Content: The page at 'https://448f1071.ngrok.io/' was loaded over HTTPS, but requested an insecure script 'http://api.nodestorage.io/ui/jquery-1.9.1.min.js'. This request has been blocked; the content must be served over HTTPS.
448f1071.ngrok.io/:8 Mixed Content: The page at 'https://448f1071.ngrok.io/' was loaded over HTTPS, but requested an insecure stylesheet 'http://api.nodestorage.io/ui/bootstrap.css'. This request has been blocked; the content must be served over HTTPS.
...

[davisshaver]

Thanks @scripting for pinging us via scripting/pagePark#6 (comment).

Coincidentally I've been looking into the mixed content issue as well. Here's my original 1999 server w/ no SSL compared to my new server with SSL. The websockets don't work on the new server at the moment, but that's an unrelated issue.

Few ideas I was considering for working around this...

• upgrade the remote server to HTTPS and switch the protocol depending on URL
• setup a CDN that can upgrade the remote server w/o adding HTTPS directly
• reverse proxy the assets from the server?
• load the assets into the repo/origin site

Alternatively you could force the server to stay in HTTP mode, e.g. for ngrok only in HTTP.

[AngeloR]

One thing that could be done is a PR that changed any links that hardcoded the protocol to //.

IE:

<script src="http://fargo.io/code/concord.js"></script>
Becomes
<script src="//fargo.io/code/concord.js"></script>

This will force the browser to supply the current protocol. If you are browsing an HTTPS site, it will force all those links to go to HTTPS, likewise if you are using HTTP, it will force everything to HTTP. That way you could support simultaneously running HTTP/HTTPS versions.

[TheDavidJohnson]

Thanks @scripting for having others check in on this. I think I recall from your blog that you aren't necessarily a big fan of the "https everywhere" concept, so thank you for being so accommodating. Also, thanks to everyone who has jumped in!

A couple of quick thoughts:
@AngeloR mentioned removing the hardcoded protocols. This was where my mind was going, but it looks like some of the assets may not yet be available over https.

@davisshaver mentioned a few possibilities:

upgrade the remote server to HTTPS and switch the protocol depending on URL

I'm in the habit of using LetsEncrypt and 301 redirects for all non https access attempts so that they're always served over https. Thus, I wouldn't prefer to do any protocol switching.

setup a CDN that can upgrade the remote server w/o adding HTTPS directly

I'm not a fan of using CDNs (like Cloudflare or even Cloudfront) to upgrade to HTTPS because of the identity problems and possible MITM attacks associated with the 3rd-party components

reverse proxy the assets from the server?

This works for me as long as the assets are local. In the cases where assets are being pulled from other sources and are still being served (to my server) over HTTP, they're going to be subject to MITM in transit.

This is actually the method I'm using to serve nodeStorage over https, as described in the guide that @andrewshell wrote (although my configuration uses nginx instead of apache).

load the assets into the repo/origin site

This makes sense to me for some of the assets. I haven't gone through everything with a fine-toothed comb just yet, but if there are any js libraries that should be updated from time to time, it may make sense to continue to load them directly from origin servers if they're available over https.

BTW, I'm more than happy to test any of the above on my setup, which runs Ubuntu and nginx.

[scripting]

Just posted an update, v0.73, that has the http:// addresses in the head section of index.html changed so they should work with an HTTPS backend.

https://github.com/scripting/myWordEditor#v073----91917-by-dw

[scripting]

I'm not a fan of make-work security theater that is completely impossible because I have a huge number of domains and Google doesn't fucking care if they wipe out all history on the web, so no I'm not a big fan as you say.

That said I try not to have "strategy taxes" on my software, like Google is doing in search. If people want to use it with HTTPS and it's possible I will help, as much as I can.

But this is already turning into a morass. It might make sense to just fork this project and come out with an HTTPS version and keep me the fuck out of it, because I'll retire before I let another big company make me do work for free for no benefit. I hate big tech companies.

[scripting]

I created this with the new version. But my server is not running behind HTTPS.

http://myword.io/users/davewiner/essays/055.html

[davisshaver]

Thanks for the update @scripting & I understand your perspective, I actually hadn't considered this as a historical issue until just reading your last comment. There are plenty of valuable servers that should not be expected to have the resources to upgrade to HTTPS. Love the term strategy debt and that's how I feel about needing to implement it. I'm going to keep hacking on this and will share what I find. Per @TheDavidJohnson above, how would you feel about us extending the update framework to pull in additional assets? I'm glad to help put together a proof of concept if that sounds okay.

[scripting]

Google probably hasn't thought about it either. But it's not the number of servers it's the number of domains that matters.

[scotthansonde]

The new version almost works with HTTPS, except that the assets at fargo.io aren't available over HTTPS (and, if I understand Dave correctly, never will be 😄 ). I'm willing to help out to get it working, though.

[scripting]

>how would you feel about us extending the update framework to pull in additional assets?

Let's get in the habit of formalizing this. I like writing and reading RFCs. For specific problems, not whether or not to generalize something. First I want to know what the problem is, and get a chance to think about it, before figuring out how to do it. You end up living with the solutions for a long time. Dave

[scripting]

I don't mind moving them @papascott.

Let's create a place where assets stored on S3 are served over HTTPS.

Then all my static files can be available that way.

Remember -- NO STRATEGY TAXES.

If it's easy it's easy.

[davisshaver]

A Scripting publicFolder 😄 ! The S3 bucket sounds like a great idea. And, noted about the RFC's and patching. If I can get one together I will share in pagePark. Right now I'm leaning on AWS free cert manager to setup SSL on domains. Actually they can give you up to 100 domains SSL for free on a single cert so I was pleasantly surprised by that.

[TheDavidJohnson]

I can test the latest update over HTTPS later today. If we end up doing an RFC, let me know... I'll happily contribute!

I feel like I need to write this date down... @scripting is proposing an S3 bucket with HTTPS?! What?!